Bugzilla Bug 69970

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
   mode.
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.

Karl,

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. 

there are some xslt scripts here, and also a python script that does it
http://www.gentoo.org/cgi-bin/viewcvs.cgi/javatoolkit/src/bsfix/?root=gentoo-src

its possible those are in the current release of dev-java/javatoolkit but i'm not sure

No luck anyway :o(

There are also some problems related to new methods in org.w3c.dom, and a quick googling doesnt reveal anything

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 

http://forums.gentoo.org/viewtopic-t-317253.html

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).

If you use
http://gentooexperimental.org/svn/java/axxo-overlay/

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
(axxo@gentoo.org)

We now have a FAQ for getting up and running with the overlay:
http://www.gentoo.org/proj/en/java/tiger-faq.xml#doc_chap3

*** Bug 105636 has been marked as a duplicate of this bug. ***

*** Bug 118813 has been marked as a duplicate of this bug. ***

*** Bug 119080 has been marked as a duplicate of this bug. ***

*** Bug 119682 has been marked as a duplicate of this bug. ***

*** Bug 119667 has been marked as a duplicate of this bug. ***

*** Bug 119665 has been marked as a duplicate of this bug. ***

*** Bug 119661 has been marked as a duplicate of this bug. ***

*** Bug 119660 has been marked as a duplicate of this bug. ***

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. 

(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.

The new Java system to support 1.5 has been unmasked. Marking fixed.

See the upgrade guide:
http://www.gentoo.org/proj/en/java/java-upgrade.xml