OpenJDK-1.7.0.71/IcedTea-2.5.3/Java-1.7.0.71 is out, but moving to OpenJDK 8

[Fernando de Oliveira]

​http://icedtea.wildebeest.org/download/source/icedtea-2.5.3.tar.xz We want to move to OpenJDK 8, which more secure. See comments below.

[Fernando de Oliveira]

Pierre, despite the title, I know that the most recent is java-1.8.0-openjdk-1.8.0.25, e.g.

​https://rhn.redhat.com/errata/RHSA-2014-1636.html

But never tried to understand why they are always ahead in this package, but not so much so in the others.

[Fernando de Oliveira]

(Edited the previous comment)

Also, Oracle is at 1.8.0.25, and warning in the browsers, if yoiu use theeir site to verify the java version. Warning, I wrote, that 1.7 is not anymore secure.

[Pierre Labastie]

Replying to fo:

(Edited the previous comment)

Also, Oracle is at 1.8.0.25, and warning in the browsers, if yoiu use theeir site to verify the java version. Warning, I wrote, that 1.7 is not anymore secure.

Well, does that mean we should go to 1.8? Right now, Debian has it in "unstable". Fedora schedules it for Fedora 21 (should be released soon). And I saw on Fedroa wiki:

OpenJDK 7 will publicly End-of-life in April 2015. Security patches may not be backported to OpenJDK 7 (or if they are, they will be significantly delayed).

So, unless somebody objects, I'll work on upgrading to 8. Will change the ticket summary within a couple of days if no objection.

[Fernando de Oliveira]

I agree with you: upgrading to 8.

[Pierre Labastie]

Progress report

[Pierre Labastie]

Progress report: Only pre releases are available. The latest one is icedtea-3.0.0pre2 ​http://icedtea.classpath.org/hg/icedtea8-forest/archive/a81a301b0f89.tar.bz2. I can make a more friendly tarball and upload it to anduin with the other tarballs, which are needed anyway.

The new build system is more friendly and incredibly faster. But you have to build jtreg for tests, and that pulls in a lot of other dependencies (work in progress now).

I plan to build a JDK 8 Java machine and to use it to build jtreg and bootstrap a new build

[Fernando de Oliveira]

Pierre, one question: if Fedora have it, though not released, are they using icedtea-3.0.0pre2? C'est damage that new packages need to be added due to the tests.

[Pierre Labastie]

I am not good at rpm specs deciphering, so I am unable to see what Fedora is doing actually. I'll look at Debian (they have openjdk-8 in sid, although the default is still openjdk-7) and arch.

For the deps of jtreg, junit is already in the book, and ant (a dep of junit), too. I'll see whether we can skip some others. Actually, somme of them are just zipped files, to be unzipped into the right directory. So that may not add many pages to the book, besides jtreg itself.

[Fernando de Oliveira]

Right.

Have same problems with rpm. Cannot remember exactly, if searching the internet or some text in (B)LFS. One thing I remember is that the scripts in (B)LFS never work, and I install the necessary programs using ArchLinux instructions.

It is so rare needing it, that each time I need to do all research again.

[Pierre Labastie]

Thanks Fernando.

Here is a new progress report:

• It seems that distros do not use icedtea anymore and compile directly from openjdk source. I have tried today, and I think it is the path to follow with LFS, too. What I am not sure about is the version we should use. There is an update process, with three main lines: jdk8u20, jdk8u25, jd8u40. The latest updates are respectively: jdk8u20-b26, jdk8u25-b18, jdk8u-40-b11...
• jtreg is not that tricky to build, but only old versions of junit (4.6) can be used. I do not know whether it is a problem. I think we'll be using junit only for testing jtreg itself. I've also read that jtreg binaries are available. I do not know whether the "spirit" of the book would be lost if we'd use them. Anyway, I have not tried. Also, I do not know whether it is necessary to install jtreg into the /usr/hierarchy, or if it is enough to keep the build directory.
• For openjdk, a few patches have to be applied. All of them can be done with sed's.
• ATM, I am unable to run the tests. I get an error "cannot determine version of java to run jtreg". Dunno what it means.

Enough for today.

[Fernando de Oliveira]

Good progress!

I would go for 8u40. In version 7, it was common OJDK be ahead of the proprietary, and this is now at 8u25, for some time already.

[Pierre Labastie]

Thanks for support, Fernando! I am just beginning to find all this very hard...

Actually, I have found that jdk8u20-b26 is the considered stable version. The stable version of 8u40 is scheduled for next March or April. And there is no information about 8u25 on the openjdk site, guess it has something to do with the proprietary soft.

Something I overlooked yesterday: Patches are needed to use the system versions of lcms and libpng. Since it changes the configure script, that means autotools have to be run. Related: the logic for libjpeg is slightly different, the system version is used if found, but you have no mean to override that by a configure switch. Maybe we could use the same logic for lcms and libpng. That makes shorter patches (but still we need to rerun autoconf).

Of course, we could also just accept to use the bundled versions of libpng and lcms, and nothing would be needed...

Also, patches from debian are much more complicated than patches from icedtea (those who are submitted to openjdk, but not yet accepted, for using system versions of lcms and libpng).

[bdubbs@…]

Replying to pierre.labastie:

Of course, we could also just accept to use the bundled versions of libpng and lcms, and nothing would be needed...

I vote for that. It may not be optimal, but I think it is practical.

[Pierre Labastie]

@Bruce: agreed, let's use the bundled versions of libpng and lcms.

New progress report about tests:

• Tests need Xvfb and a window manager for running, but it seems that twm is not appropriate (2 tests hang). Testing with fvwm right now. fvwm is supposed to be OK according to the doc.
• Only langtools and jdk are tested if you use the top test/Makefile. Only 2 tests (the tests which hang, see above) out of > 4000 fail. There is a test withan error, too (I do not know the difference between an error and a failure). SO, ala in all, tests are good, but (see below), not all tests are run. Furthermore, you have to change to hotspot/test and run jtreg manually to get the hotspot tests. For hotspot, 10 tests fail out of 645.
• Only a subset of the tests for jdk are run by the top test/Makefile. Around ~2000 tests are not run, while ~3500 are run. If you want all the tests, you have again to run jtreg manually (not yet done).
• You have to pass JT_HOME and PRODUCT_HOME to all the tests, they are not set automatically, although they could easily be set in the Makefile's. Do not know if it is better to patch/sed the Makefile's or to set and pass those variables in the book instructions.

I am now using a built JDK 8 VM, and all seems well.

[bdubbs@…]

I suggest passing JT_HOME and PRODUCT_HOME explicitly. Just document the other issues.

[Pierre Labastie]

Fixed at r14964.

I guess that ant and junit are not usefull anymore, but I have to check. So closing this ticket and will open another one for archiving.

[bdubbs@…]

Making the change on anduin is trivial. However the book has the file names differently that what was uploaded. The book has names like OpenJDK-1.8.0_25-b18/hotspot.tar.xz, but anduin has OpenJDK-1.8.0_25.

I'm a bit agnostic about OpenJDK-1.8.0_25 or OpenJDK-1.8.0.25, but do have a slight preference for the dot. I do see why upstream may have wanted to differentiate version 1.8.0 from build (if that is the right term) 25.

In any case either I need to change the directory name on anduin or the book needs to be changed or both.

Reopening until we decide the best way to go.

[Pierre Labastie]

Typo (-b18) fixed at r14970.

For upstream, in the full version name (1.8.0_25-b18), 25 is the "update" number, and 18 is the "build" number.

I am agnostic too... But just, I'd like to know why Fernando is not.

Changing the underscore to a dot is just a matter to change the openjdk-version entity in packages.ent.

[Fernando de Oliveira]

I have removed my comments.

Forgot I had promised not to make interventions about my opinions.

If by any chance I do it again in the future, please, just remind me what I promised.

[Fernando de Oliveira]

The source code is jdk8u25-b18.tar.bz2.

My personal preference (that doesn't matter) would be to comply to the source package.

So, my preference, that I never put in discussion, and I'm not doing it now, would be "open jdk8u25-b18" for the page name.

Just to demonstrate that what I discuss is not exactly what I would like it to be.

The book had named the page as a convention, by DJ, who even stated it in a discussion I had with him.

But I am not opposing to anything Pierre does. Just commenting the interesting pattern of changing the book as much as the commit allows, every time.

Which, again, I may comment in future occasions, because I don't like that, but will never oppose anymore.

[bdubbs@…]

OK, I'll change it and coordinate anduin.

[bdubbs@…]

Fixed at 14974. anduin updated.

[Pierre Labastie]

Answering to comment:23

But I am not opposing to anything Pierre does. Just commenting the interesting pattern of changing the book as much as the commit allows, every time.

Which, again, I may comment in future occasions, because I don't like that, but will never oppose anymore.

I do not quite understand what you are saying, but you seem to write that I am just changing the book for changing it. It is of course not true. You very often change things too, in your commits, and I'll never say that it is just for "fun". When I sometimes disagree, it is because there are several ways to do things, and I think you did not choose the one I think is best. But at least, I understand you could have reasons for doing that.

In the present case, the reason is the following: when you issue:

java -version

you get:

openjdk version "1.8.0_25-BLFS"

I have not invented it. And I felt like it was better to use upstream way. You don't. That does not mean I did the change lightly!

So please refrain from making this kind of comments, or I guess you'll end up editing the book alone (maybe it is what you want...).

[bdubbs@…]

All the editors are making changes that they feel are the right thing. I don't feel anyone thinks differently. There is no reason not to express an opinion, even strongly, but please don't think in antagonist terms. Let's make this the last comment in this ticket and move on.

[Armin K]

Just an FYI:

Even Oracle's Binary JDK extracts to "jdk1.8.0_25", so the versioning Pierre used at first appears to be some kind of convention used by Java people.

[Fernando de Oliveira]

Armin's comment does not need a reply, because what he says is common knowledge.

Although this replies in part Pierre's comment, I would like to reply at length. I'm not doing it now, because Bruce asked not to. As always, for Armin, it does not matter. He only respects what lies between him and the image in the mirror he is using for self admiration.

I'll do reply tomorrow, if I am allowed to.

[Fernando de Oliveira]

Not tomorrow. I am very disappointed now. Will take a couple of days off. will be back as soon as I feel better.

[Armin K]

My reply was just an observation, nothing else.