OpenJDK-9.0.4

[Pierre Labastie]

New point version. See ​http://www.oracle.com/technetwork/java/javase/8u152-relnotes-3850503.html

The full version string for this update release is 1.8.0_152-b16 (where "b" means "build"). The version number is 8u152

Several security fixes as usual.

[Pierre Labastie]

Should we still provide a 32 bit VM?

[bdubbs@…]

Replying to pierre.labastie:

Should we still provide a 32 bit VM?

If it doesn't take a lot of time, yes. However I think it would be relatively time consuming for very little value. If we don't, a note saying that a 32-bit version is not available would be appropriate.

As a side note, I just finished rebuilding the system on my laptop. I find no use for java on that system at all. I do build the 64-bit version on my development system for the book, but do not remember using it for anything I need other than fop (to render the pdf version of LFS).

[Armin K]

OpenJDK 9 has also been recently released. I don't know if it's worth upgrading at this time.

[Armin K]

Also, as a side note. I was looking at getting the proper version using BLFS currency scripts. The problem with openjdk detection is that it detects packages available on LFS servers, not the actual upstream ones.

However, the links in the jdk page [1] are integrated somehow differently from other packages, and because of that they do not appear in wget-list. If you could make the download part look more like other packages, the currency could be used to fetch every new version. Would that be a problem? There are other packages split into several sources (take a look at LLVM, for example), and they all use same instruction format.

[1] ​http://www.linuxfromscratch.org/blfs/view/svn/general/openjdk.html

[Pierre Labastie]

Replying to Krejzi:

OpenJDK 9 has also been recently released. I don't know if it's worth upgrading at this time.

I guess this is something which should be discussed on the list: as Bruce said, the book itself has only fop which depends on java, so it should be checked that fop can be built with java 9. But I know several users use java for programming, and they have certainly an opinion.

[Pierre Labastie]

Replying to Krejzi:

Also, as a side note. I was looking at getting the proper version using BLFS currency scripts. The problem with openjdk detection is that it detects packages available on LFS servers, not the actual upstream ones.

However, the links in the jdk page [1] are integrated somehow differently from other packages, and because of that they do not appear in wget-list. If you could make the download part look more like other packages, the currency could be used to fetch every new version. Would that be a problem?

The layout can certainly be changed (it would be nice to have those in wget-list), but the currency problem lies elsewhere: there are new "8uxxx-byy" tags every week or so, but those are not releases. The only way to know which xxx/yy combination is a true release is to monitor the ​http://www.oracle.com/technetwork/java/javase/overview/index.html site. Also their issue tracking system is hard to use: identical issues do not have the same number if they are applied to different xxx (for example 8u151 and 8u152) or different version (8 or 9).

[Armin K]

Yes, I was intending to use ​http://www.oracle.com/technetwork/java/javase/downloads/index.html anyways. We don't need to match bXX number (as it can't be done from that page), but we can match 8uXXX ones just fine.

[Pierre Labastie]

After a "poll" (only two answers) to the list, I think nobody is against moving to JAVA 9. Preliminary testing shows that system libraries are easier to use and testing is much easier. Furthermore, there is an OSS version of the binary JVM at ​http://download.java.net/java/GA/jdk9/9.0.1/binaries/openjdk-9.0.1_linux-x64_bin.tar.gz, which may eliminates the need to store it on anduin (note that we may still have to provide a 32 bit JVM on anduin)

[Pierre Labastie]

Java 9 introduces big changes, see ​https://docs.oracle.com/javase/9/whatsnew/toc.htm. Roughly, there is no more a jre directory, but a jmods directory with modules, which can be customized to downsize the jdk to a jre or even smaller.

Also the cacerts file is now in $JAVA_HOME/lib/security (no jre dir in the path), and can be accessed with the option -cacerts in the keytool command (instead of -keystore <path>). Furthermore the -import option to keytool is obsolete and should be replaced with -importcert. This has some implications to the make-ca command.

[Douglas R. Reno]

Let me know if you need some Java code to test with. I still have some of the stuff from my time in College.

[Pierre Labastie]

Giving back to the book. Nobody ever answered questions on the list, so I think nobody is interested. I do not use Java myself.

[DJ Lucas]

Fixed at r19800.