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: 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: 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 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/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: 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: 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: Does JDK7 security hole affect OpenJDK6?
On 01/17/2013 11:58 AM, Deniz Akcal wrote: > I read somewhere (I think it was on Techrepublic but, I'm not sure) that the > answer to that was no (as in that popular security hole does not affect > OpenJDK 6). You should get confirmation from someone that knows more about > this, though. I can tell you now that the affected code is not present in OpenJDK 6. 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/50f7ed19.4020...@redhat.com
Re: -gcj packages and openjdk-built jars
On 07/18/2012 02:48 PM, Rene Engelhard wrote: > On Wed, Jul 18, 2012 at 02:28:42PM +0100, Andrew Haley wrote: >> 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. > > Well, they obviously have the .jars as a compile-time dependency :) > > And that is the point of the question: What happens if the jar.so > was built from a gcj-built jar but then the jar installedis built with > OpenJDK? Noop? Assuming that both Java compilers are correct, nothing exciting. No more than if you mix Java compilers when building libraries. I wouldn't do it myself, though. 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/5006c702.7040...@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/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/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/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 ]
> [Loaded (pre-compiled) gnu.gcj.convert.Input_8859_1 from ]
> [Loaded (BC-compiled) org.eclipse.jdt.internal.compiler.env.AccessRestriction
> from (file:/usr/share/java/eclipse-ecj-3.5.1.jar )]
> [Loaded (BC-compiled)
> org.eclipse.jdt.internal.compiler.batch.ClasspathSourceJar from
> (file:/usr/share/java/eclipse-ecj-3.5.1.jar )]
> [Loaded (BC-compiled) org.eclipse.jdt.internal.compiler.batch.ClasspathJar
> from (file:/usr/share/java/eclipse-ecj-3.5.1.jar )]
> [Loaded (BC-compiled)
> org.eclipse.jdt.internal.compiler.batch.ClasspathLocation from
> (file:/usr/share/java/eclipse-ecj-3.5.1.jar )]
> [Loaded (BC-compiled)
> org.eclipse.jdt.internal.compiler.batch.ClasspathDirectory from
> (file:/usr/share/java/eclipse-ecj-3.5.1.jar )]
> [Loaded (BC-compiled)
> org.eclipse.jdt.internal.compiler.env.NameEnvironmentAnswer from
> (file:/usr/share/java/eclipse-ecj-3.5.1.jar )]
> [Loaded (BC-compiled)
> org.eclipse.jdt.internal.compiler.batch.ClasspathDirectory$1 from
> (file:/usr/share/java/eclipse-ecj-3.5.1.jar )]
> [Loaded (BC-compiled)
> org.eclipse.jdt.internal.compiler.classfmt.ClassFileReader from
> (file:/usr/share/java/eclipse-ecj-3.5.1.jar )]
> [Loaded (BC-compiled)
> org.eclipse.jdt.internal.compiler.classfmt.ClassFileStruct from
> (file:/usr/share/java/eclipse-ecj-3.5.1.jar )]
> [Loaded (pre-compiled)
> org.eclipse.jdt.internal.compiler.env.IBinaryNestedType from
> (file:/usr/share/java/eclipse-ecj-3.5.1.jar )]
> [Loaded (pre-compiled) org.eclipse.jdt.internal.compiler.env.IBinaryField
> from (file:/usr/share/java/eclipse-ecj-3.5.1.jar )]
> [Loaded (pre-compiled) org.eclipse.jdt.internal.compiler.env.IGenericField
> from (file:/usr/share/java/eclipse-ecj-3.5.1.jar )]
> [Loaded (pre-compiled) org.eclipse.jdt.internal.compiler.env.IBinaryMethod
> from (file:/usr/share/java/eclipse-ecj-3.5.1.jar )]
> [Loaded (pre-compiled) org.eclipse.jdt.internal.compiler.env.IGenericMethod
> from (file:/usr/share/java/eclipse-ecj-3.5.1.jar )]
> [Loaded (BC-compiled) org.eclipse.jdt.internal.compiler.util.ManifestAnalyzer
> from (file:/usr/share/java/eclipse-ecj-3.5.1.jar )]
> [Loaded (BC-compiled)
> org.eclipse.jdt.internal.compiler.classfmt.ClassFormatException from
> (file:/usr/share/java/eclipse-ecj-3.5.1.jar )]
> [Loaded (pre-compiled) java.lang.ArrayIndexOutOfBoundsException from source>]
> [Loaded (pre-compiled) java.lang.IndexOutOfBoundsException from source>]
> [Loaded (pre-compiled) java.util.Hashtable$1 from ]
> [Loaded (pre-compiled) java.util.Hashtable$KeyIterator from ]
> [Loaded (pre-compiled) java.util.Collections$8 from ]
> Exception in thread "main" [Loaded (pre-compiled) gnu.gcj.runtime.NameFinder
> from ]
> [Loaded (pre-compiled) gnu.gcj.runtime.NameFinder$Addr2Line from source>]
> [Loaded (pre-compiled) java.lang.PosixProcess from ]
> [Loaded (pre-compiled) java.lang.Process from ]
> [Loaded (pre-compiled) java.lang.PosixProcess$ProcessManager from source>]
> [Loaded (pre-compiled) java.util.LinkedList from ]
> [Loaded (pre-compiled) java.util.AbstractSequentialList from ]
> [Loaded (pre-compiled) java.util.Deque from ]
> [Loaded (pre-compiled) java.util.Queue from ]
> [Loaded (pre-compiled) java.util.LinkedList$Entry from ]
> [Loaded (pre-compiled) java.util.LinkedList$LinkedListItr from source>]
> [Loaded (pre-compiled) java.util.ListIterator from ]
> [Loaded (pre-compiled) java.io.BufferedWriter from ]
> [Loaded (pre-compiled) java.lang.Throwable$StaticData from ]
> 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
> fstat64(3, {st_mode=S_IFREG|0644, st_size=1282644, ...}) = 0
> fstat64(3,
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/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/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: 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-.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/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-.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: 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/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/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). 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:23 AM, Andrew Haley 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: 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 2>&1 ; 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:15 AM, Andrew Haley 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: 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 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 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: 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: RFS: trang 20030619-7 (QA upload)
Michael Schutte wrote: > On Sat, Sep 06, 2008 at 02:23:51PM +0100, Andrew Haley wrote: >> 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 >>> […] >> I'm guessing that there was a missing -findirect-dispatch -Bsymbolic. > > Thanks for the tip, but -findirect-dispatch was already there, and > adding -Bsymbolic does not fix the problem. OK. I still don't really understand what was causing the problem. There must be something peculiar about the way that it was being built. As long as the classes are compiled with -findirect-dispatch -Bsymbolic, built into a shared library, the library added to the database, and the bootclasspath pointed at the jarfiles, everything should be fine. I'm guessing that what happens here is that the org.relaxng classes are compiled into an executable in the hope that these classes will be preferred to the ones of the same name in libgcj. >> 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. > > # aptitude install devscripts > $ dget -xu http://alioth.debian.org/~michi-guest/packages/trang_20030619-7.dsc > $ cd trang-20030619 > > For your convenience, I’ve also attached a patch between the buggy -6.1 > and my -7. Yeah, I see that you've renamed the classes to avoid gcj finding its own versions. 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;
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: 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: Bug#432541: eclipse-cdt FTBFS with gcj-4.2
Andrew Haley wrote:
> Andrew Haley wrote:
>> 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.
OK, and the *reason* for this is that IPluginDescriptor is loaded not
from eclipse/plugins/org.eclipse.core.runtime_3.3.100.v20070530.jar
but from
eclipse/plugins/org.eclipse.core.runtime.compatibility.registry_3.2.100.v20070316/runtime_registry_compatibility.jar
So, if you ask IPluginDescriptor's class loader to find Plugin it
throws a ClassNotFoundException.
The only files in runtime_registry_compatibility.jar are:
org/eclipse/core/internal/registry/BundleHelper.class
org/eclipse/core/internal/registry/ExtensionHandle.class
org/eclipse/core/internal/registry/ExtensionPointHandle.class
org/eclipse/core/internal/registry/RegistryCompatibilityHelper.class
org/eclipse/core/runtime/IExtension.class
org/eclipse/core/runtime/IExtensionPoint.class
org/eclipse/core/runtime/IPluginDescriptor.class
So, I think I now have enough to write a test case. Two class
loaders, one of which loads a subset of the other's classes. Call
an interface in the class defined by the subset class loader and
see what happens.
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:
> Michael Koch wrote:
>> On Sun, Mar 02, 2008 at 12:01:03PM +0000, 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
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 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: 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 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
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 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 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
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: 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: 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: FreeMind and gcj [Re: Help needed on the Java policy]
Eric Lavarde wrote: Hi Andrew, Andrew Haley wrote: I guess it depends on whether the program fails because a particular runtime has bugs or because the program depends on something it shouldn't use, such as com.sun.* classes. We're pretty complete with respect to 1.4, so I'd like to know what this problem actually is. Well, I suspect that the classpath team and associated do concentrate their effort on the non-AWT/Swing classes because Apache/Server-classes and Eclipse don't use them. I think this will come as a terrible shock to those people who spent so much time writing the GUI stuff. In short, FreeMind 0.7.1 (the one in unstable) starts very well with the latest gcj, doesn't spit any error, but is completely unusable (and ugly). Ah, OK, so we're talking about AWT bugs. I admit I don't know very much about that side of Classpath. The notion that Classpath "doesn't care" about non-server applications seems to be very common on this list. 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: Help needed on the Java policy
Michael Koch wrote: On Sun, Jan 27, 2008 at 08:35:22PM +0100, Eric Lavarde wrote: Hi, I'm fighting a bit with the current state of the Java policy, and it has hit pretty hard because FreeMind isn't in testing anymore because of this (see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=436206). OK, starting from the beginning: 1. FreeMind 0.7.1 works only with Sun's Java (let's assume 1.4 only for the sake of simplicity). 2. i.e. I make my package depend on j2re1.4 | java2-runtime, the first is necessary, the second is given by the policy. 3. the issue is that anybody can then decide to fulfill the dependency by installing whatever provides java2-runtime, even if I perfectly know that it won't work. So, how can I fix this and respect the policy? Additional question: the Java RE packages created with java-package used to depend on some X libraries, the sun-javaN-jre packages don't anymore. What is the dependency one should best use for Java programs with an (X-)Gui? Personally I would just depend on some working runtime and on java(2)-runtime and then forward all bugs specific to some runtime to the affected runtime. This help to gets the runtimes fixed. Otherwise they will never get fixed because people dont know the problems. I guess it depends on whether the program fails because a particular runtime has bugs or because the program depends on something it shouldn't use, such as com.sun.* classes. We're pretty complete with respect to 1.4, so I'd like to know what this problem actually is. Andrew. -- 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: 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?
Andrew Haley writes: > gcj is already v5 language compatible, and the library is complete > enough for general use. Actually, that's not *strictly* true. The more recently released gcj is based on on the Java 1.4, but Fedora and a bunch of other distros are shipping pre-releases of the next gcj. 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: 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: 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: > 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 ] > > > > 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 )] > ... and for SWT... > [Loaded (bytecode) org.eclipse.swt.SWT from > (file:/usr/share/java/swt.jar )] 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: 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 ] 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: > 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#432541: eclipse-cdt FTBFS
Thomas Girard writes: > It built successfully in June[2], and started to fail building in July[3]. Ping Doko: what did you change in this time window? 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#432541: eclipse-cdt FTBFS
Thomas Girard writes: > Le mercredi 10 octobre 2007 à 12:36 +0200, Thomas Girard a écrit : > > Just another hint on this one: using etch to recompile eclipse-cdt > > *does* work. So it's likely a problem in the toolchain. > > Moving from an etch chroot to sid, I was able to find out that the > following upgrades do not impact eclipse-cdt compilation: > * libc6 2.6.1-6 > * ant 1.7.0-3 > * eclipse 3.2.2-4 > > This means one of the following packages is causing eclipse-cdt to > FTBFS: > * ecj > * gij/gcj > > Unfortunately, these packages have to be updated at once. > > Any idea how to find out which one could be the culprit? gcj's class loading machanism hasn't changed. Andrew Overholt <[EMAIL PROTECTED]> thinks there's probably something wrong with the OSGI configuration, and the fact that the first exception also happens with Sun's VM must be a clue. Has this version of Eclipse and Eclipse CDT been built successfully on Debian/gcj before now, or is it new? 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: Fw: Re: Java interpreter on ARM GNU/Linux
Riku Voipio writes: > On Thu, Jul 12, 2007 at 11:03:22PM -0400, Daniel Jacobowitz wrote: > > On Thu, Jul 12, 2007 at 11:53:19PM +0100, Wookey wrote: > > > I can work around some of the failures, but I can't really be > > > bothered: the real fix for this is EABI. > > > Unfortunately, the EABI won't fix this either. In its native form it > > supported neither forced unwinding nor _Unwind_Backtrace; we added > > forced unwinding for the benefit of NPTL (though we're still talking > > to ARM intermittently about its semantics). But no one's tried to > > make _Unwind_Backtrace work yet, and it's not clear how to. To me > > anyway. I've thought about recognizing the standard and/or GNU > > personality routines in libgcc... > > Due to the amount of core libraries and tools building java bindings, > this is pretty much the top technical roadblock[1] on current debian > arm eabi port. Interesting. My usual reponse to this is "get me hardware running the OS and I'l 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: 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: gcj-4.1/arm
Matthias Klose writes: > > I didn't see this failure yet. So maybe this is a bug in the libffi > backport for arm? btw, Martin Michlmayr checked that Phil Blundell has > a copyright assignment for GCC, so if somebody updates the arm libffi > support for the trunk, I assume it can be submitted upstream. Definitely. The problem for a long time has been that Debian had the patches but they were never submitted. 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
[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
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: Plans about OpenJDK ?
Arnaud Vandyck writes: > On 5/19/07, Matthias Klose <[EMAIL PROTECTED]> wrote: > [...] > > Because openJDK won't be available for all architectures we will > > have to use gcj for most of our architectures. > > That could lead to problems when we'll have a dfsg openjdk, it'll be > on x86, x64, but what will be the status of other arches? > > What will we do with packages that needs openjdk to build and run? > Will they be in main but only for x64 and x64 arches? > > Is there plans to include code from cacao or jamvm? or to port the vm > on other arches? > > Maybe it's too early to answer, but when we'll have openjdk in our > pool, the question will raise from users on arches !=(x86|x64). There is supposedly a protable interpreter in OpenJDK. We (@ Red Hat) are investigating this for other arches. 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: 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: 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
Steve Langasek writes: > On Mon, Oct 23, 2006 at 01:18:35AM +0200, Matthias Klose wrote: > > Please consider moving the following packages to testing: > > > - 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. The testsuite > > in 4.0 shows over 100 test failures, in 4.1 over 700. Reverting back > > to 4.0 for arm would mean to use an older java-gcj-compat for arm as > > well. Another alternative would be to replace the gcj runtime with > > kaffe, using patches from upstream CVS (suggested by Dalibor Topic). > > > For etch, I currently don't have the time and hardware resource to > > spend work on arm. > > Could Andrew be correct that this is a sign of an improved testsuite, > not a regression in the functionality for arm? > > A build failure on arm is also the only thing keeping this updated version > of gcj-4.1 from being hinted into testing, though that seems to have been an > OOD error on the buildd; given back now. Is no-one interested in actually fixing this? We could, for the first time, get gcj running properly on ARM. 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: > > 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 > > > > > 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: 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 > > > 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: 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]
