Re: [Slightly OT] Oracle JDK and utilities crash on Debian Wheezy, Squeeze and now stretch.
On 12/07/17 16:55, shirish शिरीष's friend wrote: > OpenJDK has more problems with application crasheswhich I > was using as my default JRE but later I had to switch because of > frequent crashes > , > which is fixed by switching to Oracle JDK and Oracle JDK has more > classes than OpenJDK. And it's always better to use Oracle JDK when > developing the web application as it is more stable and thoroughly > tested. And the problem is from JDK 8 onwards up to 7 there are no > crashes. As my application needs JDK8 so can't go for 7. Today I have > installed Linux mint parallelly on my system and seems like there are > no crashes up to now with same JDK, Tomcat, Eclipse and Browsers > combination. So, the issue is related to Debian Jessie and Stretch. This sort of message is extremely damaging to free software. The horrible thing is that we can't do anything about it without reproducible bug reports. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. <https://www.redhat.com> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
Re: JMAP tool broken since openjdk-7 version 7u92?
On 31/01/17 18:35, Matthew Patton wrote: > I ran across this bug report > (https://bugs.launchpad.net/ubuntu/+source/openjdk-7/+bug/1548434) and it > seems in Wheezy/Jessie it's likewise. The last functional version I just so > happened to hold onto is 7u79-2.5.5-1~deb7u1. > > The following are confirmed to throw an Exception > * 7u111-2.6.7-2~deb8 > * 7u121-2.6.8-1~deb7u1 > * 7u95-2.6.4-1~deb7u1 > > Here is an example run with 7u121 - http://pastebin.com/tzRk7xTH Please come over to jdk7u-...@openjdk.java.net. Andrew.
Re: java outlook for stretch and buster
On 10/09/16 14:28, Matthias Klose wrote: > On 10.09.2016 12:28, Andrew Haley wrote: >> On 10/09/16 11:09, Matthias Klose wrote: >> >>> The ARM32 port already is in an upstream repository, and I'm told >>> that the s390x is on it's way. Even if these ports will not be >>> merged before openjdk-10, it's my intent to build these from their >>> branches, as done in the past with the AArch64 and PPC64 port. >> >> We should perhaps be looking at proper stable release branches for these, >> as we have for AArch64. >> >> http://hg.openjdk.java.net/aarch64-port/jdk8u/ is a clone against a >> tag of the upstream stable jdk8u, but with AArch64 added. The diffs >> from upstream are as small as we can possibly make them. > > It would be nice if the branch could be kept up to date. Usually it's only > updated after a security update, however I'd like to see the merge for the > base > of the next security update (in this case jdk8u112-b04) be done before the > security update. Sure, that's a matter of negotiation. Andrew Hughes does this job. > It would not be a problem, if providers of security updates > would be allowed to share their work, but my understanding is this is yet not > allowed. I don't really understand what point you're making here, so I can't reply. Andrew.
Re: java outlook for stretch and buster
On 10/09/16 11:09, Matthias Klose wrote: > The ARM32 port already is in an upstream repository, and I'm told > that the s390x is on it's way. Even if these ports will not be > merged before openjdk-10, it's my intent to build these from their > branches, as done in the past with the AArch64 and PPC64 port. We should perhaps be looking at proper stable release branches for these, as we have for AArch64. http://hg.openjdk.java.net/aarch64-port/jdk8u/ is a clone against a tag of the upstream stable jdk8u, but with AArch64 added. The diffs from upstream are as small as we can possibly make them. Andrew.
Re: Making OpenJDK 7 the default in Wheezy-LTS
On 24/03/16 19:03, Markus Koschany wrote: > Wheezy-LTS is going to start next month and there is the intention to > switch the default-jre|jdk from OpenJDK 6 to OpenJDK 7 because the > latter can be supported until Wheezy reaches EOL in 2018-05-31. Yes! Good call. While we are still supporting OpenJDK 6 and making security releases, it is always the last in the queue when there is urgent work to be done, and for this reason may be subject to delays. Andrew. (OpenJDK 6 project lead.) signature.asc Description: OpenPGP digital signature
Re: Re: OpenJDK 8 vs Zulu
On Mon, Jan 19, 2015 at 10:41 PM, Andrew Haley wrote: That would be against the rules AFAICR: you're supposed to do your own TCK runs, and not on behalf of someone else. How do automated builds factor into that? I don't think it makes any difference. But IANAL, and you'd have to read the TCK agreement for more information. You can't run a full TCK as part of an automated test anyway, because there are some interacive tests. Andrew. -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54c1051f.80...@redhat.com
Re: OpenJDK 8 vs Zulu
On 01/22/2015 02:23 PM, Paul Wise wrote: On Thu, Jan 22, 2015 at 10:11 PM, Andrew Haley wrote: On Mon, Jan 19, 2015 at 10:41 PM, Andrew Haley wrote: That would be against the rules AFAICR: you're supposed to do your own TCK runs, and not on behalf of someone else. How do automated builds factor into that? I don't think it makes any difference. But IANAL, and you'd have to read the TCK agreement for more information. I mean, if an automated system builds the binary packages rather than a human developer, who is allowed to test those packages? Ah, I see the confusion. By you I mean you as in Debian; i.e. an organization is supposed to use the OpenJDK TCK to test the binaries they ship. I don't think that people or organizations are allowed to set up a TCK testing service for other people's OpenJDK builds. But, again, IANAL: the details are in the TCK agreement. Andrew. -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54c109e8.3080...@redhat.com
Re: OpenJDK 8 vs Zulu
On 19/01/15 11:35, Emmanuel Bourg wrote: I've requested an access to the TCK for Java 8 in June to run it on the Debian packages but I haven't heard back from Oracle yet. I'd ping them again. Andrew. -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54bd17a6.6050...@redhat.com
Re: OpenJDK 8 vs Zulu
On 19/01/15 00:20, Paul Wise wrote: If there are individuals who have access to the TCK and could validate the package and file bugs, that would be great. That would be against the rules AFAICR: you're supposed to do your own TCK runs, and not on behalf of someone else. Andrew. -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54bd1794.5020...@redhat.com
Re: problem with java - debian
On 04/11/2014 11:24 AM, Geert Stappers wrote: Op 2014-04-11 om 11:38 schreef mohamad.most...@uni-ulm.de: Hi, I am trying to install matlab under Linux and I am facing the following message Preparing installation files ... Installing ... Error occurred during initialization of VM Could not reserve enough space for object heap Could not create the Java virtual machine. Finished Running apt-cache depends default-jdk yields default-jdk Depends: default-jre Depends: openjdk-6-jdk Something is definitely wrong with java. I have been trying for long time to know what is wrong here, however I still could not solve the problem. Being presistent is good. Could you help me. My gut feeling is low memory. Please provide the output of head /proc/meminfo Also check /proc/sys/vm/overcommit_memory Andrew. -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5347f773.40...@redhat.com
Re: Replacing openjdk-6 with gcj-jdk as default java for mips{,el}
On 11/13/2013 12:29 AM, Aurelien Jarno wrote: Hi, On Sat, Nov 09, 2013 at 02:35:49PM +0100, Niels Thykier wrote: Hi, (With my Java hat on and my Release hat off) We are getting close to being able to remove openjdk-6 from sid and testing. However, there is major blocker, which is java-common itself (and its default-* binaries). mips and mipsel are the only two architectures still using OpenJDK 6 as default java. At the current time, OpenJDK 7 have not been successfully ported on these architectures and it is my understanding that it is unlikely to change in the near future. This leaves gcj-jdk as the only viable option for mips and mipsel. I have finally been able to fix openjdk-7 on mips and mipsel. It was a problem of ugly casts done without taking care of alignement issues. See bug #729448 for more details. I need to prepare a patch for current HotSpot. Unless you have signed the OCA I'll have to do this work myself. I'm trying to get access to a box that needs strict alignment. Andrew. -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/529472ab.1060...@redhat.com
Re: openjdk-7 for kfreebsd
On 11/13/2013 07:45 PM, Steven Chamberlain wrote: On 11/13/2013 12:29 AM, Aurelien Jarno wrote: I have finally been able to fix openjdk-7 on mips and mipsel. Brilliant! On 13/11/13 09:10, Andrew Haley wrote: That's an odd patch. FWIW it looks right to me that something like this would trigger SIGBUS when hotspot is run during mips(el) builds or possibly sparc. I'd like to get this fixed upstream. Debian Java maintainers might also insist on that, before considering openjdk-7 as default java. Sorry to jump in on a thread about mips, but on kfreebsd we are also looking to switch to openjdk-7 as soon as possible. And we were advised to send our patches upstream also. I'd appreciate any advice on how to go about doing that. Talk to me. Ideally we could consistently have openjdk-7 as default on all of Debian's release arches and be moving *away* from gcj-jdk. Sure. So, what have you got? Andrew. -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52849762.6020...@redhat.com
Re: openjdk-7 for kfreebsd
On 11/14/2013 11:53 AM, Steven Chamberlain wrote:
Hi Andrew,
On 14/11/13 09:26, Andrew Haley wrote:
[...] on kfreebsd we are also looking to switch to openjdk-7 as
soon as possible. And we were advised to send our patches
upstream also. I'd appreciate any advice on how to go about doing
that.
Talk to me.
Thank you!
Debian applies four patches to openjdk-7 for kfreebsd support, including
some bits I don't expect to be appropriate for upstream, but I propose
to split some bits out:
-#ifdef __linux__
+#if defined(__linux__) || defined(__GLIBC__)
We have dozens of these for example - that kind of ifdef is ambiguous as
to whether it expects the Linux kernel or just a Linux-like userland
which is true also of GNU/kFreeBSD, GNU/Hurd and potentially other glibc
ports.
We also have a handful of these in the patches mentioned below - though
I propose to match on startsWith(GNU), in anticipation that GNU/Hurd
(osname=GNU?) may someday want to use the same code:
if (osname.startsWith(SunOS) ||
+ osname.startsWith(GNU/kFreeBSD) ||
osname.startsWith(Linux)) {
These two patches are fairly straightforward, enabling build system support:
http://patch-tracker.debian.org/patch/series/view/openjdk-7/7u25-2.3.12-4/kfreebsd-support-corba.diff
http://patch-tracker.debian.org/patch/series/view/openjdk-7/7u25-2.3.12-4/kfreebsd-support-jamvm.diff
The final two patches consist of largely the ifdef changes mentioned
above. Some other parts look clearly objectionable. e.g. I expect you
don't want to add large blocks of (largely duplicated) kfreebsd-specific
code to src/os/linux/*:
http://patch-tracker.debian.org/patch/series/view/openjdk-7/7u25-2.3.12-4/kfreebsd-support-hotspot.diff
http://patch-tracker.debian.org/patch/series/view/openjdk-7/7u25-2.3.12-4/kfreebsd-support-jdk.diff
Hmm. Some of these are simple enough, but others require more careful
handling.
To begin with: anything not utterly trivial in OpenJDK requires
copyright assignment. I can push simple patches, but this doesn't
look so simple. If someone is prepared to sign Oracle's contributor
agreement and submit these patches, it can be done.
Andrew.
--
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5284c71f.3040...@redhat.com
Re: Replacing openjdk-6 with gcj-jdk as default java for mips{,el}
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 11/13/2013 12:29 AM, Aurelien Jarno wrote: I have finally been able to fix openjdk-7 on mips and mipsel. It was a problem of ugly casts done without taking care of alignement issues. See bug #729448 for more details. With the patch from the bug report applied, I was able to get a fairly decent testsuite result on both mips and mipsel (see below), comparable to the other architectures using zero and for which the testsuite is not disabled. That's an odd patch. Is there a discussion of this somewhere, or can we take this discussion to the Debian Java List only? I'd like to get this fixed upstream. Andrew. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJSg0H1AAoJEKXNYDUzL6ZxlVQH/1Rd7CbMmrLRxaO+QeEoLqGX b4wWu3ww9FOXUca2/Lh2c7rdDKXTyKU6GTfKC7BrFaGNrlmt6c36v6VqEmJwGbRc lfa9vk6slywOQQiLkislx0VhFp9p8NhcMw2+bTwjJGUaPx/vVT+pRJ5kIV34QEYU 9zfUvA30oSHQF6YOoB7M/XlJo5bcoKPZblBnCqz0Wb+knecFVYStRTkPoxnWnyav /YCozl5V/HJGU1+bUrex1UG6w93hy6GRRQXfxFUN8A3W6sg9hOpYGo8HmpByvXm3 lZa65u6BSIQgTfz4WvFdUX2YhzhjjkpvbW3V9jH7ivAZGaqRJcyj5yMUfS2moww= =E27Q -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/528341f5.70...@redhat.com
Re: Runtime JVM != compile time JDK - acceptable?
On 09/20/2013 08:48 AM, Emmanuel Bourg wrote: Le 20/09/2013 08:50, Florian Weimer a écrit : Is this a bug in Netbeans or OpenJDK 6? If the latter, has it been fixed upstream? This is an OpenJDK 6 bug. It has been reported upstream and promptly closed as 'Won't Fix'. https://bugs.openjdk.java.net/browse/JDK-8021890 I reopened the bug. I still don't understand what the bug actually is, though. Antonín Nebuželský seems to have analysed it, but I can't find an analysis anywhere. Andrew. -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/524fc9e5.8090...@redhat.com
Re: Runtime JVM != compile time JDK - acceptable?
On 09/20/2013 08:48 AM, Emmanuel Bourg wrote: Le 20/09/2013 08:50, Florian Weimer a écrit : Is this a bug in Netbeans or OpenJDK 6? If the latter, has it been fixed upstream? This is an OpenJDK 6 bug. It has been reported upstream and promptly closed as 'Won't Fix'. It's not marked as 'Won't Fix' by me, and I'm the OpenJDK 6 lead. If anyone has a fix we'll look at it. Andrew. -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/524a931f.1010...@redhat.com
Re: Release Goal: Switch to OpenJDK7
On 08/19/2013 01:13 PM, Andreas Kuckartz wrote: OpenJDK6 is obsolete No it's not. Andrew. OpenJDK 6 Project Lead -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52120dfe.1050...@redhat.com
Bug#699757: Java 6 support ending, Java 7 not in squeeze
On 02/04/2013 05:27 PM, Christian Bernardt wrote: Debian squeeze does provide openjdk-6-jdk as part of its default-jdk package. Here it can be seen that http://www.oracle.com/technetwork/java/eol-135779.html Java 6 end of support will be end of this month. That's Oracle proprietary Java. We'll be keeping OpenJDK 6 going. Andrew. (Project Lead, OpenJDK 6) -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5110d2a2.7000...@redhat.com
Re: -gcj packages and openjdk-built jars
On 07/18/2012 02:02 PM, Rene Engelhard wrote: - compile the jar.sos against -java-commons jars (b-d on itself on kbsd-*) The .jar.so files have no compile-time dependencies on anything. All dependencies are resolved at runtime. Andrew. -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5006ba0a.3010...@redhat.com
Re: gcj cannot find ecj any more, on m68k
On 05/12/2012 04:59 PM, Thorsten Glaser wrote:
Andrew Haley dixit:
Oh, gosh. As you say, it looks like strace isn't working. I can't
I managed to get further by usine -o but *not* -f (or -ff), since
using -o with -ff showed a child process’ log consisting exactly of:
--- SIGPWR (Power failure) @ 0 (0) ---
--- SIGXCPU (CPU time limit exceeded) @ 0 (0) ---
+++ killed by SIGINT +++
I believe it hung there.
Added to the logs were:
- stdout/stderr -
[Loaded (pre-compiled) java.util.PropertyResourceBundle from no code source]
[Loaded (pre-compiled) gnu.gcj.convert.Input_8859_1 from no code source]
[Loaded (BC-compiled) org.eclipse.jdt.internal.compiler.env.AccessRestriction
from (file:/usr/share/java/eclipse-ecj-3.5.1.jar no certificates)]
[Loaded (BC-compiled)
org.eclipse.jdt.internal.compiler.batch.ClasspathSourceJar from
(file:/usr/share/java/eclipse-ecj-3.5.1.jar no certificates)]
[Loaded (BC-compiled) org.eclipse.jdt.internal.compiler.batch.ClasspathJar
from (file:/usr/share/java/eclipse-ecj-3.5.1.jar no certificates)]
[Loaded (BC-compiled)
org.eclipse.jdt.internal.compiler.batch.ClasspathLocation from
(file:/usr/share/java/eclipse-ecj-3.5.1.jar no certificates)]
[Loaded (BC-compiled)
org.eclipse.jdt.internal.compiler.batch.ClasspathDirectory from
(file:/usr/share/java/eclipse-ecj-3.5.1.jar no certificates)]
[Loaded (BC-compiled)
org.eclipse.jdt.internal.compiler.env.NameEnvironmentAnswer from
(file:/usr/share/java/eclipse-ecj-3.5.1.jar no certificates)]
[Loaded (BC-compiled)
org.eclipse.jdt.internal.compiler.batch.ClasspathDirectory$1 from
(file:/usr/share/java/eclipse-ecj-3.5.1.jar no certificates)]
[Loaded (BC-compiled)
org.eclipse.jdt.internal.compiler.classfmt.ClassFileReader from
(file:/usr/share/java/eclipse-ecj-3.5.1.jar no certificates)]
[Loaded (BC-compiled)
org.eclipse.jdt.internal.compiler.classfmt.ClassFileStruct from
(file:/usr/share/java/eclipse-ecj-3.5.1.jar no certificates)]
[Loaded (pre-compiled)
org.eclipse.jdt.internal.compiler.env.IBinaryNestedType from
(file:/usr/share/java/eclipse-ecj-3.5.1.jar no certificates)]
[Loaded (pre-compiled) org.eclipse.jdt.internal.compiler.env.IBinaryField
from (file:/usr/share/java/eclipse-ecj-3.5.1.jar no certificates)]
[Loaded (pre-compiled) org.eclipse.jdt.internal.compiler.env.IGenericField
from (file:/usr/share/java/eclipse-ecj-3.5.1.jar no certificates)]
[Loaded (pre-compiled) org.eclipse.jdt.internal.compiler.env.IBinaryMethod
from (file:/usr/share/java/eclipse-ecj-3.5.1.jar no certificates)]
[Loaded (pre-compiled) org.eclipse.jdt.internal.compiler.env.IGenericMethod
from (file:/usr/share/java/eclipse-ecj-3.5.1.jar no certificates)]
[Loaded (BC-compiled) org.eclipse.jdt.internal.compiler.util.ManifestAnalyzer
from (file:/usr/share/java/eclipse-ecj-3.5.1.jar no certificates)]
[Loaded (BC-compiled)
org.eclipse.jdt.internal.compiler.classfmt.ClassFormatException from
(file:/usr/share/java/eclipse-ecj-3.5.1.jar no certificates)]
[Loaded (pre-compiled) java.lang.ArrayIndexOutOfBoundsException from no code
source]
[Loaded (pre-compiled) java.lang.IndexOutOfBoundsException from no code
source]
[Loaded (pre-compiled) java.util.Hashtable$1 from no code source]
[Loaded (pre-compiled) java.util.Hashtable$KeyIterator from no code source]
[Loaded (pre-compiled) java.util.Collections$8 from no code source]
Exception in thread main [Loaded (pre-compiled) gnu.gcj.runtime.NameFinder
from no code source]
[Loaded (pre-compiled) gnu.gcj.runtime.NameFinder$Addr2Line from no code
source]
[Loaded (pre-compiled) java.lang.PosixProcess from no code source]
[Loaded (pre-compiled) java.lang.Process from no code source]
[Loaded (pre-compiled) java.lang.PosixProcess$ProcessManager from no code
source]
[Loaded (pre-compiled) java.util.LinkedList from no code source]
[Loaded (pre-compiled) java.util.AbstractSequentialList from no code source]
[Loaded (pre-compiled) java.util.Deque from no code source]
[Loaded (pre-compiled) java.util.Queue from no code source]
[Loaded (pre-compiled) java.util.LinkedList$Entry from no code source]
[Loaded (pre-compiled) java.util.LinkedList$LinkedListItr from no code
source]
[Loaded (pre-compiled) java.util.ListIterator from no code source]
[Loaded (pre-compiled) java.io.BufferedWriter from no code source]
[Loaded (pre-compiled) java.lang.Throwable$StaticData from no code source]
java.lang.NoClassDefFoundError: org.eclipse.jdt.internal.compiler.Compiler
at
org.eclipse.jdt.internal.compiler.batch.Main.performCompilation(eclipse-ecj.jar.so)
at org.eclipse.jdt.internal.compiler.batch.Main.compile(eclipse-ecj.jar.so)
at
org.eclipse.jdt.internal.compiler.batch.GCCMain.compile(eclipse-ecj.jar.so)
at org.eclipse.jdt.internal.compiler.batch.GCCMain.main(eclipse-ecj.jar.so)
- strace -
fstat64(3, {st_mode=S_IFREG|0644, st_size=1282644, ...}) = 0
fstat64(3, {st_mode=S_IFREG|0644, st_size=1282644, ...}) = 0
Re: gcj cannot find ecj any more, on m68k
On 05/14/2012 02:21 PM, Thorsten Glaser wrote: With that, “gcj-4.6 -c x.java” produces… x.o: ELF 32-bit MSB relocatable, Motorola 68020, version 1 (SYSV), not stripped Ugh. So, now what. God only knows. Your system is behaving in such a bizarre way that I can't imagine what it's doing. I can't think of anything else that anyone can do without actually debugging the thing, and probably not many people can do that. Is this box reachable? Does it have a working gdb? Andrew. -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fb10e74.5020...@redhat.com
Re: gcj cannot find ecj any more, on m68k
On 05/14/2012 04:57 PM, Thorsten Glaser wrote: Andrew Haley dixit: Is this box reachable? https://wiki.debian.org/Aranym/Quick can get you a VM that behaves the same (it’s one of these). Does it have a working gdb? I think so. Andreas recently even fixed thread debugging, though someone has to test that first ;-) Ah, yes. I have no idea if I'll have the time to do anything with this, but it looks interesting. :-) Andrew. -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fb1316a.9090...@redhat.com
Re: gcj cannot find ecj any more, on m68k
On 05/09/2012 07:55 PM, Thorsten Glaser wrote: Andrew Haley dixit: gcj has an evil bug. Sometimes, when it has an unresolved reference, it reports a ClassNotFoundException for the referring class, not the referred. So, you now need to Oh, ok. jcf-dump -v -classpath /usr/share/java/eclipse-ecj-3.5.1.jar org.eclipse.jdt.internal.compiler.Compiler Ok, got a lot of output. and have a look at the class references in the constant pool. Uh, I’m sorry you lost me there. That is a train station, right? ;-) I can barely read any Java™ source code, much less know about gcj internals other than what I’ve seen during porting… Hmm. Well, I think we're very close and it would be a shame to stop now. If you do an strace -f -etrace=file you should be able to see what classes it's trying to load at the end, and one of these won't be found, and one of them wil be mentioned in the list of classes in the jcf-dump. Andrew. -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fab7028.6040...@redhat.com
Re: gcj cannot find ecj any more, on m68k
On 05/10/2012 06:08 PM, Thorsten Glaser wrote: Andrew Haley dixit: Hmm. Well, I think we're very close and it would be a shame to stop Oh, ok. now. If you do an strace -f -etrace=file you should be able to see what classes it's trying to load at the end, and one of these won't be found, and one of them wil be mentioned in the list of classes in the jcf-dump. I did it to the gij command, as you didn’t specify which, but bad luck, all it does is sitting there for a few minutes after spewing out what I attached. I’ve not had too much luck with strace on m68k for anything since the architecture was forced by glibc maintainers to switch to use TLS but didn’t have a register allocated in the psABI for it, and the porters probably didn’t want to change the ABI so they added syscalls, and now about every single function calls syscall #333 to get the TLS base address which slows strace down to hell. The “just sitting there” is idle though. root@aranym:~ # ps ax | fgrep pts/3 17229 pts/3Ss 0:00 -/bin/mksh 17255 pts/3S+ 1:03 strace -f -etrace=file gij-4.6 -verbose:class -classpath /usr/share/java/eclipse-ecj.jar org.eclipse.jdt.internal.compiler.batch.GCCMain x.java -g1 -fbootclasspath=./:/usr/share/java/libgcj-4.6.jar -g1 -fsource=1.5 -ftarget=1.5 17256 pts/3S+ 0:00 tee st.log 17257 pts/3Sl+0:35 gij-4.6 -verbose:class -classpath /usr/share/java/eclipse-ecj.jar org.eclipse.jdt.internal.compiler.batch.GCCMain x.java -g1 -fbootclasspath=./:/usr/share/java/libgcj-4.6.jar -g1 -fsource=1.5 -ftarget=1.5 17569 pts/4R+ 0:00 fgrep pts/3 Do you reckon a LD_PRELOAD open wrapper would help? (Or are we looking at more functions, if so which?) Oh, gosh. As you say, it looks like strace isn't working. I can't think of any way I'd investigate this other than using gdb to try to find the place where the exception is being thrown. Andrew. -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fabf9c1.6010...@redhat.com
Re: gcj cannot find ecj any more, on m68k
On 05/06/2012 03:56 PM, Thorsten Glaser wrote: If someone has an idea how to debug this, you’re welcome. Try running ecj1 like this: gij -verbose:class -classpath /usr/share/java/eclipse-ecj.jar org.eclipse.jdt.internal.compiler.batch.GCCMain \ Hello.java -g1 -fbootclasspath=./:/usr/share/java/libgcj-version.jar -g1 -fsource=1.5 -ftarget=1.5 Andrew. -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4faa3b6b.5030...@redhat.com
Re: gcj cannot find ecj any more, on m68k
On 05/09/2012 12:58 PM, Thorsten Glaser wrote: Andrew Haley dixit: On 05/06/2012 03:56 PM, Thorsten Glaser wrote: If someone has an idea how to debug this, you’re welcome. Try running ecj1 like this: gij -verbose:class -classpath /usr/share/java/eclipse-ecj.jar org.eclipse.jdt.internal.compiler.batch.GCCMain \ Hello.java -g1 -fbootclasspath=./:/usr/share/java/libgcj-version.jar -g1 -fsource=1.5 -ftarget=1.5 OK: gij-4.6 -verbose:class -classpath /usr/share/java/eclipse-ecj.jar org.eclipse.jdt.internal.compiler.batch.GCCMain x.java -g1 -fbootclasspath=./:/usr/share/java/libgcj-4.6.jar -g1 -fsource=1.5 -ftarget=1.5 jar tf /usr/share/java/eclipse-ecj-3.5.1.jar | grep org/eclipse/jdt/internal/compiler/Compiler.class -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4faa6489.2090...@redhat.com
Re: gcj cannot find ecj any more, on m68k
On 05/09/2012 05:15 PM, Thorsten Glaser wrote: Andrew Haley dixit: OK: gij-4.6 -verbose:class -classpath /usr/share/java/eclipse-ecj.jar org.eclipse.jdt.internal.compiler.batch.GCCMain x.java -g1 -fbootclasspath=./:/usr/share/java/libgcj-4.6.jar -g1 -fsource=1.5 -ftarget=1.5 jar tf /usr/share/java/eclipse-ecj-3.5.1.jar | grep org/eclipse/jdt/internal/compiler/Compiler.class root@aranym:~ # jar tf /usr/share/java/eclipse-ecj-3.5.1.jar | grep org/eclipse/jdt/internal/compiler/Comp org/eclipse/jdt/internal/compiler/Compiler.class So it’s in the .jar, it’s just not found… why? root@aranym:~ # unzip -lv /usr/share/java/eclipse-ecj-3.5.1.jar | fgrep internal/compiler/Compiler.class 18069 Defl:N 7207 60% 2012-04-10 14:30 b997aed0 org/eclipse/jdt/internal/compiler gcj has an evil bug. Sometimes, when it has an unresolved reference, it reports a ClassNotFoundException for the referring class, not the referred. So, you now need to jcf-dump -v -classpath /usr/share/java/eclipse-ecj-3.5.1.jar org.eclipse.jdt.internal.compiler.Compiler and have a look at the class references in the constant pool. Andrew. -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4faa99bd.8040...@redhat.com
Re: New work on java-package
On 04/03/2012 12:29 AM, Emmanuel Bourg wrote: Le 31/03/2012 21:10, Andrew Haley a écrit : While reading the authbind documentation I saw it was doing some fork tricks behind the scene. Maybe the forked process can't allocate its memory due to OpenVZ and quits? Hold on, do you see this problem outside OpenVZ? I know that there is a virtualization container that doesn't support memory overcommit, but I can't remember its name. If so, that's a big problem; Java's GC strategy really needs overcommit to work. This problem doesn't happen outside the OpenVZ container. OpenVZ has a setting to fiddle with memory overcommit (the privvmpages parameter), but I'm not sure it'll work with a 32 bits container and 4GB assigned, the limit can't be extended. If the JVM could allocate gradually the memory as the heap grows that would help, but I guess that's not possible. Not really. To be frank, overcommit is such a basic Linux feature that any container which doesn't fully support it is just broken. That's probably one more good reason to replace authbind with iptable in my case. The other reason being the lack of IPv6 support. Right. I expect that every Java VM will move to IPv6, so authbind would stop working everywhere. The sad thing is there is no good alternative yet. I realized today that ip6table doesn't support port redirection (because it works with NAT and NAT is discouraged with IPv6). The only solution left is to put a reverse proxy in front of Tomcat. It doesn't look difficult to make authbind work with IPv6. I don't know why no-one has yet done it. Andrew. -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f7ac21d.6030...@redhat.com
Re: New work on java-package
On 03/28/2012 11:50 PM, Emmanuel Bourg wrote: Le 28/03/2012 19:38, Andrew Haley a écrit : If you run strace -f -etrace=net java ... you'll be able to see the bind call that fails, and we can take it from there. Thank you for the tip, I'll give it a try. I'm not familiar with strace, -etrace=net seems to be rejected. The syntax bellow is accepted, is it the right one? strace -f -e trace=network java ... Yes. Andrew. -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f743058.6060...@redhat.com
Re: New work on java-package
On 03/27/2012 10:12 AM, Emmanuel Bourg wrote:
Le 20/03/2012 12:41, Andrew Haley a écrit :
Comments like this are infuriating. I want to make OpenJDK
competitive, but I can't do anything with this because I don't know
what you're talking about. I can't reproduce the problem, so I can't
fix it. Is there anything more frustrating than being told there's
a problem, but not what it is? It's like something out of Kafka.
There are indeed issues with OpenJDK that do not exist with the Oracle
JRE. Here is an issue I reported recently:
Tomcat with authbind on OpenVZ throws SocketException: Cannot allocate
memory (works with sun-java6)
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=659293
That's the only hurdle that prevents me from migrating my production
servers to OpenJDK (and the reason why I contributed some changes to
java-package).
I think the problem is in authbind: it only supports IPv4.
Try this:
$ authbind --depth 2 java -Djava.net.preferIPv4Stack=true ListenTest
ServerSocket[addr=localhost/127.0.0.1,port=0,localport=80]
Andrew.
import java.net.*;
public class ListenTest {
public static void main(String[] args)
throws Throwable {
ServerSocket s = new ServerSocket(80, 0,
InetAddress.getByName(localhost));
System.out.println(s);
}
}
--
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f745c75.1020...@redhat.com
Re: New work on java-package
On 03/27/2012 10:12 AM, Emmanuel Bourg wrote: Le 20/03/2012 12:41, Andrew Haley a écrit : Comments like this are infuriating. I want to make OpenJDK competitive, but I can't do anything with this because I don't know what you're talking about. I can't reproduce the problem, so I can't fix it. Is there anything more frustrating than being told there's a problem, but not what it is? It's like something out of Kafka. There are indeed issues with OpenJDK that do not exist with the Oracle JRE. Here is an issue I reported recently: Tomcat with authbind on OpenVZ throws SocketException: Cannot allocate memory (works with sun-java6) http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=659293 That's the only hurdle that prevents me from migrating my production servers to OpenJDK (and the reason why I contributed some changes to java-package). Right, that's an example of a comment that is actually useful. That's going to be tricky to find. I presume that the message is deceptive, and it's actually a permissions problem. If you run strace -f -etrace=net java ... you'll be able to see the bind call that fails, and we can take it from there. Andrew. -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f734c8f.80...@redhat.com
Re: New work on java-package
On 03/19/2012 07:11 PM, Barry Hawkins wrote: The focus of my message was to point out the need for users of Debian and its derivatives to be able to install an official JRE or JDK from Oracle. If I gave the impression of criticizing OpenJDK, my apologies; that was not the intent. Like so many others, I'll be happy when OpenJDK is the de facto choice for all things based on the JVM. Currently, high performance and graphical applications still see significant improvement when using the Oracle JRE/JDK. Comments like this are infuriating. I want to make OpenJDK competitive, but I can't do anything with this because I don't know what you're talking about. I can't reproduce the problem, so I can't fix it. Is there anything more frustrating than being told there's a problem, but not what it is? It's like something out of Kafka. Actual specific problems with performance are something we can address. Core performance differences are very few: It's the same VM. Oracle does have a few magic optimized classes we don't have, and they have a proprietary font renderer. We don't use Oracle's plugin. There isn't much else. People are now using some less desirable approaches like the one mentioned in a blog post from earlier in the year[0] which is not as rigorous or disciplined as the approach we were taking when using java-package years ago prior to the advent of the DLJ. I believe it would be a service to our user community to provide the java-package utility once more until the time when OpenJDK fully displaces Oracle's non-free offering for all cases. I understand, and I agree. Andrew. -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f686d04.3090...@redhat.com
Re: New work on java-package
On 03/19/2012 02:04 PM, Barry Hawkins wrote: For example, JetBrains IntelliJ IDEA, one of the main IDEs for Java development, still doesn't endorse the use of OpenJDK. If you download IDEA and launch it via a terminal, you will see the following warning: ~$ ./idea-IC-111.277/bin/idea.sh OpenJDK Runtime Environment (IcedTea6 1.11pre) (6b24~pre2-1) OpenJDK 64-Bit Server VM (build 20.0-b12, mixed mode) OpenJDK 64-Bit Server VM (build 20.0-b12, mixed mode) WARNING: You are launching IDE using OpenJDK Java runtime. THIS IS STRICTLY UNSUPPORTED DUE TO KNOWN PERFORMANCE AND GRAPHICS PROBLEMS! NOTE:If you have both Oracle (Sun) JDK and OpenJDK installed please validate either IDEA_JDK, JDK_HOME, or JAVA_HOME environment variable points to valid Oracle (Sun) JDK installation. See http://ow.ly/6TuKQ for more info on switching default JDK But that's their fault, not OpenJDK's; if there's actually anything wrong with OpenJDK that stops IDEA working, that would be another matter. I'd note that OpenJDK is the official Java SE 7 Reference Implementation, so if IntelliJ IDEA doesn't even work with the RI, it really is JetBrains' fault! Andrew. -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f6763f6.60...@redhat.com
Re: Reasonable values for the -Xmx parameter ?
On 03/08/2010 11:11 PM, Vincent Fourmond wrote: Pablo Duboue wrote: All right... Then, maybe I could add a function to java-wrappers that would find out what is a 'good default' for that parameter, getting something more than the memory required but still reasonably less than the memory present on the machine ? If you want to go in that direction, you might want to add also pointer compression in AMD64 (-XX:+UseCompressedOops), which makes a huge difference with respect to minimum heap sizes in AMD64. Otherwise what it's OK for 32-bits might be way too little for 64 bits. http://wikis.sun.com/display/HotSpotInternals/CompressedOops http://java.sun.com/javase/6/webnotes/6u14.html Would that be useful for anyone else than me ? I find it difficult to imagine how would you automatically determine the heap size based on the ideas you sketched in your earlier comments. If what you propose actually solves the problem, then you can actually write a patch for upstream to do that within the JVM :-) :-) My idea would be something just like all the memory minus a bit, which would make java apps behave somehow like the other programming languages with respect to memory allocation. The reason why this isn't done by default in the JVM (and why it definitely shouldn't be done that way) is that the JVM puts a strong emphasis on security: setting a limit on the resources a web applet can take seems like a good idea. No, that's not the main reason. It's done that way because the heap is contiguous, so has to be pre-allocated. The key issue here is the setting of vm.overcommit_memory and vm.overcommit_ratio. If you set the ratio large enough you can allocate a large heap without any problems. Andrew. -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4b9615e4.1090...@redhat.com
Re: State of openjdk on hppa
On 01/06/2010 05:26 PM, Tom Rodriguez wrote: No I didn't see it. If it was only on the icedtea list then I wouldn't have seen it as hotspot-dev is the only one of these aliases that I'm on. Oh darn, my mistake. The shiny new Reply List button on Thunderbird 3 didn't quite do what I expected... By the way, I restored the other aliases to my reply so they would get it too. So the computation of the location of the guard pages is wrong because of the direction of growth? For instance this line obviously won't work right: address low_addr = stack_base() - stack_size(); Right, that's it. There's also some code in os_linux_zero.cpp that does math on the stack that would need to take into account the real ABI direction. I think we probably need something like int os::stack_direction() to deal with this in shared code. All the guard logic in Thread needs to check it as does is_in_stack and is_lock_owned. There might be some logic in frame that needs to check it too but hopefully that will all be platform dependent logic. Andrew. -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#559967: FTBFS [hppa]: method openConnection() in the type URL is not...
On 12/14/2009 04:58 PM, dann frazier wrote:
On Fri, Dec 11, 2009 at 02:10:18PM +0530, Onkar Shinde wrote:
AFAIK, GCJ uses classpath library these days. The code from classpath
is being merged in GCJ. And from the status of classpath [1] it is
clear that java.net.URL.openConnection(java.net.Proxy) does not exist
in classpath implementation.
This can be easily tested. Try compiling following code with GCJ and
OpenJDK. GCJ fails to compile the code but OpenJDK works fine.
***
import java.net.*;
public class Hello {
public static void main (String args[]){
try {
URL url = new URL(http://www.google.com;);
url.openConnection(Proxy.NO_PROXY);
} catch (Exception e) {
e.printStackTrace();
}
}
}
***
Hence this is a tool chain issue and not issue in package
libxmlrpc3-java itself. As of now there is nothing package maintainer
can do except disabling building of the package for all arch that use
GCJ as default compiler (to unblock the transition to testing).
Onkar,
Thanks for looking into this.
Would you mind filing a bug against the appropriate toolchain package,
and setting a 'blocks' in the bug tracking system? This would make it
easy to lookup the history/status of this issue next time someone
notices it.
Also, I believe the appropriate way to avoid having this bug block
testing migration is to request the removal of hppa binaries from
testing. Once no hppa binaries exist in testing, we can reduce the
severity of this issue to important, which is not release critical.
I'd suggest *not* disabling building on gcj-archs because, presumably,
this bug will be fixed at some point and we could then provide hppa
binaries without updating each affected source package.
Fixing it properly will be hard, since AFAICS Classpath doesn't have support
for web proxies. But does this package actually *need* proxy support
to work? If not, it's easy to work around the problem with a simple patch
for the application. I can give advice if you like.
Andrew.
--
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: What is openjdk equivalent of javaws.jar
Vincent Fourmond wrote: On Mon, Nov 9, 2009 at 11:15 AM, Andrew Haley a...@redhat.com wrote: Vincent Fourmond wrote: This raises a problem which I've hit quite a few times already: it is a currently pain to find which java package holds which java classes. It would be quite great to have the equivalent of apt-file for java classes ;-)... (and that shouldn't be too difficult to write, actually - I just do not currently have the time). This should do it. Sure, but that only works for installed packages, whereas its utility would be much greater if it was based on some index of the jars available in the Debian archive... (for the record, apt-file is a utility that tells you which packages are installing a named file). Fair enough. I find the various combinations of dpkg and apt utterly baffling, but that's just me! I know I shouldn't be here really. :-) Seriously though, that script is *very* useful. I hope you find it so too. Andrew. -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: What is openjdk equivalent of javaws.jar
Vincent Fourmond wrote: This raises a problem which I've hit quite a few times already: it is a currently pain to find which java package holds which java classes. It would be quite great to have the equivalent of apt-file for java classes ;-)... (and that shouldn't be too difficult to write, actually - I just do not currently have the time). This should do it. Andrew. #!/bin/sh # # loc Find a class or package # # Usage: loc [-l] class-pattern [dirname] #-lUse system locate command instead of find. In that case, loc # will ignore any directory to be searched. # Example: # # $ loc -l org.objectweb.jonas.common.JProp # /var/lib/jonas/demoserver/ejbjars/autoload/mejb.jar # /var/lib/jonas/lib/common/ow_jonas_bootstrap.jar # /var/lib/jonas/eclipseserver/ejbjars/autoload/mejb.jar # /var/lib/jonas/ejbjars/autoload/mejb.jar # /var/cache/jonas/work/ejbjars/jonas/mejb_2005.09.15-17.01.52.jar # /usr/src/redhat/BUILD/jonas-4.3.3/jonas/classes/common/org/objectweb/jonas/common/JProp.class MODE=$1 if test $MODE == -l; then COMMAND='(locate \*.jar ; locate \*.war)' shift else COMMAND='(find $FOO -name \*.jar -follow ; find $FOO -name \*.zip -follow ; find $FOO -name \*.war -follow)' fi FOO=$2 if test x$FOO == x; then FOO=/usr/share/java fi eval $COMMAND 2/dev/null | while read i; do if (jar tf $i 2/dev/null | grep $1) /dev/null 21 ; then echo $i fi done if test $MODE != -l; then find $FOO -name '*.class' 2/dev/null | grep $1 else locate \*.class | grep $1 fi
Re: What is openjdk equivalent of javaws.jar
Vincent Fourmond wrote: On Mon, Nov 9, 2009 at 11:23 AM, Andrew Haley a...@redhat.com wrote: Sure, but that only works for installed packages, whereas its utility would be much greater if it was based on some index of the jars available in the Debian archive... (for the record, apt-file is a utility that tells you which packages are installing a named file). Fair enough. I find the various combinations of dpkg and apt utterly baffling, but that's just me! I know I shouldn't be here really. :-) You spy ;-) ! Uh yeah. Andrew. -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debconf Java BOF discussions
Matthew Johnson wrote: I've arranged for a Debian Java BOF at Debconf this year which I know many people won't be at, so I'd like to have some sort of pre-discussion first. There are a number of issues I'd like to try and sort out with packaging policy, and actually try and get them baked into policy. Firstly, I think we need to move most of the changes suggested at FOSDEM 2006[1] into the main policy. I then have some large issues and a couple of small ones which I'd like to address. General issues: - FOSDEM Draft - Packaging tools - Jar dependency resolution - Transitions FOSDEM Draft: Library changes look good, particularly dropping runtime dependencies. Javadoc is all sensible. Native and arch-dependent stuff is also all sensible. Unit tests, shouldn't specifically refer to JUnit, but I think if the maintainer is happy that there aren't any racy tests, failing the build on a failing unit test is entirely reasonable. If it's a real regression, you really do want to fail the build. The virual package section from here has been superseded since and I think we have a fairly sensible set of packages. Packaging tools: Project Jigsaw is going to change Java packaging in a major way. Whatever Debian changes to do, it needs to be able to work with the Jigsaw system. http://openjdk.java.net/projects/jigsaw/ Andrew. -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: openjdk-6 6b14-4 built but not uploaded
Matthias Klose wrote: Luk Claes schrieb: Matthias Klose wrote: According to the buildd logs the openjdk-6 6b14-4 build for mipsel did finish on Jun 20, but was not uploaded until now. Is there any interest within the mips porters on openjdk-6 on mips*, or should we just remove it from the archive and drop openjdk support on mips? Scheduled for upload now. Do you think the failure on hppa was temporary or is there a bug to be filed? thanks! No, it needs porting work (the implementation makes the assumption that the stack always grows downwards; unknown if there are other issues). Andrew Haley did look at it. For now nobody was interested in working on the port. That's right. It may be that the memory allocation is actually the only problem, and everything else will work just fine, but PA-RISC is, as far as I'm aware, only for legacy systems now. Andrew. -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: hppa in danger of being ignored for testing migration and eventual removal
Matthias Klose wrote: dann frazier schrieb: On Tue, Apr 28, 2009 at 05:09:25PM -0400, Carlos O'Donell wrote: On Tue, Apr 28, 2009 at 4:12 PM, Luk Claes l...@debian.org wrote: * Has progress been made regarding proper java support? What is considered proper java support? GCJ? Dave, have you tinkered with GCJ lately? GCJ-4.4 works fine on hppa, currently waiting in NEW ... so if you do want to see this resolved, please help with getting this accepted. Note that this doesn't work very well with NPTL (Ubuntu karmic), so please make sure that this continues to work with an glibc update. OpenJDK is non-trivial. Andrew Haley did have a look at this and came to the conclusion that the byte code interpreter for the zero port needs porting for archs with upward growing stacks. It might not be horribly difficult to fix. The crash comes when the VM calls mprotect() on the second page of the stack as a guard against stack overflow: obviously that isn't going to work if your stack grows upwards. I don't know if that is the only place in which the VM assumes the stack grows downwards. It's a matter of debugging, if anyone on hppa cares enough to get OpenJDK working. Andrew. -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#479952: libc6/s390 - __pthread_mutex_lock: Assertion `mutex-__data.__owner == 0' failed.
Carlos O'Donell wrote: On Sat, Oct 25, 2008 at 1:21 PM, Julien Danjou [EMAIL PROTECTED] wrote: Is there anything from an outsider that could help? I've seen this on-and-off again on the hppa-linux port. The issue has, in my experience, been a compiler problem. My standard operating procedure is to methodically add volatile to the atomic.h operations until it goes away, and then work out the compiler mis-optimization. The bug is almost always a situation where the lll_unlock is scheduled before owner = 0, and the assert catches the race condition where you unlock but have not yet cleared the owner. Are you sure this is a compiler problem? Unless you use explicit atomic memory accesses or volatile the compiler is supposed to re-order memory access. Perhaps I'm misunderstanding you. Andrew. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#479952: libc6/s390 - __pthread_mutex_lock: Assertion `mutex-__data.__owner == 0' failed.
Carlos O'Donell wrote: On Mon, Oct 27, 2008 at 10:05 AM, Andrew Haley [EMAIL PROTECTED] wrote: I've seen this on-and-off again on the hppa-linux port. The issue has, in my experience, been a compiler problem. My standard operating procedure is to methodically add volatile to the atomic.h operations until it goes away, and then work out the compiler mis-optimization. The bug is almost always a situation where the lll_unlock is scheduled before owner = 0, and the assert catches the race condition where you unlock but have not yet cleared the owner. Are you sure this is a compiler problem? Unless you use explicit atomic memory accesses or volatile the compiler is supposed to re-order memory access. Perhaps I'm misunderstanding you. Sorry, parsing the above statement requires knowing something about how lll_unlock is implemented in glibc. The lll_unlock function is supposed to be a memory barrier. The function is usually an explicit atomic operation, or a volatile asm implementing the futex syscall i.e. INTERNAL_SYSCALL macro. I understand all that, but the question still stands: is the compiler really moving a memory write past a memory barrier? ISTR we did have a discussion on gcc-list about that, but it was a while ago and should now be fixed. Andrew. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: trang 20030619-7 (QA upload)
Michael Schutte wrote: Hi Javaists, [Please Cc me on replies, I’m not subscribed] Could one of you be so kind and check my proposed QA upload of trang fixing #478187? The error occurs because gcj hides an internal package of trang behind a built-in one, which causes the very fancy message described in the bug report. The source package is at: http://alioth.debian.org/~michi-guest/packages/trang_20030619-7.dsc It builds fine in pbuilder, the binary package as well as the source is lintian clean, and debdiff against the binary package from 6.1 shows no unexpected changes. I originally converted the package to javahelper instead of implementing the current fix, but then noticed that java-gcj-compat fails on the JAR as well. From a release point of view, I guess it is okay to not change the package too much, anyway. Could anyone of you have a look and comment on the package (and probably consider uploading it)? I'm guessing that there was a missing -findirect-dispatch -Bsymbolic. I'd be quite interested to see what you've changed and what broke, but sadly my Debian smarts are inadequate to decude that URL. Andrew. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Developing with Java on Debian
Richard wrote: This is a bit of a newby question. What I'm wondering is whether one can use the debian package system as a kind of build system. Let me illustrate with an example, say for example I want to write an app and package it with debian and this app uses Hibernate, then I would like to declare a dependency on the hibernate libary package and start developing in eclipse right away. Right now I see that hibernate is available as a library package that has put jars in /usr/share/java. If I depend on these jars and write a unit test I discover that there are more dependencies, I need some of the apache commons libraries and the log4j library, but I can't see those as dependencies. So report a bug against the hibernate package: it certainly should require all of its dependencies. Andrew. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Are gcj/gij/java-gcj-compat ok on armel?
Martin Guy wrote: Hi! I see gcj/gij/java-gcj-compat are now disabled on arm, and that dependent packages are being asked to exclude them as Build-Deps to eliminate java library bindings. Are they believed to work in the armel port? Yes. As far as I'm aware gcj works 100% on armel. Andrew. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RM: arm: gtk/gnome java stack RoP;
Riku Voipio wrote: Package: ftp.debian.org Severity: important The following source packages are unbuildable and out of date on arm, thus blocking testing transition. It seems unlikely that java will properly work on oldabi arm, so please remove these for starters. Are we only talking about oldabi here? These should be fine with eabi. libglade-java libvte-java libgnome-java libgconf-java libgtk-java cairo-java glib-java -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RM: arm: gtk/gnome java stack RoP;
Package: ftp.debian.org Severity: important Riku Voipio wrote: Package: ftp.debian.org Severity: important The following source packages are unbuildable and out of date on arm, thus blocking testing transition. It seems unlikely that java will properly work on oldabi arm, so please remove these for starters. Are we only talking about oldabi here? These should be fine with eabi. libglade-java libvte-java libgnome-java libgconf-java libgtk-java cairo-java glib-java -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#432541: eclipse-cdt FTBFS with gcj-4.2
Andrew Haley wrote: Michael Koch wrote: On Sun, Mar 02, 2008 at 12:01:03PM +, Andrew Haley wrote: Michael Koch wrote: On Sun, Mar 02, 2008 at 10:35:28AM +, Andrew Haley wrote: And what was the reason? I need to know. !ENTRY org.eclipse.osgi 4 0 2008-03-02 12:38:50.196 !MESSAGE Application error !STACK 1 java.lang.ClassNotFoundException: org.eclipse.core.runtime.Plugin at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:402) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:347) make: *** [build-stamp] Fehler 13 The only small strange thing is that org.eclipse.core.runtime.Plugin and org.eclipse.core.runtime.Platform are in the same Jar. This must be some OSGi issue. At least I know now where to start debugging. Oh, right, so you *don't* actually know what the cause of this is. Me either, but I'm debugging it at the moment. Yeah, yesterday I thought it was just a missing jar file. Today I took a closer look at at it... gcj should not distinguish between natively compiled code and bytecode. The fact that it makes a difference must be a bug. Sounds like it. Can I somehow help? I know this is a hard case and currently cant think of a simpler testcase. OK, I've found it. The ClassNotFoundException is thrown from a security check in libgcj. We are calling Method m1 from method m0, and m1's class loader is different from m0's class loader. We have to check that for every arg in m1, the actual type is the same in both m1.loader and m0.loader. The method in question is org.eclipse.core.runtime.Platform.getPlugin(String), which returns an instance of org.eclipse.core.runtime.Plugin. It gets this by calling org.eclipse.core.internal.plugins.PluginDescriptor.getPlugin(). When we do the security check, we call Platform's class loader to ask it to loadClass(org.eclipse.core.runtime.Plugin) and it throws a ClassNotFoundException. OK, I've discovered some more. The class loader that's throwing the exception is a org.eclipse.osgi.framework.internal.core.BundleLoader, and it's being asked to find org.eclipse.core.runtime.Plugin. Now, this is where it gets really interesting. org.eclipse.core.runtime.Plugin is defined in eclipse/plugins/org.eclipse.core.runtime_3.3.100.v20070530.jar, along with a few other classes, including org.eclipse.core.runtime.IPluginDescriptor and org.eclipse.core.runtime.Platform. *but* IPluginDescriptor's class loader is not able to find org.eclipse.core.runtime.Plugin. Andrew. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#432541: eclipse-cdt FTBFS with gcj-4.2
Michael Koch wrote:
On Sun, Mar 02, 2008 at 12:01:03PM +, Andrew Haley wrote:
Michael Koch wrote:
On Sun, Mar 02, 2008 at 10:35:28AM +, Andrew Haley wrote:
And what was the reason? I need to know.
!ENTRY org.eclipse.osgi 4 0 2008-03-02 12:38:50.196
!MESSAGE Application error
!STACK 1
java.lang.ClassNotFoundException: org.eclipse.core.runtime.Plugin
at
org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:402)
at
org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:347)
make: *** [build-stamp] Fehler 13
The only small strange thing is that org.eclipse.core.runtime.Plugin and
org.eclipse.core.runtime.Platform are in the same Jar. This must be some
OSGi issue. At least I know now where to start debugging.
Oh, right, so you *don't* actually know what the cause of this is. Me either,
but
I'm debugging it at the moment.
Yeah, yesterday I thought it was just a missing jar file. Today I took a
closer look at at it...
gcj should not distinguish between natively compiled code and bytecode.
The fact that it makes a difference must be a bug.
Sounds like it. Can I somehow help? I know this is a hard case and
currently cant think of a simpler testcase.
OK, I've found it. The ClassNotFoundException is thrown from a security check
in libgcj. We are calling Method m1 from method m0, and m1's class loader
is different from m0's class loader. We have to check that for every arg
in m1, the actual type is the same in both m1.loader and m0.loader.
The method in question is org.eclipse.core.runtime.Platform.getPlugin(String),
which returns an instance of org.eclipse.core.runtime.Plugin. It gets this
by calling org.eclipse.core.internal.plugins.PluginDescriptor.getPlugin().
When we do the security check, we call Platform's class loader to ask it to
loadClass(org.eclipse.core.runtime.Plugin) and it throws a
ClassNotFoundException.
Tom Tromey: opinion, please.
Andrew.
public final class Platform {
...
public static Plugin getPlugin(String id) {
try {
IPluginRegistry registry = getPluginRegistry();
if (registry == null)
throw new IllegalStateException();
IPluginDescriptor pd = registry.getPluginDescriptor(id);
if (pd == null)
return null;
return pd.getPlugin(); // == This is where the
ClassNotFoundException is thrown
} catch (CoreException e) {
// TODO log the exception
}
return null;
}
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#432541: eclipse-cdt FTBFS with gcj-4.2
Andrew Haley wrote: Michael Koch wrote: On Sun, Mar 02, 2008 at 12:01:03PM +, Andrew Haley wrote: Michael Koch wrote: On Sun, Mar 02, 2008 at 10:35:28AM +, Andrew Haley wrote: And what was the reason? I need to know. !ENTRY org.eclipse.osgi 4 0 2008-03-02 12:38:50.196 !MESSAGE Application error !STACK 1 java.lang.ClassNotFoundException: org.eclipse.core.runtime.Plugin at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:402) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:347) make: *** [build-stamp] Fehler 13 The only small strange thing is that org.eclipse.core.runtime.Plugin and org.eclipse.core.runtime.Platform are in the same Jar. This must be some OSGi issue. At least I know now where to start debugging. Oh, right, so you *don't* actually know what the cause of this is. Me either, but I'm debugging it at the moment. Yeah, yesterday I thought it was just a missing jar file. Today I took a closer look at at it... gcj should not distinguish between natively compiled code and bytecode. The fact that it makes a difference must be a bug. Sounds like it. Can I somehow help? I know this is a hard case and currently cant think of a simpler testcase. OK, I've found it. The ClassNotFoundException is thrown from a security check in libgcj. We are calling Method m1 from method m0, and m1's class loader is different from m0's class loader. We have to check that for every arg in m1, the actual type is the same in both m1.loader and m0.loader. The method in question is org.eclipse.core.runtime.Platform.getPlugin(String), which returns an instance of org.eclipse.core.runtime.Plugin. It gets this by calling org.eclipse.core.internal.plugins.PluginDescriptor.getPlugin(). To be clear: the two class loaders being checked are those of interface org.eclipse.core.runtime.IPluginDescriptor and class org.eclipse.core.runtime.Platform Tromey: are you quite sure we should be checking the class loader of the interface type instead of the class loader of the method we're invoking? Andrew. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#432541: eclipse-cdt FTBFS with gcj-4.2
Michael Koch wrote:
On Fri, Feb 15, 2008 at 11:50:38PM +0100, Thomas Girard wrote:
Hello,
A while ago, I wrote:
Using the following pakages:
* java-gcj-compat{,-dev} 1.0.69-2
* ecj, ecj-gcj, libecj-java and libecj-gcj 3.3.0+0728-1
* libgcj-bc, libgcj8{-1,-1-awt,-jar} 4.2.1-3
* gcc-4.2-base 4.2.1-3
* gcj-4.1-base, gcj-4.1, gij-4.1, libgcj7-1 4.1.2-16
* libgcc1 1:4.2.2-3
eclipse-cdt compiles.
Updating to sid, I reach a point where it no longer compiles:
* java-gcj-compat 1.0.76-4 sets gcj-4.2 as the default gcj version
* gcj-4.2, gij-4.2 and libgcj8-* are at version 4.2.1-3
On Sat, Jan 26, 2008 at 05:12:44PM +0100, Michael Koch replied:
I have just tried this with SUN JDK 6, Icedtea, gcj 4.3, jamvm and cacao
with the following result:
* SUN JDK 6: Just works.
* gcj-4.3: No output at all. Returns with exit code 13.
* icedtea: No output at all. Returns with exit code 13. Exactly the same
as with gcj.
* jamvm: Fails but prints quite some output. Main issue is that jamvm has
no real JAVA_HOME.
* cacao: Fails but prints some output. Again an issue with an incomplete
JAVA_HOME provided by cacao.
We made progress on this issue with Michael; it turns out that using
eclipse natively compiled -gcj packages work around the FTBFS, for some
reason.
Michael found out that only eclipse-rcp-gcj is needed, and that deleting
org.eclipse.core.runtime_3.2.0.v20060603.jar.so is enough to make the
compilation fails, while it works when it's there.
So we now have a work-around to compile Eclipse plugins: install
eclipse-rcp-gcj.
What's really weird is that icedtea, even though it does not use -gcj
packages, exhibit the very same behavior.
Any idea on this?
I'm a bit ashamed. The solution was quiet simple. Added -consolelog to
the arguments revealed the reason for this (and for some crashes of
eclipse). I will fix that bug in eclipse packaging. This really makes me
wonder why SUN JDK worked...
And what was the reason? I need to know.
Andrew.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#432541: eclipse-cdt FTBFS with gcj-4.2
Michael Koch wrote: On Sun, Mar 02, 2008 at 10:35:28AM +, Andrew Haley wrote: And what was the reason? I need to know. !ENTRY org.eclipse.osgi 4 0 2008-03-02 12:38:50.196 !MESSAGE Application error !STACK 1 java.lang.ClassNotFoundException: org.eclipse.core.runtime.Plugin at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:402) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:347) make: *** [build-stamp] Fehler 13 The only small strange thing is that org.eclipse.core.runtime.Plugin and org.eclipse.core.runtime.Platform are in the same Jar. This must be some OSGi issue. At least I know now where to start debugging. Oh, right, so you *don't* actually know what the cause of this is. Me either, but I'm debugging it at the moment. gcj should not distinguish between natively compiled code and bytecode. The fact that it makes a difference must be a bug. Andrew. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#432541: eclipse-cdt FTBFS with gcj-4.2
Michael Koch wrote: On Sun, Mar 02, 2008 at 12:01:03PM +, Andrew Haley wrote: Michael Koch wrote: On Sun, Mar 02, 2008 at 10:35:28AM +, Andrew Haley wrote: And what was the reason? I need to know. !ENTRY org.eclipse.osgi 4 0 2008-03-02 12:38:50.196 !MESSAGE Application error !STACK 1 java.lang.ClassNotFoundException: org.eclipse.core.runtime.Plugin at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:402) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:347) make: *** [build-stamp] Fehler 13 The only small strange thing is that org.eclipse.core.runtime.Plugin and org.eclipse.core.runtime.Platform are in the same Jar. This must be some OSGi issue. At least I know now where to start debugging. Oh, right, so you *don't* actually know what the cause of this is. Me either, but I'm debugging it at the moment. Yeah, yesterday I thought it was just a missing jar file. Today I took a closer look at at it... gcj should not distinguish between natively compiled code and bytecode. The fact that it makes a difference must be a bug. Sounds like it. Can I somehow help? I don't think so. My plan is to add a lot of class loader tracing code to libgcj, and I will then trap at the point where compiled succeeds but interpreted doesn't. There are areas where compliant jvms might behave differently. For example, the exact time when dependent classes are loaded isn't defined. Maybe at class initialization time, maybe later. All the the spec requires is that ClassNotFoundExceptions aren't raised until classes are referred to. So, it is possible that Eclipse requires some precise semantics of class loading beyond what is strictly required by the spec. Maybe compiled code loads classes earlier than interpreted code, and maybe *the effective classpath has changed* by the time gij tries to load org.eclipse.core.runtime.Plugin. Andrew. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#432541: eclipse-cdt FTBFS with gcj-4.2
Andrew Haley wrote: There are areas where compliant jvms might behave differently. For example, the exact time when dependent classes are loaded isn't defined. Maybe at class initialization time, maybe later. All the the spec requires is that ClassNotFoundExceptions aren't raised until classes are referred to. So, it is possible that Eclipse requires some precise semantics of class loading beyond what is strictly required by the spec. Maybe compiled code loads classes earlier than interpreted code, and maybe *the effective classpath has changed* by the time gij tries to load org.eclipse.core.runtime.Plugin. And, in turn, this means that potentially the same VM may behave differently in interpreted and compiled mode... Andrew. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#432541: eclipse-cdt FTBFS with gcj-4.2
Michael Koch wrote: On Sat, Feb 16, 2008 at 10:33:21AM +, Andrew Haley wrote: Michael Koch wrote: On Sat, Feb 16, 2008 at 09:56:18AM +, Andrew Haley wrote: Has anyone actually attempted to debug this? Which code actually calls Runtime.exit()? I tried to debug this but I dont found out from where exit is called with code 13. What went wrong with the debugging? Do you want me to look? I was not able top get proper backtraces. All I found was that exit_group(13) was called. So, no-one has actually tried to debug this. I'm betting it's a bogus version check. What kind of version check do you mean? As far as I'm aware, OSGI bundles are versioned and if an appropriate OSGI bundle version is not found the program exits. That doesnt explain why the build always worked with SUN JDK. It should have failed the same if OSGi versions would be a problem. Wouldn't it? No. Did you try it with OpenJDK (the Sun version with the binary plugs) ? This is an important test. Andrew. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#432541: eclipse-cdt FTBFS with gcj-4.2
Thomas Girard wrote:
Hello,
A while ago, I wrote:
Using the following pakages:
* java-gcj-compat{,-dev} 1.0.69-2
* ecj, ecj-gcj, libecj-java and libecj-gcj 3.3.0+0728-1
* libgcj-bc, libgcj8{-1,-1-awt,-jar} 4.2.1-3
* gcc-4.2-base 4.2.1-3
* gcj-4.1-base, gcj-4.1, gij-4.1, libgcj7-1 4.1.2-16
* libgcc1 1:4.2.2-3
eclipse-cdt compiles.
Updating to sid, I reach a point where it no longer compiles:
* java-gcj-compat 1.0.76-4 sets gcj-4.2 as the default gcj version
* gcj-4.2, gij-4.2 and libgcj8-* are at version 4.2.1-3
On Sat, Jan 26, 2008 at 05:12:44PM +0100, Michael Koch replied:
I have just tried this with SUN JDK 6, Icedtea, gcj 4.3, jamvm and cacao
with the following result:
* SUN JDK 6: Just works.
* gcj-4.3: No output at all. Returns with exit code 13.
* icedtea: No output at all. Returns with exit code 13. Exactly the same
as with gcj.
* jamvm: Fails but prints quite some output. Main issue is that jamvm has
no real JAVA_HOME.
* cacao: Fails but prints some output. Again an issue with an incomplete
JAVA_HOME provided by cacao.
We made progress on this issue with Michael; it turns out that using
eclipse natively compiled -gcj packages work around the FTBFS, for some
reason.
Michael found out that only eclipse-rcp-gcj is needed, and that deleting
org.eclipse.core.runtime_3.2.0.v20060603.jar.so is enough to make the
compilation fails, while it works when it's there.
So we now have a work-around to compile Eclipse plugins: install
eclipse-rcp-gcj.
What's really weird is that icedtea, even though it does not use -gcj
packages, exhibit the very same behavior.
Has anyone actually attempted to debug this? Which code actually calls
Runtime.exit()?
I'm betting it's a bogus version check.
Andrew.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#432541: eclipse-cdt FTBFS with gcj-4.2
Michael Koch wrote: On Sat, Feb 16, 2008 at 09:56:18AM +, Andrew Haley wrote: Has anyone actually attempted to debug this? Which code actually calls Runtime.exit()? I tried to debug this but I dont found out from where exit is called with code 13. What went wrong with the debugging? Do you want me to look? I'm betting it's a bogus version check. What kind of version check do you mean? As far as I'm aware, OSGI bundles are versioned and if an appropriate OSGI bundle version is not found the program exits. Andrew. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFH: Illegal instruction error building docbook-xsl-saxon(-gcj) on arm architecture
Daniel Leidert wrote: The arm-buildd failed to build docbook-xsl-saxon(-gcj) with an illegal instruction error. You can find the build log at: http://buildd.debian.org/fetch.cgi?pkg=docbook-xsl-saxon;ver=1.00.dfsg.1-3;arch=arm;stamp=1202259174 A bug in GIJ? Anybody an idea? I do not have access to an arm-machine, so it's a little bit difficult to debug. I think it must be a bug in gij. I can debug it some time next week, but I'll need access to the build machine. Andrew. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Help needed on the Java policy
Matthew Johnson wrote: I have a package which compiles in the sid java-gcj-compat-dev, but only runs with sun java (or, I assume, IBM, but since IBM isn't in the archive, I don't think it's all that important to cater for). I've filed bugs against gcj, which have been fixed upstream, and it will probably work with icedtea, but until either of those reaches the archive, I only depend on sun-java5 | sun-java6. It seems to me like there's something major wrong here. Bugs get filed against gcj, I or one of the other gcj maintainers fix them, but the patches don't get applied to Debian's gcj package. So, despite the fact that the bug has been fixed, you still have to depend on Sun's Java. Andrew. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: icedtea status?
Egon Willighagen writes: On Jan 7, 2008 10:22 AM, Arnaud Vandyck [EMAIL PROTECTED] wrote: 2008/1/7, Michael Koch [EMAIL PROTECTED]: I understand, but do we really have other possible ways? Not moving packages that work only with icedtea to main at the moment. What are the timelines of IcedTea and gcj with respect to the next Debian release? Out of curiosity (haven't been keeping as tuned in as I would have liked): Has IcedTea (IT) matured enough to be ready before the next Debian release, and would it therefore make sense to replace gcj with IT as default JVM? For example, it is reasonable to expect IT to be ported to the same platforms as gcj currently has? Yes, it is reasonable, but it'll be some time before it's ready. IcedTea is good on x86 Linux, and it runs OK on PPC, but is interpreter only. Getting good performence with IcedTea on all the platforms to which gcj has been ported will be harder. What are the plans of the gcj (/Classpath) community with respect to coverage of the J5/6 language? gcj is already v5 language compatible, and the library is complete enough for general use. That is, what advantages does IT have over gcj (and vice versa), now and in, say, 6 months? The core problem with IcedTea at the present time is that it's *too* advanced: it's a pre-release of Java 1.7. To quote the README, At this time the build from which IcedTea was constructed corresponds to an early build of JDK 7. When JDK 7 is complete it will implement the Java SE 7 Platform Specification. Work on that specification is underway, but far from final. Any APIs in the JDK 7 implementation, whether new or old, are therefore subject to minor adjustments, major revisions, or even outright removal between now and the time that the Java SE 7 Platform Specification is finalized. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: icedtea status?
Michael Koch writes: On Mon, Jan 07, 2008 at 10:22:42AM +0100, Arnaud Vandyck wrote: 2008/1/7, Michael Koch [EMAIL PROTECTED]: [...] You know that even GCJ is not working on all our platforms? Yes I know and for those platforms, I don't see a problem moving the package to main because there were no alternative before icedtea. Given that fact we have to move *all* Java packages to contrib. Thats not really what we want. No, I don't want that and that's not what I'm trying to explain ;-) Anyway, Michael, thanks for working on Icedtea and I will not waste time to send bug reports on packages that moved to main but should IMHO remain in contrib. I understand, but do we really have other possible ways? Not moving packages that work only with icedtea to main at the moment. I agree that we have to take care when moving from contrib to main and that we have problems when some package in main works *only* with icedtea. IMO it is a good policy to file bugs against not working runtimes in this case so people know the problems and can work on them. OK, but please also post gcj failures to [EMAIL PROTECTED] At least, thing that don't buld with the latest gcj. I can't promise we'll fix everything, of course. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using java-gcj-compat-dev as build dependency
Onkar Shinde writes: On Dec 20, 2007 3:23 PM, Arnaud Vandyck [EMAIL PROTECTED] wrote: 2007/12/19, Onkar Shinde [EMAIL PROTECTED]: I am a java developer who is learning debian packaging these days. I am trying to fix some FTBFS of java related packages in Ubuntu. Some recent observations: 1. I am not sure about Debian but in Ubuntu Sun JDk packages can not be installed non-interactively and this causes buold failures. 2. For many packages adding java-gcj-compat-dev to 'Build-Depends' is the first and only thing needed for fixing FTBFS. Is there any policy regarding which compiler to use. java-gcj-compat-dev is used to build *free* java package because it was the free java alternative and was a primary choice in Debian/Ubuntu (and I think Fedora). I suppose OpenJDK will not require user interaction and I suppose OpenJDK will be the first choice in a near future. You can replace the JDK with java-gcj-compat-dev if you are sure the software can be built and can run with java-gcj-compat-dev. In other cases, you'll have to leave Sun's JDK. Right. That is my point. It looks like the packagers use Sun JDK as build dependency without trying to build with GCJ. So if there is any written policy or instruction on wiki that clearly states order of preference as gcj - icedtea - Sun JDK, it will solve many problems. It would help to know if there really is a problem building with gcj. If there is, and it's a gcj bug, we could look at that. Otherwise you might be limited to running on only OpenJDK, which greatly restricts the systems you can run on. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using java-gcj-compat-dev as build dependency
Onkar Shinde writes: On Dec 20, 2007 3:47 PM, Andrew Haley [EMAIL PROTECTED] wrote: Onkar Shinde writes: On Dec 20, 2007 3:23 PM, Arnaud Vandyck [EMAIL PROTECTED] wrote: 2007/12/19, Onkar Shinde [EMAIL PROTECTED]: I am a java developer who is learning debian packaging these days. I am trying to fix some FTBFS of java related packages in Ubuntu. Some recent observations: 1. I am not sure about Debian but in Ubuntu Sun JDk packages can not be installed non-interactively and this causes buold failures. 2. For many packages adding java-gcj-compat-dev to 'Build-Depends' is the first and only thing needed for fixing FTBFS. Is there any policy regarding which compiler to use. java-gcj-compat-dev is used to build *free* java package because it was the free java alternative and was a primary choice in Debian/Ubuntu (and I think Fedora). I suppose OpenJDK will not require user interaction and I suppose OpenJDK will be the first choice in a near future. You can replace the JDK with java-gcj-compat-dev if you are sure the software can be built and can run with java-gcj-compat-dev. In other cases, you'll have to leave Sun's JDK. Right. That is my point. It looks like the packagers use Sun JDK as build dependency without trying to build with GCJ. So if there is any written policy or instruction on wiki that clearly states order of preference as gcj - icedtea - Sun JDK, it will solve many problems. It would help to know if there really is a problem building with gcj. If there is, and it's a gcj bug, we could look at that. Otherwise you might be limited to running on only OpenJDK, which greatly restricts the systems you can run on. I would say this is partially incorrect statement. Using openjdk/icedtea as build dependency doesn't necessarily mean that you have you use only corresponding JRE for running applications. If the application uses only Java 1.5 (the common denominator these days) code features then we can make sure that it runs on Sun JRE by passing '-target 1.5' argument to compiler. But the Sun JRE isn't available on all Debian targets. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug #449176: azureus: Downloads very slowly with GIJ
Anthony Green writes: Andrew Haley wrote: OK, so you're not picking up the precompiled classes for some reason. Not good, but the fact that the CPU is only at 5% indicates that isn't the core problem. I believe that the problem lies in our NIO implementation. I don't know exactly what the problem is. It has been discussed a few times on some of our mailing lists (GNU Classpath, [EMAIL PROTECTED]). FWIW, there have been many bug reports against azureus in Fedora about this. Now that we have IcedTea I've closed all of these bug reports just asking people to not use gcj. IcedTea runs azureus just fine. It would be nice to find out what the problem really is, but I can't think of a way to find out. At least, a way that doesn't involve punching a hole in my firewall and allowing God Only Knows what peer-to-peer traffic through. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug #449176: azureus: Downloads very slowly with GIJ
Shaun Jackman writes: Running the bit torrent client Azureus, downloading progresses terribly slowly with the java-gcj-compat JVM and works fine with Sun's JVM. If anyone has any thoughts on why this might be the case, or has some time to investigate, I'd appreciate the help in solving this bug. http://bugs.debian.org/449176 What is the CPU meter doing? If the CPU is pegged at 100%, I'd do some profiling. Also, starting with the vm option -verbose:class will tell you if, by some accident, you aren't using the precompiled classes. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug #449176: azureus: Downloads very slowly with GIJ
Shaun Jackman writes: On Nov 21, 2007 6:31 AM, Andrew Haley [EMAIL PROTECTED] wrote: Shaun Jackman writes: Running the bit torrent client Azureus, downloading progresses terribly slowly with the java-gcj-compat JVM and works fine with Sun's JVM. If anyone has any thoughts on why this might be the case, or has some time to investigate, I'd appreciate the help in solving this bug. http://bugs.debian.org/449176 What is the CPU meter doing? If the CPU is pegged at 100%, I'd do some profiling. Also, starting with the vm option -verbose:class will tell you if, by some accident, you aren't using the precompiled classes. Hello Andrew, I can confirm that the CPU usage is 5% and that the precompiled classes are being used. Lots of messages like [Loaded (pre-compiled) java.lang.ClassLoader from no code source] OK, so you never see Loaded (bytecode) ? with azureus classes I do see messages like this: DEBUG::Wed Nov 21 11:05:54 GMT-07:00 2007::com.aelitis.azureus.core.networkmanager.impl.tcp.VirtualChannelSelectorImpl::select::586: VirtualChannelSelector: No progress for op 1: listener = class com.aelitis.azureus.core.clientmessageservice.impl.NonBlockingReadWriteService$2, count = 300, socket: open = true, connected = true VirtualChannelSelector::select::332,NonBlockingReadWriteService$1::runSupport::82,AEThread::run::69 Perhaps it's related. Which version of Azureus has RedHat packaged? Cc: Anthony Green for comments. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug #449176: azureus: Downloads very slowly with GIJ
Shaun Jackman writes: On Nov 21, 2007 11:30 AM, Andrew Haley [EMAIL PROTECTED] wrote: Shaun Jackman writes: On Nov 21, 2007 6:31 AM, Andrew Haley [EMAIL PROTECTED] wrote: Shaun Jackman writes: Running the bit torrent client Azureus, downloading progresses terribly slowly with the java-gcj-compat JVM and works fine with Sun's JVM. If anyone has any thoughts on why this might be the case, or has some time to investigate, I'd appreciate the help in solving this bug. http://bugs.debian.org/449176 What is the CPU meter doing? If the CPU is pegged at 100%, I'd do some profiling. Also, starting with the vm option -verbose:class will tell you if, by some accident, you aren't using the precompiled classes. Hello Andrew, I can confirm that the CPU usage is 5% and that the precompiled classes are being used. Lots of messages like [Loaded (pre-compiled) java.lang.ClassLoader from no code source] OK, so you never see Loaded (bytecode) ? with azureus classes Oh, yes I do. Sorry, I thought it was the precompiled GCJ classes that were important. I also see for Azureus... [Loaded (bytecode) org.gudy.azureus2.ui.common.Main from (file:/usr/share/java/Azureus2.jar no certificates)] ... and for SWT... [Loaded (bytecode) org.eclipse.swt.SWT from (file:/usr/share/java/swt.jar no certificates)] OK, so you're not picking up the precompiled classes for some reason. Not good, but the fact that the CPU is only at 5% indicates that isn't the core problem. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Thread problem in gcj?
Arnaud Vandyck writes: Hi all, I was reading some bug reports and I don't know if Andrew, Marc or other gcj dev were aware of a problem we have with dom4j that could be a gcj thread problem: Debian Bug report logs - #427456 dom4j: FTBFS: org.dom4j.ThreadingTest times out http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=427456 See the latest messages from Marcus. Thanks for your help, If you (or marcus) can extract a self-contained test case I might be able to have a look. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Memory problems with gij-4.1 and glibc 2.6
Marcus Better writes: I have recently had problems building Java packages. The build would just eat memory, and occasionally show things like: GC Warning: Repeated allocation of very large block (appr. size 524288000): May lead to memory leak and poor performance. GC Warning: Out of Memory! Returning NIL! Turns out this is bug #433391, so beware... It's probably not a bug in gcj: every time I've seen this it has turned out to be a bug in the application. Of course, if you can reproduce this in a way that allows me to attach a debugger I'll fix it. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Debian Wiki] Update of Java by HenningSprang
Michael Koch writes: On Thu, Jul 19, 2007 at 01:27:22PM +0200, Henning Sprang wrote: Michael Koch wrote: On Thu, Jul 19, 2007 at 12:28:09PM +0200, Arnaud Vandyck wrote: Am I missing something? Isn't Sun's Java 6 in Debian still in non-free?! It is. And it will never move to main. Someone should revert this change to old text which is more clear, IMO. Please look at the Wiki page the edited sentence described, first. The link this sentence is describing is not about Java 6 in particular, and the link to NonFree was broken, so I removed it, and made the sentence more generic. The OpenJDK the linked page is describing will not be in non-free for a very long time, I guess, but in contrib, I guess? There is still a long road to get this into main. Many legal issues need to be solved first. OpenJDK will never be in non-free, ever. OpenJDK is free software. It might a different case with a binary distribution of suns jdk (will that be available as deb in parallell toi the really gpl free jdk?) Tell me what you think and I'll change it to fit your tastes - currently, saying it is in Debian is not exactly wrong. It is. Quoting the Debian Policy: Packages in the other distribution areas (contrib, non-free) are not considered to be part of the Debian distribution, although we support their use and provide infrastructure for them (such as our bug-tracking system and mailing lists). [ OT: What a nasty us of the passive voice. Not considered to be part of the Debian distribution by whom? It would have been so easy to say Packages in the other distribution areas (contrib, non-free) are not part of the Debian distribution. Even We do not consider packages in the other distribution areas (contrib, non-free) to be part of the Debian distribution would have been better. :-) ] Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Backtrace with jar
Jörg Sommer writes:
is this a bug in java or in the application?
Caused by: java.lang.NoSuchMethodError: getenv
getenv was deprecated, removed, and then re-added in Java 1.5.
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4199068
Caused by: java.lang.ClassNotFoundException:
com.sun.image.codec.jpeg.ImageFormatException not found in
gnu.gcj.runtime.SystemClassLoader{urls=[file:Puck.jar],
parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}
com.sun.image.codec.jpeg.ImageFormatException is not part of the Java
API.
Andrew.
--
Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4
1TE, UK
Registered in England and Wales No. 3798903
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sun's OpenJDK in Debian?
Mark Wielaard writes: Only bootstraps on Fedora 7 for now, but we are making (very) slow progress to get things to build fully on Debian also. Ofergoodnessake, it's been three whole days! :-) Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Java policy and ABI changes
[EMAIL PROTECTED] writes: Quoting Andrew Haley [EMAIL PROTECTED]: In my opinion, Java libraries without stable interfaces shouldn't be deployed in free OSes. If they are to be used, you're going to have to change the jar name, but even that may not work: if you use such a library Mozilla, some other version of the same package might be used by some other Java application running in the same process, and unless it's firewalled by some ClassLoader trickery it'll break. If that happens, some trickery like Jar Jar Links may be your only hope. Hm. All this is a bit extreme. Even the Linux kernel changes its API all the time and things are working okay. This really is grossly unfair to the kernel deveopers, who go to great lengths to avoid breaking the ABI. Would that Java package mantainers were so careful. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Java policy and ABI changes
Marcus Better writes: Andrew Haley wrote: In my opinion, Java libraries without stable interfaces shouldn't be deployed in free OSes. That's a nice goal but unfortunately the world is not so perfect, because users occasionally require new software with shiny new bells and whistles. Besides we cannot control upstream and prevent them from breaking ABI. As a distribution we need to find a balance between features and stability. I think the Java policy needs to be tweaked to allow for multiple versions of the same library. The problem is much easier than for C libraries, since we don't have a dynamic linker, so the user is responsible for adding the correct library to the classpath. We just need to make sure the different versions don't conflict, which usually means that both of them cannot install the generic symlink /usr/share/java/foo.jar. As I pointed out before, that doesn't work for Java in the general case because a single running VM can load multiple libraries, which come from different sources, which may need different versions of the same library. You're into dependency hell very quickly. It seems it would suffice to have the symlink created by postinst, which would point it at the latest installed version (similar to ldconfig). Note that I'm not suggesting we should package several versions of libraries. That should be avoided, but when necessary there should be a way to do it. I'm not going to argue with that. Sometimes everybody has to do bad things. :-) Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Java policy and ABI changes
Mike Hommey writes: I have a java library package, called libmozillainterfaces-java, that is provided by xulrunner. I'm currently working on a new upstream release of xulrunner which changed the java interfaces: some interfaces changed namespaces, so you have to do changes to your source code, and xpcom initialization is not handled the same way (you have to initialize the Mozilla instance before initializing xpcom). Which means classes built with the older version won't build nor run as is with the newer version. What should be done in such case, package-wise ? Change name ? Change jar name ? Both ? Other ? Shoot the maintainers? Well, OK, that would be a little extreme, but urge the maintainers not to break binary compatibility. Despite all of its promise, software reuse in object-oriented programming has yet to reach its full potential. A major impediment to reuse is the inability to evolve a compiled class library without abandoning the support for already compiled applications. . . . [A]n object-oriented model must be carefully designed so that class-library transformations that should not break already compiled applications, indeed, do not break such applications.' ? Ira Forman, Michael Conner, Scott Danforth, and Larry Raper, Release-to-Release Binary Compatibility in SOM (1995) as quoted in the JLS. In my opinion, Java libraries without stable interfaces shouldn't be deployed in free OSes. If they are to be used, you're going to have to change the jar name, but even that may not work: if you use such a library Mozilla, some other version of the same package might be used by some other Java application running in the same process, and unless it's firewalled by some ClassLoader trickery it'll break. If that happens, some trickery like Jar Jar Links may be your only hope. Andrew. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: java dependency substvars and native compilation
Paul Cager writes: * Using the strings command seems to me a bit unsafe, in that you could get false positives if there are (normal) strings that end in class. I'm not sure if that is a real-life concern, or just my over-active imagination. It's unsafe. strings prints the printable character sequences that are at least 4 characters long and are followed by an unprintable character. A better plan would be to extract the strings by using jcf-dump --print-constants. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: java dependency substvars and native compilation
Matthew Johnson writes: Ideally I'd write (not in bash) a real byte-code parser which can find the class references properly. $ jcf-dump --print-constants java.lang.Object | grep 'Class name:' #2: Class name: 1=java/lang/Object #8: Class name: 7=java/lang/Throwable #18: Class name: 17=java/lang/InterruptedException #26: Class name: 25=java/lang/StringBuffer #32: Class name: 31=java/lang/Class #46: Class name: 45=java/lang/Integer #59: Class name: 58=java/lang/CloneNotSupportedException #63: Class name: 62=java/lang/NoSuchMethodError -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Repackaging question
Arnaud Vandyck writes: On 12/6/06, Marcus Better [EMAIL PROTECTED] wrote: Benjamin Mesing wrote: Generally speaking yes, but the Debian Java Policy suggests, that class files should be removed from upstream release [1]. That advice is plain wrong. (And it's not part of the actual Java policy as the page says.) No, it's not. It's a good idea to remove generated javadoc and jar files and classes. Very much so. Unless you build from source, you have no way to know that the binaries correspond to that source code. You can't even guarantee that you're not violating the GPL, which requires you to provide source code on demand. Many Java packages come with jar files for dependencies, i.e. external code where the source is not included in the upstream tarball. Such binaries must be removed and the package should then get a +dfsg suffix. However a .jar or .class file built from included source code should not be removed (but obviously they must not be installed in Debian, but rather the sources must be rebuilt). They can be removed to use less space and be sure not to include code that has been build with non free dependencies. That too. This is all to do with basic free software hygiene. Andrew. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Naming a 32-bit/64-bit specific Java package
Matthew Johnson writes: On Tue, 28 Nov 2006, Goswin von Brederlow wrote: libswt-gtk-3.2-java32 libswt-gtk-3.2-java64 libswt-gtk-3.2-java Any other suggestions, or completely different approaches? This seems like a really bad solution. The package is architecture independent except for the register/address size. How come it depends on this and is not architecture-dependent in another way? this seems really strange. If it's all bytecode there should be no dependency, and if there are native libraries it surely needs to be arch-dependent for other things. It is all bytecode. There is a wordlength dependency because the shortest Java integer type that will fit an address is used. Andrew. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFC-DRAFT] Debian-Java point of view about JDK under the GPL
Matthias Klose writes: Arnaud Vandyck writes: Hi debian-java team, I'd like us to write a common position statement about the jdk under the gpl. I think these points should be mentioned: o This is really a good thing for us because it is now really the GPL (+Classpath exception), not a MPL like license; o Sun worked hard to have the jdk in Debian for some time now. (My POV: not the right way, but they did it, thanks ;-)); o Let be patient. There is still a lot of work for everything to be integrated; o Debian currently supports java compatible infrastructure on more archs than the sun jdk supports. I would like to pick up the ideas from the Oldenburg meeting last year for arch dependent packages default-jre and default-jdk. Yeah. It would be nice to try to figure out where Java run-times for the various architectures are going to come from. What architectures do you support with the Sun JRE? Andrew. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packaging questions
Marcus Better writes: Benjamin Mesing wrote: However it requires Java 5.0 and I haven't found any information if there is a 5.0 compatible free java compiler available. I don't think so, but check GCJ upstream. It's not just the compiler, but also the class library that needs to support some new features, such as generics. gcj is now feature complete, but unstable. It's basically alpha quality. I'll probably check in a merge with mainline gcj some time this week. I'mo not sure when it'll be ready for release, but it'll be a good while yet. Andrew. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gcj/java status
Matthias Klose writes: - arm: debian only port, not yet submitted to upstream; runtime is currently non-functional, testsuite shows failures for all interpreter test cases. #388505: segfaults in gcj-dbtool-4.1, not addressed. Going back to gcj-4.0 for arm could be an alternative, at least simple programs did compile to native code and run sucessfully. As I understand it, Debian has a private patch for libffi closures. This is needed to make the interpreter work. No-one except Debian has the gcj interpreter working on ARM. See http://gcc.gnu.org/ml/java/2006-08/msg00123.html This patch looks to me like unwinder data is missing, and on systems that use DWARF unwinding this will cause exceptions to fail. I'm happy to help anyone who wants to get these test filaures fixed. But really, this patch should be pushed upstream rather than being Debian local. The testsuite in 4.0 shows over 100 test failures, in 4.1 over 700. Mmm, but I suspect that's because more is being tested, not because it's worse. Andrew. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: JGR with free java (was: GUI for R)
Egon Willighagen writes: cc: debian-java - I need a bit of help here, see below On Wednesday 11 October 2006 15:48, Dirk Eddelbuettel wrote: | Unfortunately, JGR is still somewhat outside Debian as it wants Sun's | Java JDK so I don't think I'll ever package it directly. Now, if | someone wanted to outside of Debian ... In fact, the CRAN maintainers | mention that idea. Maybe one day. | | Did you try it with JamVM/Classpath? I will have a go at that in running | JGR, and report problems with the Classpath team. I do not use Java myself, so I wouldn't be the one to try this. It would be nice if someone like you with R and Java clues coud try it. I honestly do not know what is involved but I have the suspicion that it is no cake walk. I've found out that it now actually is a package on CRAN, and installs fine, and really just depends on rJava for the Java binding. (JGR and rJava are downloaded as source tar.gz from [1]). I had a brief go at installing rJava against GIJ: $ JAVA_HOME=/usr/lib/jvm/java-1.4.2-gcj-4.1-1.4.2.0 R CMD INSTALL --library=/usr/local/lib/R/site-library rJava_0.4-11.tar.gz (R comes with the package r-base). You need to have java-gcj-compat-dev and libgcj-bc installed. But it fails because of this call: /usr/lib/jvm/java-1.4.2-gcj-4.1-1.4.2.0/bin/javac -target 1.4 -source 1.4 -target 1.4 -source 1.4 -classpath src/JRI.jar -d examples examples/rtest.java Note the duplicate '-target 1.4 -source 1.4', which is OK for the Sun javac, but breaks compiling with gcj 4.1 javac. What is javac here? If it's a link to ecj, which it should be, this will work. A workaround is not compiling the examples, which can be done by modifying (after tar zxvf) the rJava/jri/Makefile.all, and make it look like: examples/%.class: examples/%.java src/JRI.jar #$(JAVAC) $(JFLAGS) -classpath src/JRI.jar -d examples $ Then the package installs. However, running it still fails with this error: $ R snip and then on the R command line: library(rJava) which fails with: Error in dyn.load(x, as.logical(local), as.logical(now)) : unable to load shared library '/usr/local/lib/R/site-library/rJava/libs/rJava.so': libjvm.so: cannot open shared object file: No such file or directory Error in library(rJava) : .First.lib failed for 'rJava' Not sure what else I can/should try now. Ideas? Did you install rJava.so? If so, where is it? Did it even get built? Andrew. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: JGR with free java (was: GUI for R)
Egon Willighagen writes: On Sunday 22 October 2006 11:51, Andrew Haley wrote: But it fails because of this call: /usr/lib/jvm/java-1.4.2-gcj-4.1-1.4.2.0/bin/javac -target 1.4 -source 1.4 -target 1.4 -source 1.4 -classpath src/JRI.jar -d examples examples/rtest.java Note the duplicate '-target 1.4 -source 1.4', which is OK for the Sun javac, but breaks compiling with gcj 4.1 javac. What is javac here? See code above: /usr/lib/jvm/java-1.4.2-gcj-4.1-1.4.2.0/bin/javac with: $ ls -la /usr/lib/jvm/java-1.4.2-gcj-4.1-1.4.2.0/bin/javac lrwxrwxrwx 1 root root 12 2006-10-20 17:04 /usr/lib/jvm/java-1.4.2-gcj-4.1-1.4.2.0/bin/javac - /usr/bin/ecj snip If it's a link to ecj, which it should be, this will work. How? $ /usr/bin/ecj -target 1.4 -source 1.4 -target 1.4 -source 1.4 -classpath src/JRI.jar -d examples examples/rtest.java Gives: duplicate target compliance setting specification: 1.4 where: $ /usr/bin/ecj -version Eclipse Java Compiler v_677_R32x, 3.2.1 release, Copyright IBM Corp 2000, 2006. All rights reserved. Actually, instead of commenting out that line in Makefile.all, you can also just remove the $(JFLAGS) to get: examples/%.class: examples/%.java src/JRI.jar $(JAVAC) -classpath src/JRI.jar -d examples $ The first -target 1.4 -source 1.4 is part of the $(JAVAC) var. Oh, I see. Fair enough. which fails with: Error in dyn.load(x, as.logical(local), as.logical(now)) : unable to load shared library '/usr/local/lib/R/site-library/rJava/libs/rJava.so': libjvm.so: cannot open shared object file: No such file or directory Error in library(rJava) : .First.lib failed for 'rJava' Not sure what else I can/should try now. Ideas? Did you install rJava.so? Yes, using the R CMD INSTALL call in my first email. If so, where is it? See the above error message: /usr/local/lib/R/site-library/rJava/libs/rJava.so $ ls -al /usr/local/lib/R/site-library/rJava/libs/rJava.so -rwxr-xr-x 1 egonw staff 128075 2006-10-22 12:37 /usr/local/lib/R/site-library/rJava/libs/rJava.so Interesting. So, the file is where it is expected to be, but gij still reports that the file is missing. How very odd. I can't explain that. Setting LD_DEBUG=all before running the program might tell you something. diff -ru rJava-orig/src/Makevars.in rJava/src/Makevars.in --- rJava-orig/src/Makevars.in 2006-10-11 01:52:30.0 +0200 +++ rJava/src/Makevars.in 2006-10-22 12:39:36.0 +0200 @@ -14,5 +14,5 @@ jri: $(MAKE) -C ../jri/ [EMAIL PROTECTED] -p ../inst/jri - @(cp -r ../jri/src/JRI.jar ../jri/*jri.* ../jri/run ../jri/examples ../inst/jri/) + @(cp -r ../jri/src/JRI.jar ../jri/*jri.* ../jri/examples ../jri/run ../inst/jri/) This looks like a change without a difference. Andrew. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: JavaMail and JAF
MrDemeanour writes: Tom Marble wrote: Marcus Better wrote: the pkg-jboss project needs DFSG-free versions of Sun's JavaMail and Java Activation Framework libraries. Can anyone tell me whether the GNU versions (already in Debian) will work out of the box? Why not use Sun's JavaMail and JAF? As of April they are now Free software under the CDDL: http://java.sun.com/products/javamail/index.jsp Since when did the CDDL equate to Free? It certainly doesn't appear on the FSF list of free licences. It is, however, on the OSF list at http://www.opensource.org/licenses/cddl1.php Andrew. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: JavaMail and JAF
Timo Juhani Lindfors writes: Hi, On Thu, Aug 31, 2006 at 05:33:03PM +0100, Andrew Haley wrote: It certainly doesn't appear on the FSF list of free licences. It is, Hmm, to me it seems that oddly enough FSF considers it free: $ lynx -dump http://www.gnu.org/philosophy/license-list.html | grep -A 5 (CDDL) [101]Common Development and Distribution License (CDDL) This is a free software license which is not a strong copyleft; it has some complex restrictions that make it incompatible with the [102]GNU GPL. It requires that all attribution notices be maintained, while the GPL only requires certain types of notices. Also, it terminates in retaliation for certain You're right, it is there. I missed it. Andrew. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: Java policy draft; a road map proposal...
Pierre Métras writes: Wolfgang Baer wrote: [...] Beside that I recognize the value a Java Developer Guide could have. I definitely agree, many thanks Pierre for volunteer :-D OK, I volunteer but I'll start small, improving the wiki content when I find some time... Perhaps my thought has been mis-interpreted. I don't think that we need to write a Developer Guide now, as it will spread our too limited resources on too many goals. Maybe such a Developer Guide would also be useful for other GNU/Linux distributions. OK, there are a few Debian-speciic issues, but surely most of the problems a developer might encounter are more general than that. I'm aware from the questions we get asked on the gcj list that we need some proper user documentation. Andrew. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Azureus finally no longer needs non-free java. It works with gij.
Mladen Adamovic writes: robin putters wrote: How about uploading an Azureus 'pure' debian package to experimental, while GCJ4.1 is not in unstable yet? Did you test Azureus properly, and not just be able to compile it? Guys from Red Hat included GCJ compiled Eclipse in Fedora core 4 (Native Eclipse) and it was so unstable that in fact it was completely useless. Shame on them. Excuse me while I go behind the outhouse and shoot myself. Mladen Adamovic http://home.blic.net/adamm http://www.shortopedia.com http://www.froola.com The site is temporary down. We are sorry about this inconvenience. :-) Andrew. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Azureus finally no longer needs non-free java. It works with gij.
Mladen Adamovic writes: Andrew Haley wrote: Did you test Azureus properly, and not just be able to compile it? Guys from Red Hat included GCJ compiled Eclipse in Fedora core 4 (Native Eclipse) and it was so unstable that in fact it was completely useless. Shame on them. Excuse me while I go behind the outhouse and shoot myself. I hope you are kidding about that shooting! Don't find me wrong, I really appreciate all effort (your guys from) Red Hat and others are giving in gcj. I see that there are few Red Hat employees working full time for gcj and there are more people also, and hopefully gcj one day will be as stable as Sun's Java and I really think it would make big positive influence on Linux and big negative influence on Vista. I really believe that gcj could be really really important. It could break MS domination on the market. But sometimes gcj used to make bad impressions and I think that Red Hat should avoid making those bad impressions, when possible. So do I. I regret the fact that you had a bad experience. I will see what Fedora 5 have to offer this week (waiting to FTP final release) and take better look inside new gcj. Thank you for displaying a slightly more reasonable attitude this time around. We make the best decisions we can, based on the information that we have. I cannot guarantee that we will always make the same decisions that you would have made, but, despite whatever you may think, we do test things and we are not cavalier about stability. If we believed that Eclipse was as unstable as you say it was, we would not have included it. http://www.froola.com The site is temporary down. We are sorry about this inconvenience. :-) :) Nobody is perfect. No kidding. Andrew. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Java policy draft
Re debugging info -- I put this patch into ecj on Fedora: https://www.redhat.com/archives/fedora-devel-java-list/2006-January/msg00086.html This patch means that no matter what broken debug options are in Ant scripts, every Java program in an RPM has full debuginfo. Essentially, this turns a rule You shall do this into something automatic. Andrew. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Java policy draft
Andrew Haley writes: Re debugging info -- I put this patch into ecj on Fedora: https://www.redhat.com/archives/fedora-devel-java-list/2006-January/msg00086.html This patch means that no matter what broken debug options are in Ant scripts, every Java program in an RPM has full debuginfo. Essentially, this turns a rule You shall do this into something automatic. An alternative would be to have ecj abort if debugging isn't set when building a package. This would be the brutal alternative, but it would work. I suspect that unless you do *something* automatic to enforce the policy, it won't work. Andrew. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Install a Java IDE
CasperLinux writes: I think you misunderstood my purpose: On Monday 27 February 2006 10:03, Michael Koch wrote: On Mon, Feb 27, 2006 at 07:51:10AM -0500, CasperLinux wrote: I am starting to learn programming Java (and programming in general for that matter). I'd like to use my Debian Testing box to work on. I have read and know that Eclipse is available but when I installed it the plugin choices were not intuitive so I uninstalled it and decided to ask directions. I dont understand. What is wrong with Eclipse? Nothing is wrong with Eclipse - just when I installed it and tried to do something (and at this point I don't even remember what I was doing) it kept asking for plugins I didn't have loaded. I finally threw in the towel and uninstalled it pending locating some documetnation on what to load including plugins. Well, if you can't remember what you were trying to do or what happened, we can't help you. We can't somehow get inside your skull and figure out what you want. Andrew. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: invoking gcj methods from gdb
Michael Koch writes: On Sat, Feb 25, 2006 at 03:45:43AM -0500, Daniel Risacher wrote: While using gdb to debug my native-compiled application, I can step, backtrace, examine local variables, etc. But I cannot seem to invoke a method - doing so causes a segfault. i.e. 'print simplevar' works, but 'print obj.method()' does not. Is this normal? Is there a workaround? Is it just me? [p.s. using gdb 6.4-debian, gcj (GCC) 4.0.3 20060212 (prerelease) (Debian 4.0.2-9)] Thats not supported yet and afaik there are some things missing in gdb for it. as far as I understood. Maybe gcj misses some other parts too. I can't remember what's supposed not to be there and what broke. Suggest you bounce this message to [EMAIL PROTECTED] Andrew. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Eclipse and Java 1.5 user report
[EMAIL PROTECTED] writes: So now I'm using the Debian Eclipse packages with J2SDK 1.5. All the new language features are supported perfectly, and the overall performance seems much better. I hope you guys are not angry about that, but for me using Sun's proprietary Java VM is just the better solution. Well, OK. You are happy to use a proprietary JVM; we aren't. With regard to J2SDK(tm) 1.5 compatibility, we're working on it. If you'd like to help us to make this happen sooner, please join us at http://www.classpath.org/. Andrew. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Tip: use of GDB with Java/gcj (and ant)
Daniel Risacher writes:
I recently started developing with gcj on debian and wanted to use
gdb for debugging, but I've struggled a bit with it. I had actually
composed a lengthy set of questions to ask here on the list, but in
writing the email, I stumbled across the answer, which I now present.
The problem: I wasn't getting any debugging information (line numbers
or local symbols into the code when I compiled with ant. My javac
task in build.xml looked like this:
javac debug=true verbose=yes debuglevel=source
includeJavaRuntime=no
compiler=gcj destdir=classes
src path=src /
include name=**/*.java /
compilerarg line= --main=Main -o Coast /
/javac
The solution was to change the javac task to this:
javac verbose=yes includeJavaRuntime=no
compiler=gcj destdir=classes
src path=src /
include name=**/*.java /
compilerarg line=-g --main=Main -o Coast /
/javac
Note that the 'debug' and 'debuglevel' properties were removed, and
the '-g' option was added to 'compilerarg'
I hope this helps someone else avoid the hand-wringing and
teeth-gnashing I went through.
I've come across a few RPMS with missing debuginfo and wasted a great
deal of time trying to rebuild to get the debuginfo.
The problem seems to be that some ant scripts force debugging to be
off or perhaps inherited from a property that no-one remembered to
set. This is compounded by the fact that some ant scripts unzip source
archives and then call ant recursively to build them: in such a case
it's very hard to patch build.xml to force debugging=true.
This patch for ecj forces debuginfo always to be generated while
rebuilding an RPM, no matter what ant thinks. I realize it's
something of a kludge, but it's better than the current situation.
When compiling C/C++/etc, RPM passes -g in RPM_OPT_FLAGS. An
alternative to this patch might be to scan RPM_OPT_FLAGS for -g and
only turn on debugging if it's present. However, I doubt that in
practice it'd make any difference.
Something similar would work for Debian. I know of no circumstances
in which we ever wish to ship packages that don't have debuginfo.
Andrew.
---
eclipse-3.1.1/plugins/org.eclipse.jdt.core/batch/org/eclipse/jdt/internal/compiler/batch/Main.java.orig
2006-01-19 17:53:49.0 +
+++
eclipse-3.1.1/plugins/org.eclipse.jdt.core/batch/org/eclipse/jdt/internal/compiler/batch/Main.java
2006-01-19 18:06:32.0 +
@@ -2405,6 +2405,29 @@
this.times = new long[this.repetitions];
this.timesCounter = 0;
}
+
+ {
+ // If we're building an RPM, force full debugging info
to
+ // be generated, no matter what options have been passed
+ // by Ant. This is something of a kludge, but it is far
+ // better than the alternative, which is having class
+ // files with debug info mysteriously missing.
+
+ String RpmPackageName =
System.getenv(RPM_PACKAGE_NAME);
+ String RpmArch = System.getenv(RPM_ARCH);
+ String RpmBuildRoot = System.getenv(RPM_BUILD_ROOT);
+ if (RpmPackageName != null RpmArch != null
RpmBuildRoot != null) {
+ this.options.put(
+
CompilerOptions.OPTION_LocalVariableAttribute,
+ CompilerOptions.GENERATE);
+ this.options.put(
+ CompilerOptions.OPTION_LineNumberAttribute,
+ CompilerOptions.GENERATE);
+ this.options.put(
+ CompilerOptions.OPTION_SourceFileAttribute,
+ CompilerOptions.GENERATE);
+ }
+ }
}
private void addNewEntry(final int InsideClasspath, final int
InsideSourcepath, ArrayList bootclasspaths, ArrayList classpaths,ArrayList
sourcepathClasspaths, String currentClasspathName, ArrayList currentRuleSpecs,
int mode, String customEncoding) {
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Trying to build jonas deb package
I have succesfully built JOnAS on FC5. There are a lot of dependencies. The FC5 packages I needed to install for the build were: tomcat5-servlet-2.4-api.i386 5.0.30-8jpp_9fc jdom.noarch 1.0-1jpp_2fc.1 werken.xpath.noarch 0.9.4-0.beta.9jpp_2fc velocity.noarch 1.4-3jpp_3fc struts.i386 1.2.4-2jpp_5fc tomcat5-jasper.i386 5.0.30-8jpp_9fc tomcat5.i386 5.0.30-8jpp_9fc jrefactory.noarch 2.8.9-3jpp_1fc.1.1 xjavadoc.noarch 1.1-1jpp_3fc adaptx.noarch 0.9.6-1jpp_2fc.1.1 mockobjects.noarch 0.09-12jpp_4fc concurrent.noarch 1.3.2-2jpp_1fc.1 tomcat5-webapps.i386 5.0.30-8jpp_9fc jgroups.noarch 2.2.6-1jpp_3fc classpathx-mail-monolithic.noarch 1.0-4jpp_4fc castor.noarch 0.9.5-1jpp_1fc.1.1 tomcat5-admin-webapps.i386 5.0.30-8jpp_9fc xdoclet.noarch 1.2.2-2jpp_4fc tanukiwrapper.i386 3.1.1-4jpp_3fc.2 jakarta-commons-cli.i386 1.0-6jpp_5.fc5 And the progress of rebuilding JOnAS and all of its dependencies went like this: monolog dtdparser objectweb-deploysched asm fractal perseus-cache perseus-dependency perseus-distribution perseus-concurrency nanoxml oldkilim jonathan-core jacorb jonathan-jeremie carol howl-logger joram perseus-pool perseus-fos jorm medor medor-expression jotm jorm-rdb-adapter objectweb-anttask perseus-persistence p6spy jonathan-rmi gif89encoder jonas More info at https://www.redhat.com/archives/fedora-devel-list/2006-February/msg00613.html Andrew. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GCJ ICEs on SWT for GTK 3.1.2
Michael Koch writes: On Sun, Feb 05, 2006 at 01:02:22PM -0700, Shaun Jackman wrote: If anybody here has the time to look into this GCJ ICE, I'd greatly appreciate it. You should file/report such bugs upstream (http://gcc.gnu.org/bugzilla/). Most of the upstream people are RH employees and don't read this list. You'd be surprised, then! :-) BTW: The recommended way by upstream to compile to native is to compile jars to native, not java files. We have no problem building Eclipse 3.1.2 with gcj-4.0 this way. OK, but if this bug can be reprodues with an upstream compiler it's worth reporting to gcc bugzilla. Andrew. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Trying to build jonas deb package
Wolfgang Baer writes: Hi Praveen, êðõ ã Ï (Praveen A) wrote: 2006/1/20, êðõ ã Ï (Praveen A) [EMAIL PROTECTED]: Hi, I' m trying to figure out how to build jonas for debian. I am a newbie to debian packaging. If anyone alse is working on the same thing it would great to work together. I think currently nobody is packaging jonas. First results while trying to build [EMAIL PROTECTED]:~/jonas$ ant install Buildfile: build.xml ^^^ [javac] The type javax.rmi.CORBA.PortableRemoteObjectDelegate cannot be resolved. It is indirectly referenced from required .class files [javac] -- [javac] 1 problem (1 error) kaffe is currently the only VM with the corba rmi stuff. So you should try to compile with kaffe. Or patch the use of corba out in the build system. May be a non-trivial task - depends on the quality of the build file :-) Note: I had to install java-gcj-compat-dev for jonas to recognise javac Sure, java-gcj-compat-dev is a JDK like environment, java-gcj-compat the JRE. kaffe only provides a full JDK like environment. On Fedora systems, javax.rmi.CORBA.PortableRemoteObjectDelegate is provided by the jonathan-rmi package. This is a tiny package that provides these few classes: javax/rmi/CORBA/ClassDesc.class javax/rmi/CORBA/PortableRemoteObjectDelegate.class javax/rmi/CORBA/Stub.class javax/rmi/CORBA/StubDelegate.class javax/rmi/CORBA/Tie.class javax/rmi/CORBA/Util.class javax/rmi/CORBA/UtilDelegate.class javax/rmi/CORBA/ValueHandler.class javax/rmi/PortableRemoteObject.class org/omg/SendingContext/RunTime.class Andrew. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
