The answer, as of this moment, is most definitely. There are two reasons for this at the moment.
- there are still packages which don’t compile when built with Java 1.5. In these cases, the new Java build system switches to a 1.4 JDK for building.
- it is needed for packages that haven’t been migrated to use the new Java system. This is necessary, otherwise we encounter the same exact problems that prompted the initial package.mask of Java 1.5.
Just to recap why Java 1.5 was package was package.mask’d…. It really comes down to backwards compatibility, and that Java 1.5 isn’t 100% backwards compatible with Java 1.4. Things that ran with Java 1.4 should still run with Java 1.5… but some things that once built with Java 1.4 no longer compile with Java 1.5. Specifically:
- There’s a new reserved keyword with Java 1.5, enum. So where you used to be able to use enum as a variable name, you no longer can in 1.5.
- A number of new methods have been introduced to some abstract classes and interfaces. If a particular implementation doesn’t implement the new methods, then it won’t compile against Java 1.5
Now, say you’re using Java 1.5 to build all your packages, and then you come up to a package that can’t compile for one of these reasons? It’d fail for one. But then you may try with Java 1.4… and all is well until you see a compile error: UnsupportedClassVersionError. What does this mean though?
Well, each major release of Java has it’s own version of bytecode. Bytecode is forward compatible, ie run 1.4 bytecode in 1.5, but not backwards compatible. If you try to use 1.5 bytecode in 1.4, you will see the infernal UnsupportedClassVersionError. This happens because, since you were using Java 1.5, the dependencies of the package you were just trying to compile with 1.4 were built with 1.5, and the default behavior is to build the highest possible bytecode.
So, these are the reasons Java 1.5 was package.mask’d, and why we need to use Java 1.4 for building unmigrated packages.
But how does the new Java system help?
- We get around the problem of enum by specifically telling the compiler to use source=”1.4″, where enum is a valid variable name.
- We get around the changes in API by switching to a version where it can be compiled, until such time as the package can be properly patched.
- Additionally, we make javac compile the lowest possible bytecode, so it can be used by as many other packages as possible.
Nice explanation, that hopefully people will understand. If you put this also on the wiki, we can slap everybody who asks with it 🙂
Hi,
Yes, we still need Java 1.4. Even when there’s nothing in the tree that needs Java 1.4, there’ll be plenty of third-party stuff that doesn’t work w/ Java 1.5. At work, we still use Java 1.4 because we find the CORBA support in Java 1.5 just too unreliable.
Best regards,
Stu
Excellent point Stu. My post was mostly a response to people who have been ‘inquiring’ Java 1.5 isn’t being used for everything yet.
Of course, we need Java 1.4 for people who need/want Java 1.4 😀
Additionally, some platforms, such as the Silicon Graphics SGI, don’t have a JVM 1.5 implementation, which is a shame…
Okay. What about amd64 systems? For example, ant may be compiled via jdk-1.5.(last). If we have java build systems, we can try use cvs or others method to get the sources for testing and/or make ebuilds. But now, after last emerge –sync (2006-09-01), portage try to download blackdown(64bit). This is incorrect….
hello,
nice explanation, but … I do not understand why should I install Java 1.4 even when I do not plan to use any of the old code?
see, I am not an Java expert … I was asked by a friend to set-up a server for testing his project – this is a new project, from scratch, no need to support older Java
then I do not understand the need for older Java? – if this is a requierement of some specific package, then why does not the package report “I need Java 1.4”, why the error message is written just like “you have to have Java 1.4 in Gentoo”?
… this is confusing for me – if the problem is only a few unmigrated packages, how can you know that I will need one of these and that I need to pull all the ballast of the older Java copy?
I don’t know how to better explain things without rehashing over what has been said already.
I suppose one of the key points is that you will run into problems if you try to compile generation-1 packages with >virtual/jdk-1.4, particularly when you have other packages depending on that package not having 1.5 or later bytecode.
Whether or not you will use Java 1.4 is kind of irrelevant. This is because for now, our build system needs 1.4 around to build some packages. It similar asking why you would need gcc on your Gentoo system if you never plan on compiling anything (from the perspective of a user of the gcc command). Since we do compile from source, you would need gcc to be able to build anything, because our build system necessitates it. It is not dissimilar for Java 1.4.
But in reality, given enough time, all packages will be migrated and stabilized, with unmigrated revisions getting dropped. Once that is done, it will only be packages which inheritly require Java 1.4, or have issues with any other version of Java. Hopefully, those will be packages on the fringe, and if we have the source, we should be able to fix them.
About updating unmigrated packages to depend on =virtual/jdk-1.4* specifically instead of >=virtual/jdk-1.4 (or whatever)… we believe that that time is better spent on just migrating the offending package.