Package Details: jdk 23.0.1-1

Git Clone URL: https://aur.archlinux.org/jdk.git (read-only, click to copy)
Package Base: jdk
Description: Oracle Java Development Kit
Upstream URL: https://www.oracle.com/java/
Licenses: LicenseRef-custom
Conflicts: jre
Provides: java-environment, java-environment-jdk, java-runtime, java-runtime-headless, java-runtime-headless-jdk, java-runtime-jdk23, jdk23-jdk, jre, jre23-jdk, jre23-jdk-headless
Submitter: td123
Maintainer: dbermond
Last Packager: dbermond
Votes: 1087
Popularity: 0.88
First Submitted: 2011-08-27 17:56 (UTC)
Last Updated: 2024-11-16 14:08 (UTC)

Required by (2649)

Sources (9)

Pinned Comments

dbermond commented on 2024-03-19 19:54 (UTC)

  • Important notice:

As was made with the java packages in the official repositories, jdk now provides the jre alongside it, and both packages conflict with each other. During the package upgrade to version 22, act accordingly to your needs. For example, if you have both jdk and jre installed, only jdk will be sufficient, as it now also contains the runtime environment, and jre can be uninstalled. If you have only jre installed, no action is required.

Latest Comments

« First ‹ Previous 1 .. 39 40 41 42 43 44 45 46 47 48 49 .. 81 Next › Last »

Det commented on 2014-02-24 05:16 (UTC)

Removed "PKGEXT='.pkg.tar'" due to a request of having your own way through makepkg.conf.

Det commented on 2014-02-12 15:32 (UTC)

Ok, well the phrasing was a bit misleading, since it's not about the size or the unreliability of the Oracle servers that the download doesn't work. So it's not like an "improvement", it's actually the only way to do it. Then about the PKGEXT, I've actually set it in quite a lot of places, and at times have thought about removing it from all of them (just because I can obviously set it myself), but people never complained so I never bothered. The initial argument I think was something like 'this thing is never provided to anybody, so a as-fast-as-possible install is preferable'. But compression should, of course, be done like you like it to be done. Sure makes a lot more sense.

hefeweiz3n commented on 2014-02-12 15:23 (UTC)

As I stated: I know why DLAGENTS is in there, I remember the times when it wasn't... However the PKGEXT is definitely something where the user setting should take preference. On my laptop I too have compression disabled in /etc/makepkg.conf as it takes too long, however when building on said server for distribution on computers managed by me I need it. So it would be much appreciated if you could in fact remove it and set it locally on your computers according to your needs (which is in my opinion also the much cleaner version than setting it in a single package). Thanks in advance!

Det commented on 2014-02-12 12:01 (UTC)

I agree it's not nice to override the DLAGENTS, but if you actually tried removing it you'll see why it's there.

hefeweiz3n commented on 2014-02-12 08:06 (UTC)

Please remove PKGEXT from the PKGBUILD. If people don't want to compress locally built backages they can set it in their makepkg.conf. For people like me, who build the package on a fast machine and then distribute it to their computers via internt compression is necessary and it it always a pain in the butt to have to comment this out manually. It is also not nice to override user settings (In the case of the download agent I can however understand it with the big source package size and as I know the oracle download servers to be a bit unreliable).

Det commented on 2014-02-07 16:58 (UTC)

Took a while, but the dependency's finally fixed. 'Atk'[1] was pulled in as a dependency of 'classpath'[2], which made the reporter think that classpath should be required. After some discussion we found out that not only was 'atk' the real dependency, but this package doesn't require it at all. So, even if you don't use OpenJDK[3], atk will still be installed, but it's required by things like GTK+ 2/3 anyway, so few will care. [1] = https://www.archlinux.org/packages/extra/x86_64/atk/ [2] = https://www.archlinux.org/packages/community/x86_64/classpath/ [3] = https://www.archlinux.org/packages/extra/x86_64/jdk7-openjdk/

Det commented on 2014-01-31 21:36 (UTC)

Just to fill you in on this, we had a little discussion with Alex and he's decided to re-open the bug: https://bugs.archlinux.org/task/38567 His original idea was that since NetBeans continued to work even with the dependency he assumed everybody would be happy. But then when I asked him about it he agreed that if it really was unnecessary, then indeed it should be reverted. We'll see what the original reporter has to say.

bigcajun commented on 2014-01-31 14:24 (UTC)

I agree with you. Not sure why the dependency was added to NetBeans. NetBeans runs fine for me without "classpath" installed. I haven't looked at all the details, but I think this package provides all the stuff that's in "classpath" so someone with this package installed shouldn't need "classpath" installed anyway. I added classpath to the provides list and rebuilt so that updating NetBeans wouldn't require me to also install classpath. I guess that's more of a hack than the real solution. Maybe the person that filed the bug has a broken JDK (i.e. not this one)? It wasn't stated in the bug report what the Java environment (or which java packages) were installed.

Det commented on 2014-01-31 12:18 (UTC)

I'm not sure about this. (At least) for me NetBeans works just fine even with just 'jre7-openjdk', so the whole idea that NetBeans wouldn't even run, if you hadn't installed Classpath seems kinda crazy: https://bugs.archlinux.org/task/38567 And what's even crazier is that it actually went through. I removed both ~/.netbeans/ and ~/.cache/netbeans/ just in case and the EULA works too.

bigcajun commented on 2014-01-31 03:49 (UTC)

The NetBeans package recently added a dependency on the "classpath" package. Unless I am mistaken, having Oracle's JDK installed fulfills all of the NetBeans package needs. Might I suggest this package be updated to add "classpath" to the "provides" line in PKGBUILD? What I'm getting at is there doesn't seem to be a need to install the "classpath" package if you have this JDK package installed.

« First ‹ Previous 1 .. 39 40 41 42 43 44 45 46 47 48 49 .. 81 Next › Last »