oracle jdk10 / java se 10 is released ! maybe should focus on the java10 ,and skip java9.
jdk 10 : http://www.oracle.com/technetwork/java/javase/downloads/jdk10-downloads-4416644.html
Well this release train is going to keep speeding along from now on so we'll have to adjust our plans accordingly, not that anything much is being done at the moment. 8 to 9 is hard. 9 onward should be easier. java-config needs to be fixed for 10 because it will order the versions incorrectly. Other than that, you could put forward an ebuild for 10, which I imagine will look almost identical to the one for 9.
*** Bug 652810 has been marked as a duplicate of this bug. ***
Dear James, to support the Java team's work in progress I propose a bumped ebuild, using the ebuild for 9.0.4. https://github.com/gentoo/gentoo/pull/8943 No changes need except of adding a special option to the JVM command that create the "Class Data Sharing archives" to avoid the creation of directory and files for the "usage tracker" feature (see https://docs.oracle.com/javacomponents/usage-tracker/overview/toc.htm). This will trigger a sandbox violation, otherwise. Passing this command line property is the best way here, i think. But maybe, the users should be noticed about that this feature now is enabled by default and might be worth to disabled in a persistent way by a property file as mentioned in the docs .
(In reply to Guido Jäkel from comment #4) > Dear James, > > to support the Java team's work in progress I propose a bumped ebuild, using > the ebuild for 9.0.4. > > https://github.com/gentoo/gentoo/pull/8943 > > No changes need except of adding a special option to the JVM command that > create the "Class Data Sharing archives" to avoid the creation of directory > and files for the "usage tracker" feature (see > https://docs.oracle.com/javacomponents/usage-tracker/overview/toc.htm). This > will trigger a sandbox violation, otherwise. Passing this command line > property is the best way here, i think. Thanks. This works fine for me.
(In reply to Guido Jäkel from comment #4) > Dear James, > > to support the Java team's work in progress I propose a bumped ebuild, using > the ebuild for 9.0.4. > > https://github.com/gentoo/gentoo/pull/8943 > > No changes need except of adding a special option to the JVM command that > create the "Class Data Sharing archives" to avoid the creation of directory > and files for the "usage tracker" feature (see > https://docs.oracle.com/javacomponents/usage-tracker/overview/toc.htm). This > will trigger a sandbox violation, otherwise. Passing this command line > property is the best way here, i think. > > But maybe, the users should be noticed about that this feature now is > enabled by default and might be worth to disabled in a persistent way by a > property file as mentioned in the docs . I just update this ebuild to 10.0.2, see https://github.com/gentoo/gentoo/pull/9479
(In reply to James Le Cuirot from comment #2) > Well this release train is going to keep speeding along from now on so we'll > have to adjust our plans accordingly, not that anything much is being done > at the moment. 8 to 9 is hard. 9 onward should be easier. java-config needs > to be fixed for 10 because it will order the versions incorrectly. Other > than that, you could put forward an ebuild for 10, which I imagine will look > almost identical to the one for 9. May be it can be added but hard masked? It would allows people who really need Java 10 to use it (I don't think that the order in the list of available JVMs is a such a big deal). I mean that Java developers are using Java 10 anyway from local overlays, or installing it by hands, which is even worse.
*** Bug 665096 has been marked as a duplicate of this bug. ***
Meanwhile Java 11 is available.
*** Bug 667712 has been marked as a duplicate of this bug. ***
Oracle JDK is going on the way to a full non-free build. Oracle OpenJDK builds are freemium, but Oracle only support LTS and the latest major version. AdoptOpenJDK is built from OpenJDK source and supported by community. As codebase is almost the same between them, is AdoptOpenJDK our choice in future? P.S.: It seems AdoptOpenJDK supports another JVM implementation called OpenJ9.
(In reply to Xiami from comment #11) > As codebase is almost the same between them, is AdoptOpenJDK our choice in > future? I already added openjdk-bin with AdoptOpenJDK builds to the tree last week. I am working on a source package.
(In reply to James Le Cuirot from comment #12) > (In reply to Xiami from comment #11) > > As codebase is almost the same between them, is AdoptOpenJDK our choice in > > future? > > I already added openjdk-bin with AdoptOpenJDK builds to the tree last week. > I am working on a source package. Could you please explain why openjdk-bin is not affected by java-config issue, but oracle-jdk-bin is? Is there any bug number for java-config, which is possible should be dependency for this bug.
(In reply to Mike Limansky from comment #13) > Could you please explain why openjdk-bin is not affected by java-config > issue, but oracle-jdk-bin is? Is there any bug number for java-config, which > is possible should be dependency for this bug. Hi Mike. Sorry for not replying to your earlier question on GitHub. I wasn't avoiding you, I just couldn't remember the details and I needed to dig back into it first. Turns out the reason I couldn't remember the details is because I imagined it. :| I had been under the impression that the Java eclasses are supposed to automatically select the latest Java version, possibly when the current selection has been removed. At some point, I must have convinced myself this was true without actually checking. The truth is nothing happens at all. If the current selection is removed then you are left without an active VM but the eclass warns you about this. Otherwise it would have been a problem because java-config doesn't order the VMs by version. I did partly correct this in eselect-java so that openjdk-bin-10 will appear after openjdk-bin-9 but this would still be followed by oracle-jdk-bin-1.8 because the name is included in the sort order. The ability to set VMs with java-config has been deprecated for years and I actually set about removing the code and updating the eclasses accordingly back in January. I now can't remember why I didn't finally get that pushed but I've just done it now. There are a lot of commits in java-config that have not been properly reviewed and as such, we have been a little scared to do a new release since the last one in 2013. With me bowing out shortly, I'm afraid someone else will have to do it. All this was slightly moot anyway because entries only appear in java-config for the newer VMs if the gentoo-vm USE flag is enabled and that will remain masked for the foreseeable future. If you guys want oracle-jdk-bin:11 added then join the team or send monsieurp a PR. My remaining energy will only be spent on OpenJDK.
I proposed an bumped ebuild for orcale-jdk-bin-11.0.1, see https://github.com/gentoo/gentoo/pull/10224 In comparision to 10.0.2 , I had to disable the pruning of lib/fonconfig.* files.
since yesterday we have 11.0.2 in the main tree :-)
