Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 69970 - All Java packages should be compliant with Java 1.5
Summary: All Java packages should be compliant with Java 1.5
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All All
: High normal (vote)
Assignee: Java team
Keywords: InVCS
: 105636 118813 119660 119661 119665 119667 119682 (view as bug list)
Depends on: 79206 127816
Blocks: 65937
  Show dependency tree
Reported: 2004-11-03 12:32 UTC by Karl Trygve Kalleberg (RETIRED)
Modified: 2006-06-30 19:42 UTC (History)
13 users (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Karl Trygve Kalleberg (RETIRED) gentoo-dev 2004-11-03 12:32:00 UTC
With the upcoming release of Java 1.5 (5.0, Tiger, whatever), we need to make certain that all packages can be built using the new SDK.

There are a few considerations:

1) If a package can be built with 1.4 and lower, its build.xml must state this
   explicitly by having source="1.4" target="1.4" in all its javac nodes.

2) If a package requries 1.5, its DEPEND must reflect that.

So, the guidelines for ensuring proper operation for a given package should be:

1) Determine the oldest JDK it can work with, and set this in DEPEND
2) Patch the build.xml file (perferrably we should have an XSLT script that
   can be applied easily in src_unpack for this) to set source="x.y" and
   target="x.y" on all javac nodes.
3) Test it with the oldest JDK it can support.
4) Submit a patch for the ebuild.

A few benefits to this:

1) An older package built with Sun JDK 1.5 will continue to work with with 1.4,
   as we explicitly tell the 1.5 compiler to operate in backwards compatible
2) We don't have to patch away "enum" and "assert" which are keywords added in
   the more recent SDK releases.
3) You can use the 1.5 SDK as your system VM and compile stuff while still have
   everything (except for really new packages that really require 1.5) running
   on a 1.3 or 1.4 user VM.
Comment 1 Jose Gonzalez Gomez 2005-01-29 04:07:29 UTC

Do you have that XSLT script available? I was going to manually patch xalan to try to get it working under 1.5, as it includes target="1.1" in all its javac tasks, but then I found this bug. If I don't get an answer from you in a few hours I'll patch it anyway, as I need it urgently. Tell me if you want me to file a bug with the patch. 
Comment 2 Thomas Matthijs (RETIRED) gentoo-dev 2005-01-29 04:43:40 UTC
there are some xslt scripts here, and also a python script that does it

its possible those are in the current release of dev-java/javatoolkit but i'm not sure
Comment 3 Jose Gonzalez Gomez 2005-01-29 11:31:17 UTC
No luck anyway :o(

There are also some problems related to new methods in org.w3c.dom, and a quick googling doesnt reveal anything
Comment 4 kustos 2005-04-30 03:28:16 UTC
I also created an xslt stylesheet that should fix any build.xml I can think of.

It just modifies the javac elements:
- For those that already have a source (and optional target) attribute it sets target to the same value.
- For those that alreday have a target (but no source) attribute it sets source to the same value.
- For those that have neither it sets source and target to 1.4.

All the other elements are copied with their attributes
Comments are stripped
Comment 5 Mason 2005-05-04 21:16:25 UTC
An interm solution could simply be a "java 1.5 compat" ebuild that is nothing but a set of shell script wrappers around the "real" java calls (/opt/gentoo-1.5.compat/bin/javac --> /opt/sun-jdk-1.5.0/bin/javac) and defaulting the "--source" attribute to 1.4 (or 1.3 even if that is required).
Comment 6 Thomas Matthijs (RETIRED) gentoo-dev 2005-09-10 11:26:48 UTC
If you use

Everything should work with 1.5

but be very carefull if you use that, since it has some huge changes on how java 
is handled (we are working on some documentation for it)

if you are brave and try it please email me with _any_ feedback
Comment 7 Josh Nichols (RETIRED) gentoo-dev 2005-12-11 18:22:16 UTC
We now have a FAQ for getting up and running with the overlay:
Comment 8 Josh Nichols (RETIRED) gentoo-dev 2005-12-23 17:53:48 UTC
*** Bug 105636 has been marked as a duplicate of this bug. ***
Comment 9 Josh Nichols (RETIRED) gentoo-dev 2006-01-12 14:15:18 UTC
*** Bug 118813 has been marked as a duplicate of this bug. ***
Comment 10 Jakub Moc (RETIRED) gentoo-dev 2006-01-15 05:45:03 UTC
*** Bug 119080 has been marked as a duplicate of this bug. ***
Comment 11 Josh Nichols (RETIRED) gentoo-dev 2006-01-20 06:08:05 UTC
*** Bug 119682 has been marked as a duplicate of this bug. ***
Comment 12 Josh Nichols (RETIRED) gentoo-dev 2006-01-20 06:08:23 UTC
*** Bug 119667 has been marked as a duplicate of this bug. ***
Comment 13 Josh Nichols (RETIRED) gentoo-dev 2006-01-20 06:08:38 UTC
*** Bug 119665 has been marked as a duplicate of this bug. ***
Comment 14 Josh Nichols (RETIRED) gentoo-dev 2006-01-20 06:08:51 UTC
*** Bug 119661 has been marked as a duplicate of this bug. ***
Comment 15 Josh Nichols (RETIRED) gentoo-dev 2006-01-20 06:09:07 UTC
*** Bug 119660 has been marked as a duplicate of this bug. ***
Comment 16 Mike Slinn 2006-01-26 13:08:43 UTC
Two points:
 1) It might be easier to alter the emerge scripts to force the appropriate Java compiler instead of altering the build.xml scripts.  The emerge script is specific to Gentoo, and could be tweaked such that JDK 1.4.2's javac is used instead of JDK 5.0's javac, when required.  The build.xml files come from a wide variety of projects, and the less mods required for Gentoo, the faster they can be adopted by Gentoo users.  For example, dev-java/javacc-3.2-r3 has a hierarchy of build.xml scripts, none of which would need modification provided JDK 1.4.2 is used to build them.  If the emerge script were beefed up, responsibility for testing the build.xml scripts would revert back to the originating projects.
 2) Many jars need to be built to be compatible with more than one JDKs.  For example, Xerces is commonly required.  It would be best to build these packages with the lowest common JDK for compatibility, or the user will see an error message like:
java.lang.UnsupportedClassVersionError: org/apache/xerces/jaxp/SAXParserFactoryImpl (Unsupported major.minor version 49.0)

However, some jars require JDK 5.0 (and soon, JDK 6.0).  These packages cannot be in the classpath when an older JDK is used.  Thus /etc/env.d/20java might need to be enhanced with some sort of conditional test so when a package is being build with -source=1.4 -target=1.4 (or -source=1.5 -target=1.5) so that only appropriate jars are included in the classpath.  I don't know how the slot mechanism works in detail, but I expect that it might provide support for the solution. 
Comment 17 Martin von Gagern 2006-01-26 15:06:37 UTC
(In reply to comment #16)
Your ideas, that is merge time selection of lowest possible VM as well as an extended VM configuration, are already implemented in the overlay mentioned in comment #6. Please read the FAQ from comment #7.
When this overlay gets merged into the main portage tree, those features will become available for everybody.
Comment 18 Josh Nichols (RETIRED) gentoo-dev 2006-06-30 19:42:06 UTC
The new Java system to support 1.5 has been unmasked. Marking fixed.

See the upgrade guide: