| Summary: | [METABUG] packages which won't work with jdk 1.5 (yet) | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Jan Brinkmann (RETIRED) <luckyduck> |
| Component: | New packages | Assignee: | Java team <java> |
| Status: | RESOLVED INVALID | ||
| Severity: | normal | CC: | alex, Anardil, anfini, anticodebr, bdonlan, beech, carlos_vendraminibr, chrb, christian, chutz+bugs.gentoo.org, dev-zero, dyurne, ed, eugine.kosenko, gentoo, hubner.radek, ikelos, k.epost, khaelin, kurt, lukenshiro, luto, mail, mholzer, nikolaymetchev, pauldv, pbodymind, pva, rohan, sac, scarr, schwientek, sschlueter, tps, tsabi-gentoo, wiktorw, wolfhead_gbz |
| Priority: | High | Keywords: | InVCS, Tracker |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 69970 | ||
| Attachments: |
"emerge log4j > log4j.txt 2>&1"
emerge -u log4j commons-pool-1.2-java5.patch jss-3.4-java5.patch xerces-2.3.0-java5.patch gnu-jaxp-1.3-java5.patch log4j-1.2.11-java5 commons-net-1.2 avalon-logkit-1.2.java5.patch bcprov-1.31.ebuild bcprov-1.31.ebuild bcprov-1.31.ebuild bcprov-1.31.ebuild bcprov-1.31.ebuild bcprov-1.31.ebuild |
||
|
Description
Jan Brinkmann (RETIRED)
2005-01-23 06:04:40 UTC
JasperReports can be added to this list as well. The Ebuild fails with -Xlint-deprecation and -Xlint-unchecked as needed compile time flags. How about adding a "jdk15" use flag? This could then be checked and if active, the required compile flags could be added to the ant build. that is not the problem actually, the jdk 1.5 introduces new methods for example which have to be overloaded when a class inherits from a class with these methods. it's not as easy to fix as it sounds. sys-libs/db-3.2.9-r10 (#79114) with USE="java" JasperReports works now after Bug #79540 is added. It bring JasperReports to 0.6.4 and compiles correctly. *** Bug 83469 has been marked as a duplicate of this bug. *** *** Bug 85070 has been marked as a duplicate of this bug. *** *** Bug 85652 has been marked as a duplicate of this bug. *** *** Bug 82886 has been marked as a duplicate of this bug. *** Freemind doesn't compile with JDK 1.5 due to enum being used as an identifier in a few isolated spots in one of the source files. Is this best handled by passing source and target of 1.4 or should I simply submit a patch for the offending file? not necessary, we rewrite the build.xml file on the fly in the future. when we're ready to unmask 1.5, that should work it of the box without patching. thanks anyways. dev-java/bsh-2.0_beta2 dev-java/commons-logging-1.0.4-r1 dev-java/xalan-2.6.0-r2 *** Bug 87328 has been marked as a duplicate of this bug. *** *** Bug 87344 has been marked as a duplicate of this bug. *** *** Bug 87497 has been marked as a duplicate of this bug. *** *** Bug 88359 has been marked as a duplicate of this bug. *** dev-java/commons-net (version 1.2.2-r1) -- sac7352 (at) rit (dot) edu The tracker keyword makes it easier to find this bug. dev-java/gnu-crypto-2.0.1 does not compile In addition, dev-java/commons-net-1.3.0-r1 does compile (though as already noted, 1.2.2 doesn't). *** Bug 88571 has been marked as a duplicate of this bug. *** *** Bug 88827 has been marked as a duplicate of this bug. *** *** Bug 89741 has been marked as a duplicate of this bug. *** For succesfully compiling xalan-2.6.0-r2 on java1.5 use patch at http://bugs.gentoo.org/show_bug.cgi?id=67244 *** Bug 90297 has been marked as a duplicate of this bug. *** *** Bug 89940 has been marked as a duplicate of this bug. *** Jan, When is the rewrite on the fly for build.xml going to be available for packages? Is there anything I can help on with this? The rewriting component has already been written. Is it in place somewhere, so I can start playing with it? You state that these packages do not compile with jdk 1.5 and have listed many bugs and dups to this one but at least one issue has accidentally been captured by this bug. gnu-crypto-2.0.1 will not compile with the blackdown-jdk-1.4.2.01. I don't use java 1.5 yet but I'm having issues on a production machine with updating this. Mathew: But bug 88538 about gnu-crypto hasn't been marked as a duplicate of this bug? *** Bug 90702 has been marked as a duplicate of this bug. *** dev-java/jdbc3-postgresql-8.0_p311 failed. too! dev-java/commons-el-1.0 works with dev-java/sun-jdk-1.5.0.03 dev-java/log4j-1.2.8-r1 works with dev-java/sun-jdk-1.5.0.03 jaxen 1.0 (tomcat 5.0.28 deps) doesn't work *** Bug 93098 has been marked as a duplicate of this bug. *** The package dev-java/ant-owanttask-1.1-r1 also fails to compile with JDK 1.5.
If someone can't wait until the generic build.xml rewriter is ready, this
simple addition to the ebuild solves the problem:
src_unpack() {
unpack ${A}
cd ${S}/src/org/objectweb/util/ant
sed -i 's/enum/e/g' JavadocMultipleLink.java
}
*** Bug 94183 has been marked as a duplicate of this bug. *** I have a question. Why dev-java/log4j-1.2.9 marked as stable, when it's not working with jdk-1.5.x(https://bugs.gentoo.org/show_bug.cgi?id=94183), although previous version of dev-java/log4j-1.2.8-r1 works without problems? because we still dont support the jdk1.5, we now that things dont work with it. that's the reason why it's hardmasked *** Bug 94613 has been marked as a duplicate of this bug. *** *** Bug 94849 has been marked as a duplicate of this bug. *** What is the status of this bug? Should source patches still be pursued, or are we simply waiting on bug 86903 (in which case it should be added to this bug's dependency list...) ? Too BSH, try the version 2.0_beta4 in bug #94987 Guys, will you be accepting patches to various java packages. I've been busy today and made some dependencies for netbeans (including tomcat) compile on 1.5 Created attachment 60835 [details]
"emerge log4j > log4j.txt 2>&1"
Maybe it is helpfull finding the error with log4j and Java 1.5
The error for log4j is quite simple actually. It can't find the com.sun.jdmk.comm.HtmlAdaptorServer class. This is probably a sun internal class that was used in old versions of the jmx package that is now included in the jdk slightly differently. *** Bug 95388 has been marked as a duplicate of this bug. *** Somehow, the jmx-jars (installed under /usr/share/jmx/lib) seem not to be added to classpath. So java does not find the com.sun.jmdk.comm.HtmlAdaptorServer class even it is still in JMX. With JMX-Jars copied to /opt/sun-jdk-1.5.0.03/jre/lib/ext/ the build of log4j works a charm. The "jmx-jars" from post #51 aren't present on my box. So I downloaded the reference implementation 1.2.1 from here: http://java.sun.com/products/JavaManagement/download.html and extracted the "jmxtools.jar" from the zip archive to "/opt/sun-jdk-1.5.0.03/jre/lib/ext/" - the build of log4j works a charm. batik 1.5.0 doesn't compile # java -version java version "1.5.0_03" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_03-b07) Java HotSpot(TM) Client VM (build 1.5.0_03-b07, mixed mode) # emerge sync ... Can't compile: [ebuild N ] dev-java/gnu-crypto-2.0.1 -doc 0 kB [ebuild N ] dev-java/xalan-2.6.0-r2 -doc -jikes -source 0 kB [ebuild N ] dev-java/log4j-1.2.9 -doc -javamail -jikes -jms -jmx -source 0 kB avalon-logkit-1.2 requires following patch to compile with JDK 1.5.x:
--- LogKit-1.2/build.xml 2003-02-10 19:12:55.000000000 +0100
+++ LogKit-1.2.patched/build.xml 2005-07-10 12:51:16.000000000 +0200
@@ -327,8 +327,7 @@
destdir="${build.classes}"
debug="${debug}"
optimize="${optimize}"
- deprecation="${deprecation}"
- target="1.2">
+ deprecation="${deprecation}">
<classpath>
<path refid="project.class.path" />
<path refid="tools.class.path"/>
Did someone unmask something lately? Today I did an emerge world and it failed on avalon-toolkit (fix included in previous comment), then it failed on log4j. I don't have anything java related in /etc/portage/package.keywords, so I did not expect any failures. I think my problem was triggered by jdbc-mysql which got upgraded to 3.0.16 (from 3.0.11). The new version pulled ant as a dependency which pulled a million packages, including the failing ones. Just a heads-up to mask back whatever you unmasked. This is on amd64. unless you are totaly misplaced that last comment and are infact not using 1.5, please go mask 1.5 again and recompile all java java packages on your system Ah, so there *is* a jdk that's stable on amd64. I sort of assumed that sun-jdk is *the* java. Apologies for the unrelated post. dev-java/log4j-1.2.9 compiles with JDK 1.5 if you have JMX installed. Unfortunately you need to register on Sun site to download JMX. Non-working ebuilds: [ebuild NS ] dev-java/avalon-logkit-1.2 -doc -javamail -jikes -jms -source [ebuild U ] dev-java/commons-logging-1.0.4-r1 [1.0.4] -avalon -doc -jikes -source (depends on avalon-logkit-1.2) [ebuild U ] dev-java/commons-net-1.2.2-r1 [1.2.2] -doc -jikes -source [ebuild N ] dev-java/gnu-crypto-2.0.1 -doc [ebuild U ] dev-java/xalan-2.6.0-r2 [2.6.0-r1] -doc -jikes -source dev-java/commons-logging-1.0.4-r1 will compile if you change the dependency from =dev-java/avalon-logkit-1.2 to >=dev-java/avalon-logkit-1.2 to comment #59: jmx is not be the only missing dependancy. log4j does not compile if jmx is installed. There are other missing packages (see attachement). Created attachment 65887 [details]
emerge -u log4j
If xalan is bumped to version 2.7.0 (bumped the ebuild version and for my purposes i ripped out the doc line in the package src) it will build under tiger / 1.5 / j2SE5 / the VM formally known as prince..... A slightly bigger question is why are is avalon-logkit still being built and supported since the avalon project has closed down and has been finished for sometime now, commons-logging will build (albeit with warnings) without avalon-logkit. Created attachment 66376 [details, diff]
commons-pool-1.2-java5.patch
Patch to get commons pool to work with Java 5
Created attachment 66388 [details, diff]
jss-3.4-java5.patch
patch to get jss-3.4 built with java 5
Created attachment 66390 [details, diff]
xerces-2.3.0-java5.patch
patch to build xerces-2.3.0 with java 5
Created attachment 66395 [details, diff]
gnu-jaxp-1.3-java5.patch
patch to build gnu's jaxp with java 5
log4j-1.2.12 http://cvs.apache.org/builds/logging/log4j/log4j-1.2.12 looks like this is close to release, it builds fine with the 1.5 JDK, just a simple copy/rename of the log4j-1.2.11 ebuild worked for me. Created attachment 67322 [details, diff]
log4j-1.2.11-java5
patches build.xml:
* added source="1.2" to all javac calls
* changed check from javax.management.MBeanInfo to
com.sun.jdmk.comm.HtmlAdaptorServer
The latter is necessary since MBeanInfo is now part of the core API, but the
JMX part of log4j uses HtmlAdaptorServer, which is only available if the USE
flag jmx was set.
Now log4j works for me, with and without USE=jmx. Still a lot of deprecation
messages, but they should be no immediate problem here. I will propose this
patch upstream as well.
There's another solution to the problem: modify src_unpack:
src_unpack() {
unpack ${A}
cd ${S}
rm -rf dist/
if java-utils_is-vm-version-ge 1 5 0 -a ! use jmx; then
sed -i -e 's/if="jmx/if="jmx-die/' build.xml
fi
}
Of course it requires:
inherit java-utils
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) While emerging jboss I've found that dev-java/gnu-crypto-2.0.1 still doesn't compile under sun-jdk-1.5.0.04 Switching for a moment to the sun-jdk-1.4.2.09 did the trick: # java-config -S sun-jdk-1.4.2.09 # /usr/sbin/env-update && source /etc/profile # emerge -av1 gnu-crypto # java-config -S sun-jdk-1.5.0.04 # /usr/sbin/env-update && source /etc/profile I'm afraid I'll have to report
www-servers/jboss-3.2.5
as another package which doesn't compile with the jdk 1.5.
The problem is obvious:
====== BEGIN QUOTE ======
_default:compile-classes:
[mkdir] Created dir:
/var/tmp/portage/jboss-3.2.5/work/jboss-3.2.5-src/common/output/classes
[javac] Compiling 221 source files to
/var/tmp/portage/jboss-3.2.5/work/jboss-3.2.5-src/common/output/classes
[execmodules] javac: target release 1.2 conflicts with default source release 1.5
BUILD FAILED
/var/tmp/portage/jboss-3.2.5/work/jboss-3.2.5-src/tools/etc/buildmagic/buildmagic.ent:406:
Compile failed; see the compiler error output for details.
====== END QUOTE ======
Switching for a moment to the sun-jdk-1.4.2.09 (as in the previous comment)
did the trick again.
*** Bug 107382 has been marked as a duplicate of this bug. *** Regarding http://bugs.gentoo.org/show_bug.cgi?id=79206#c73 Jboss v. 3.2.x only runs with Java > 5.0 but does not does not compile with it according to: http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossVsJavaJDKVersionMatrix So this is fixed upstream for latter Jboss versions but the one in portage will newer work with Java 5.0. Hopefully this does not mean that we will wait (infinitely) for Jboss 3.2.x to compile with Java 5.0. Lets move ahead and make the Jboss ebuild depend on Java 1.4.x instead on it holding the great 5.0 back. Regarding http://bugs.gentoo.org/show_bug.cgi?id=79206#c72: Quote from the gnu crypto website: "Building the library this way [with gcc gcj] ]is the best (and in some cases, the only) way when compiling and linking native applications" http://www.gnu.org/software/gnu-crypto/#build So why does it not depend only on gcj instead of holding sun java 5.0 back when the people who develop gnu crypto actually think that only gcj should be used (and sometimes only can be used)? (In reply to comment #76) > Regarding http://bugs.gentoo.org/show_bug.cgi?id=79206#c72: > Quote from the gnu crypto website: > "Building the library this way [with gcc gcj] ]is the best (and in some cases, > the only) way when compiling and linking native applications" > Of course it is the best option when compiling to native code but we don't do that yet because gcj is usable only with the latest of the latest off the gcc versions. Redhat even uses their special branch. It still takes a while before we even get that stuff out of package.mask I think. > > http://www.gnu.org/software/gnu-crypto/#build > > > So why does it not depend only on gcj instead of holding sun java 5.0 back when > the people who develop gnu crypto actually think that only gcj should be used > (and sometimes only can be used)? People who develop gnu crypto think that people should only use free as in freedom software and there is of course nothing wrong with that. And there is the additional problem that we can't depend on gcj because there are no use based dependencies yet and gcj is just a use flag of gcc. (Coming with the next major version of Portage). If you want to speedup things you could help us make an ebuild wich builds and installs only the parts of needed to run gcj. I think there is a bug about that open or some work already somewhere but I can't remember where from the top of my head. Hmm, I understand your point of view, but from where I stand this is all gnu crypto stuff which should not prohibit Java 5 from becoming stable in portage. What if a program only compiles with gcc-2.9*. Are we then going to declare gcc-3* unstable? Where is the borderlinie? closing, not so usefull bug anymore, use the other 1.5 bugs only usefull to have bugs on them if they don't work after -target/-source fixing *** Bug 111708 has been marked as a duplicate of this bug. *** *** Bug 116075 has been marked as a duplicate of this bug. *** *** Bug 122008 has been marked as a duplicate of this bug. *** Created attachment 79137 [details, diff]
commons-net-1.2
avoids javac-1.5 to exit on syntax error when using variables named enum by
telling it to assume source as java-1.4 complient.
This is done by adding the attribute source="1.4" to the javac-tag of the build.xml
Created attachment 79138 [details, diff]
avalon-logkit-1.2.java5.patch
fixes crash of javac as to target-version problem.
Default set to 1.2 by the avalon-logkit, which conflicts with the default target-version of 1.5.
Simply solved by removing the target-attribute from the javac-tag in the build.xml
Comment on attachment 79137 [details, diff]
commons-net-1.2
fixes the enum variable name problem between sources for version 1.4 compiled with javac 1.5
Surley a dumb question but will these patches be included in future ebuilds? Because emerge --sync removes them again from the local system :-) This bug is RESOLVED INVALID. Please take a look at http://www.gentoo.org/proj/en/java/ *** Bug 123705 has been marked as a duplicate of this bug. *** (In reply to comment #86) > Surley a dumb question <poke_fun> Surely. ;-) </poke_fun> > but will these patches be included in future ebuilds? > Because emerge --sync removes them again from the local system :-) Read this first (regarding PORTDIR_OVERLAY): http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=3&chap=5 If you want the pathes to be applied you need to put the modified ebuilds in the overlay directory of your choice. How to modify the ebuilds to automatically apply patches is left as an exercise to the reader. ;-P *** Bug 124049 has been marked as a duplicate of this bug. *** Jaxen 1.1_beta compiles fine with sun-jdk-1.5.0.06 - ebuild is here http://bugs.gentoo.org/show_bug.cgi?id=124051. Also have a CVS ebuild for dom4j http://bugs.gentoo.org/show_bug.cgi?id=124049 which works with sun-jdk-1.5.0.06. *** Bug 125227 has been marked as a duplicate of this bug. *** Created attachment 82246 [details]
bcprov-1.31.ebuild
Bcprov also comes in a jdk15 version - the current ebuild looks for a jdk14 version.
Created attachment 82247 [details]
bcprov-1.31.ebuild
Bcprov also comes in a jdk15 version - the current ebuild looks for a jdk14 version.
Created attachment 82248 [details]
bcprov-1.31.ebuild
Bcprov also comes in a jdk15 version - the current ebuild looks for a jdk14 version.
Created attachment 82249 [details]
bcprov-1.31.ebuild
Bcprov also comes in a jdk15 version - the current ebuild looks for a jdk14 version.
Created attachment 82250 [details]
bcprov-1.31.ebuild
Bcprov also comes in a jdk15 version - the current ebuild looks for a jdk14 version.
Created attachment 82251 [details]
bcprov-1.31.ebuild
Bcprov also comes in a jdk15 version - the current ebuild looks for a jdk14 version.
*** Bug 126652 has been marked as a duplicate of this bug. *** *** Bug 124845 has been marked as a duplicate of this bug. *** *** Bug 128347 has been marked as a duplicate of this bug. *** (In reply to comment #77) > People who develop gnu crypto think that people should only use free as in > freedom software and there is of course nothing wrong with that. Does it mean, that gnu crypto will *never* work with Java 5? Is it safe to use gnu crypto, compiled successfully with blackdown jdk 1.4, with sun jdk 1.5? *** Bug 129693 has been marked as a duplicate of this bug. *** *** Bug 129512 has been marked as a duplicate of this bug. *** *** Bug 131401 has been marked as a duplicate of this bug. *** *** Bug 132911 has been marked as a duplicate of this bug. *** *** Bug 132917 has been marked as a duplicate of this bug. *** *** Bug 132918 has been marked as a duplicate of this bug. *** |