Summary: | All Java packages should be compliant with Java 1.5 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Karl Trygve Kalleberg (RETIRED) <karltk> |
Component: | Current packages | Assignee: | Java team <java> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | aaron, cgs, clmason, dmlloyd, evermind, gentoo+bugzilla, jgonzalez.openinput, Martin.vGagern, mathias.hasselmann, mmacleod, mslinn, nikolaymetchev, tehdanish |
Priority: | High | Keywords: | InVCS |
Version: | unspecified | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 79206, 127816 | ||
Bug Blocks: | 65937 |
Description
Karl Trygve Kalleberg (RETIRED)
2004-11-03 12:32:00 UTC
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 |