From orion at cora.nwra.com Tue Oct 2 19:42:11 2007 From: orion at cora.nwra.com (Orion Poplawski) Date: Tue, 02 Oct 2007 13:42:11 -0600 Subject: [fedora-java] Problems compiling Sun Grid Engine code Message-ID: <47029F13.7000501@cora.nwra.com> I'm trying to compile SGE java stuff on Fedora 7 and running into the following error: [java] [javac] 1. ERROR in /builddir/build/BUILD/gridengine/source/classes/org/ggf/drmaa/PartialTimestamp.java (at line 133) [java] [javac] public class PartialTimestamp extends Calendar { [java] [javac] ^^^^^^^^^^^^^^^^ [java] [javac] The type PartialTimestamp must implement the inherited abstract method Comparable.compareTo(Object) Is this a GNU Classpath issue? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From fitzsim at redhat.com Tue Oct 2 21:11:48 2007 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Tue, 02 Oct 2007 17:11:48 -0400 Subject: [fedora-java] Problems compiling Sun Grid Engine code In-Reply-To: <47029F13.7000501@cora.nwra.com> References: <47029F13.7000501@cora.nwra.com> Message-ID: <4702B414.3060005@redhat.com> Orion Poplawski wrote: > I'm trying to compile SGE java stuff on Fedora 7 and running into the > following error: > > [java] [javac] 1. ERROR in > /builddir/build/BUILD/gridengine/source/classes/org/ggf/drmaa/PartialTimestamp.java > (at line 133) > [java] [javac] public class PartialTimestamp extends > Calendar { > [java] [javac] ^^^^^^^^^^^^^^^^ > [java] [javac] The type PartialTimestamp must implement the > inherited abstract method Comparable.compareTo(Object) > > Is this a GNU Classpath issue? Calendar.compareTo was added in 1.5. Is it possible that you're compiling 1.4-level source code? If so, this represents a breakage in source compatibility. The usual resolution is to stub or implement the inherited abstract method. Tom From orion at cora.nwra.com Tue Oct 2 22:29:19 2007 From: orion at cora.nwra.com (Orion Poplawski) Date: Tue, 02 Oct 2007 16:29:19 -0600 Subject: [fedora-java] Problems compiling Sun Grid Engine code In-Reply-To: <4702B414.3060005@redhat.com> References: <47029F13.7000501@cora.nwra.com> <4702B414.3060005@redhat.com> Message-ID: <4702C63F.40402@cora.nwra.com> Thomas Fitzsimmons wrote: > > Calendar.compareTo was added in 1.5. Is it possible that you're > compiling 1.4-level source code? If so, this represents a breakage in > source compatibility. The usual resolution is to stub or implement the > inherited abstract method. > > Tom Changing target from 1.4 to 1.5 in the build.xml file fixed it. Thanks! Next step, where can I find the javacc class for ant? [java] [java] BUILD FAILED [java] [java] /builddir/build/BUILD/gridengine/source/libs/jgdi/build.xml:1060: The following error occurred while executing this line: [java] [java] /builddir/build/BUILD/gridengine/source/libs/jgdi/cullconv/build.xml:49: The following error occurred while executing this line: [java] [java] /builddir/build/BUILD/gridengine/source/libs/jgdi/cullconv/build.xml:62: Could not create task or type of type: javacc. [java] [java] Ant could not find the task or a class this task relies upon. [java] [java] This is common and has a number of causes; the usual [java] [java] solutions are to read the manual pages then download and [java] [java] install needed JAR files, or fix the build file: [java] [java] - You have misspelt 'javacc'. [java] [java] Fix: check your spelling. [java] [java] - The task needs an external JAR file to execute [java] [java] and this is not found at the right place in the classpath. [java] [java] Fix: check the documentation for dependencies. [java] [java] Fix: declare the task. [java] [java] - The task is an Ant optional task and the JAR file and/or libraries [java] [java] implementing the functionality were not found at the time you [java] [java] yourself built your installation of Ant from the Ant sources. [java] [java] Fix: Look in the ANT_HOME/lib for the 'ant-' JAR corresponding to the [java] [java] task and make sure it contains more than merely a META-INF/MANIFEST.MF. [java] [java] If all it contains is the manifest, then rebuild Ant with the needed [java] [java] libraries present in ${ant.home}/lib/optional/ , or alternatively, [java] [java] download a pre-built release version from apache.org [java] [java] - The build file was written for a later version of Ant [java] [java] Fix: upgrade to at least the latest release version of Ant [java] [java] - The task is not an Ant core or optional task [java] [java] and needs to be declared using . [java] [java] - You are attempting to use a task defined using [java] [java] or but have spelt wrong or not [java] [java] defined it at the point of use [java] [java] Remember that for JAR files to be visible to Ant tasks implemented [java] [java] in ANT_HOME/lib, the files must be in the same directory or on the [java] [java] classpath [java] [java] Please neither file bug reports on this problem, nor email the [java] [java] Ant mailing lists, until all of these causes have been explored, [java] [java] as this is not an Ant bug. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From orion at cora.nwra.com Tue Oct 2 23:10:33 2007 From: orion at cora.nwra.com (Orion Poplawski) Date: Tue, 02 Oct 2007 17:10:33 -0600 Subject: [fedora-java] Problems compiling Sun Grid Engine code In-Reply-To: <4702C63F.40402@cora.nwra.com> References: <47029F13.7000501@cora.nwra.com> <4702B414.3060005@redhat.com> <4702C63F.40402@cora.nwra.com> Message-ID: <4702CFE9.3080802@cora.nwra.com> Orion Poplawski wrote: > Thomas Fitzsimmons wrote: >> >> Calendar.compareTo was added in 1.5. Is it possible that you're >> compiling 1.4-level source code? If so, this represents a breakage in >> source compatibility. The usual resolution is to stub or implement >> the inherited abstract method. >> >> Tom > > Changing target from 1.4 to 1.5 in the build.xml file fixed it. Thanks! > > Next step, where can I find the javacc class for ant? > Ah, dejavu: https://bugzilla.redhat.com/show_bug.cgi?id=225196 -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From pcheung at redhat.com Wed Oct 3 11:32:42 2007 From: pcheung at redhat.com (Permaine Cheung) Date: Wed, 03 Oct 2007 07:32:42 -0400 Subject: [fedora-java] Problems compiling Sun Grid Engine code In-Reply-To: <4702CFE9.3080802@cora.nwra.com> References: <47029F13.7000501@cora.nwra.com> <4702B414.3060005@redhat.com> <4702C63F.40402@cora.nwra.com> <4702CFE9.3080802@cora.nwra.com> Message-ID: <47037DDA.7000901@redhat.com> Orion Poplawski wrote: > Orion Poplawski wrote: >> Thomas Fitzsimmons wrote: >>> >>> Calendar.compareTo was added in 1.5. Is it possible that you're >>> compiling 1.4-level source code? If so, this represents a breakage >>> in source compatibility. The usual resolution is to stub or >>> implement the inherited abstract method. >>> >>> Tom >> >> Changing target from 1.4 to 1.5 in the build.xml file fixed it. Thanks! >> >> Next step, where can I find the javacc class for ant? >> > > Ah, dejavu: > > https://bugzilla.redhat.com/show_bug.cgi?id=225196 > Seems like you need ant-nodeps. From orion at cora.nwra.com Wed Oct 3 14:22:18 2007 From: orion at cora.nwra.com (orion at cora.nwra.com) Date: Wed, 3 Oct 2007 08:22:18 -0600 (MDT) Subject: [fedora-java] Problems compiling Sun Grid Engine code In-Reply-To: <47037DDA.7000901@redhat.com> References: <47029F13.7000501@cora.nwra.com> <4702B414.3060005@redhat.com> <4702C63F.40402@cora.nwra.com> <4702CFE9.3080802@cora.nwra.com> <47037DDA.7000901@redhat.com> Message-ID: <1642.71.208.46.232.1191421338.squirrel@www.co-ra.com> > Orion Poplawski wrote: >> Orion Poplawski wrote: >>> Thomas Fitzsimmons wrote: >>>> >>>> Calendar.compareTo was added in 1.5. Is it possible that you're >>>> compiling 1.4-level source code? If so, this represents a breakage >>>> in source compatibility. The usual resolution is to stub or >>>> implement the inherited abstract method. >>>> >>>> Tom >>> >>> Changing target from 1.4 to 1.5 in the build.xml file fixed it. >>> Thanks! >>> >>> Next step, where can I find the javacc class for ant? >>> >> >> Ah, dejavu: >> >> https://bugzilla.redhat.com/show_bug.cgi?id=225196 >> > Seems like you need ant-nodeps. > Indeed, that gets me farther, thanks! No I get: [java] [java] BUILD FAILED [java] [java] /builddir/build/BUILD/gridengine/source/libs/jgdi/build.xml:1060: The following error occurred while executing this line: [java] [java] /builddir/build/BUILD/gridengine/source/libs/jgdi/cullconv/build.xml:49: The following error occurred while executing this line: [java] [java] /builddir/build/BUILD/gridengine/source/libs/jgdi/cullconv/build.xml:62: JavaCC home must be a valid directory. The relevant section of build.xml is: Now, I have no idea what javacc.home is being set to, or what it should be, or how to set it if I need to. Any ideas? - Orion From pcheung at redhat.com Wed Oct 3 16:25:29 2007 From: pcheung at redhat.com (Permaine Cheung) Date: Wed, 03 Oct 2007 12:25:29 -0400 Subject: [fedora-java] Problems compiling Sun Grid Engine code In-Reply-To: <1642.71.208.46.232.1191421338.squirrel@www.co-ra.com> References: <47029F13.7000501@cora.nwra.com> <4702B414.3060005@redhat.com> <4702C63F.40402@cora.nwra.com> <4702CFE9.3080802@cora.nwra.com> <47037DDA.7000901@redhat.com> <1642.71.208.46.232.1191421338.squirrel@www.co-ra.com> Message-ID: <4703C279.7040509@redhat.com> An HTML attachment was scrubbed... URL: From orion at cora.nwra.com Wed Oct 3 16:28:50 2007 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 03 Oct 2007 10:28:50 -0600 Subject: [fedora-java] Problems compiling Sun Grid Engine code In-Reply-To: <4703C279.7040509@redhat.com> References: <47029F13.7000501@cora.nwra.com> <4702B414.3060005@redhat.com> <4702C63F.40402@cora.nwra.com> <4702CFE9.3080802@cora.nwra.com> <47037DDA.7000901@redhat.com> <1642.71.208.46.232.1191421338.squirrel@www.co-ra.com> <4703C279.7040509@redhat.com> Message-ID: <4703C342.6090000@cora.nwra.com> Permaine Cheung wrote: > Do you have javacc installed? I think you can try setting javacc.home to > /usr/share/java/ where javacc.jar is. Yup. Setting javacchome to /usr/share/java in build.xml works. Ah, just found the build.properties file that set javacc.home. I'll fix that. Thanks again! -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From aph at redhat.com Fri Oct 5 12:47:29 2007 From: aph at redhat.com (Andrew Haley) Date: Fri, 5 Oct 2007 13:47:29 +0100 Subject: [fedora-java] default vm memory settings for fedora eclipse In-Reply-To: <20070911121059.GA5059@redhat.com> References: <1188588879.14892.11.camel@plug> <20070831210446.GA3447@redhat.com> <1188596252.30138.50.camel@localhost.localdomain> <20070910175050.GA7647@redhat.com> <20070911092041.177b38f3@localhost.localdomain> <20070911121059.GA5059@redhat.com> Message-ID: <18182.12897.376758.264146@zebedee.pink> Andrew Overholt writes: > * S?ren Mathiasen [2007-09-11 03:55]: > > > > Could be nice if the eclipse startup script contained some code to > > detect the memory size, and according to that set the permsize to > > mem/10 and Xms and Xmx to mem/2 or something close to that. > > Yeah, but we don't have and don't want to have a wrapper script. I > guess we could add it into the binary launcher ... I think we should just change the limits. For example, it's a fairly trivial matter to change the default MaxPermSize in hotspot/src/cpu/x86/vm/c2_globals_x86.hpp from the current define_pd_global(uintx, MaxPermSize, ScaleForWordSize(64*M)); to something more suitable. Linux doesn't actually allocate memory until it's used, so I'm not convinced that the "keep the limit small for users with small memory" actually applies. So, why don't I just patch IcedTea to use your values as defaults? You can then try the resulting IcedTea, make dure it works, and it'll be in the next IcedTea release. If anyone screams we can always change the default back down again, but I doubt very much it'll ever happen. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From overholt at redhat.com Fri Oct 5 12:49:28 2007 From: overholt at redhat.com (Andrew Overholt) Date: Fri, 5 Oct 2007 08:49:28 -0400 Subject: [fedora-java] default vm memory settings for fedora eclipse In-Reply-To: <18182.12897.376758.264146@zebedee.pink> References: <1188588879.14892.11.camel@plug> <20070831210446.GA3447@redhat.com> <1188596252.30138.50.camel@localhost.localdomain> <20070910175050.GA7647@redhat.com> <20070911092041.177b38f3@localhost.localdomain> <20070911121059.GA5059@redhat.com> <18182.12897.376758.264146@zebedee.pink> Message-ID: <20071005124927.GB21567@redhat.com> * Andrew Haley [2007-10-05 08:47]: > So, why don't I just patch IcedTea to use your values as defaults? That would be awesome. I think Tom Fitzsimmons might actually have some better values, but anything higher would rock. Thanks, Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From aph at redhat.com Fri Oct 5 13:01:32 2007 From: aph at redhat.com (Andrew Haley) Date: Fri, 5 Oct 2007 14:01:32 +0100 Subject: [fedora-java] default vm memory settings for fedora eclipse In-Reply-To: <20071005124927.GB21567@redhat.com> References: <1188588879.14892.11.camel@plug> <20070831210446.GA3447@redhat.com> <1188596252.30138.50.camel@localhost.localdomain> <20070910175050.GA7647@redhat.com> <20070911092041.177b38f3@localhost.localdomain> <20070911121059.GA5059@redhat.com> <18182.12897.376758.264146@zebedee.pink> <20071005124927.GB21567@redhat.com> Message-ID: <18182.13740.498634.360200@zebedee.pink> Andrew Overholt writes: > * Andrew Haley [2007-10-05 08:47]: > > So, why don't I just patch IcedTea to use your values as defaults? > > That would be awesome. I think Tom Fitzsimmons might actually have some > better values, but anything higher would rock. Alright, so I need to do the experiment: Duplicate the failures -- you must tell me exactly what to do. Rebuild with new values. Confirm that the failures no longer happen. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From overholt at redhat.com Fri Oct 5 13:16:07 2007 From: overholt at redhat.com (Andrew Overholt) Date: Fri, 5 Oct 2007 09:16:07 -0400 Subject: [fedora-java] default vm memory settings for fedora eclipse In-Reply-To: <18182.13740.498634.360200@zebedee.pink> References: <1188588879.14892.11.camel@plug> <20070831210446.GA3447@redhat.com> <1188596252.30138.50.camel@localhost.localdomain> <20070910175050.GA7647@redhat.com> <20070911092041.177b38f3@localhost.localdomain> <20070911121059.GA5059@redhat.com> <18182.12897.376758.264146@zebedee.pink> <20071005124927.GB21567@redhat.com> <18182.13740.498634.360200@zebedee.pink> Message-ID: <20071005131606.GA22331@redhat.com> * Andrew Haley [2007-10-05 09:01]: > Andrew Overholt writes: > > * Andrew Haley [2007-10-05 08:47]: > > > So, why don't I just patch IcedTea to use your values as defaults? > > > > That would be awesome. I think Tom Fitzsimmons might actually have some > > better values, but anything higher would rock. > > Alright, so I need to do the experiment: > > Duplicate the failures -- you must tell me exactly what to do. > > Rebuild with new values. > > Confirm that the failures no longer happen. It may be easier for me to do this. Josh Sumali can help as well as he can now reliably crash Eclipse within a few minutes. It's difficult to reproduce with a simple "run these steps" and even with a large workspace, I find it happens erratically. When was the last time I told you something was wrong and it was easy to reproduce? :) Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From aph at redhat.com Fri Oct 5 13:20:45 2007 From: aph at redhat.com (Andrew Haley) Date: Fri, 5 Oct 2007 14:20:45 +0100 Subject: [fedora-java] default vm memory settings for fedora eclipse In-Reply-To: <20071005131606.GA22331@redhat.com> References: <1188588879.14892.11.camel@plug> <20070831210446.GA3447@redhat.com> <1188596252.30138.50.camel@localhost.localdomain> <20070910175050.GA7647@redhat.com> <20070911092041.177b38f3@localhost.localdomain> <20070911121059.GA5059@redhat.com> <18182.12897.376758.264146@zebedee.pink> <20071005124927.GB21567@redhat.com> <18182.13740.498634.360200@zebedee.pink> <20071005131606.GA22331@redhat.com> Message-ID: <18182.14893.588833.641445@zebedee.pink> Andrew Overholt writes: > * Andrew Haley [2007-10-05 09:01]: > > Andrew Overholt writes: > > > * Andrew Haley [2007-10-05 08:47]: > > > > So, why don't I just patch IcedTea to use your values as defaults? > > > > > > That would be awesome. I think Tom Fitzsimmons might actually have some > > > better values, but anything higher would rock. > > > > Alright, so I need to do the experiment: > > > > Duplicate the failures -- you must tell me exactly what to do. > > > > Rebuild with new values. > > > > Confirm that the failures no longer happen. > > It may be easier for me to do this. Josh Sumali can help as well as he > can now reliably crash Eclipse within a few minutes. It's difficult to > reproduce with a simple "run these steps" and even with a large > workspace, I find it happens erratically. OK, I'll make two packages, one with and one without the patch. Which arch do you prefer? > When was the last time I told you something was wrong and it was easy to > reproduce? :) Uh, yeah. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From overholt at redhat.com Fri Oct 5 13:52:02 2007 From: overholt at redhat.com (Andrew Overholt) Date: Fri, 5 Oct 2007 09:52:02 -0400 Subject: [fedora-java] default vm memory settings for fedora eclipse In-Reply-To: <18182.14893.588833.641445@zebedee.pink> References: <20070831210446.GA3447@redhat.com> <1188596252.30138.50.camel@localhost.localdomain> <20070910175050.GA7647@redhat.com> <20070911092041.177b38f3@localhost.localdomain> <20070911121059.GA5059@redhat.com> <18182.12897.376758.264146@zebedee.pink> <20071005124927.GB21567@redhat.com> <18182.13740.498634.360200@zebedee.pink> <20071005131606.GA22331@redhat.com> <18182.14893.588833.641445@zebedee.pink> Message-ID: <20071005135201.GA3653@redhat.com> * Andrew Haley [2007-10-05 09:20]: > Andrew Overholt writes: > > * Andrew Haley [2007-10-05 09:01]: > > > Andrew Overholt writes: > > > > * Andrew Haley [2007-10-05 08:47]: > > > > > So, why don't I just patch IcedTea to use your values as defaults? > > > > > > > > That would be awesome. I think Tom Fitzsimmons might actually have some > > > > better values, but anything higher would rock. > > > > > > Alright, so I need to do the experiment: > > > > > > Duplicate the failures -- you must tell me exactly what to do. > > > > > > Rebuild with new values. > > > > > > Confirm that the failures no longer happen. > > > > It may be easier for me to do this. Josh Sumali can help as well as he > > can now reliably crash Eclipse within a few minutes. It's difficult to > > reproduce with a simple "run these steps" and even with a large > > workspace, I find it happens erratically. > > OK, I'll make two packages, one with and one without the patch. Which > arch do you prefer? i386. Thanks, Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fitzsim at redhat.com Fri Oct 5 13:57:23 2007 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Fri, 05 Oct 2007 09:57:23 -0400 Subject: [fedora-java] default vm memory settings for fedora eclipse In-Reply-To: <18182.12897.376758.264146@zebedee.pink> References: <1188588879.14892.11.camel@plug> <20070831210446.GA3447@redhat.com> <1188596252.30138.50.camel@localhost.localdomain> <20070910175050.GA7647@redhat.com> <20070911092041.177b38f3@localhost.localdomain> <20070911121059.GA5059@redhat.com> <18182.12897.376758.264146@zebedee.pink> Message-ID: <470642C3.7090805@redhat.com> Andrew Haley wrote: > Andrew Overholt writes: > > * S?ren Mathiasen [2007-09-11 03:55]: > > > > > > Could be nice if the eclipse startup script contained some code to > > > detect the memory size, and according to that set the permsize to > > > mem/10 and Xms and Xmx to mem/2 or something close to that. > > > > Yeah, but we don't have and don't want to have a wrapper script. I > > guess we could add it into the binary launcher ... > > I think we should just change the limits. For example, it's a fairly > trivial matter to change the default MaxPermSize in > hotspot/src/cpu/x86/vm/c2_globals_x86.hpp from the current > > define_pd_global(uintx, MaxPermSize, ScaleForWordSize(64*M)); > > to something more suitable. Linux doesn't actually allocate memory > until it's used, so I'm not convinced that the "keep the limit small > for users with small memory" actually applies. > > So, why don't I just patch IcedTea to use your values as defaults? I'd rather MaxPermSize be disabled entirely. Upping the limit just puts off the OOM JVM crash, when really the kernel should be left to handle memory pressure. Tom From aph at redhat.com Fri Oct 5 14:03:27 2007 From: aph at redhat.com (Andrew Haley) Date: Fri, 5 Oct 2007 15:03:27 +0100 Subject: [fedora-java] default vm memory settings for fedora eclipse In-Reply-To: <470642C3.7090805@redhat.com> References: <1188588879.14892.11.camel@plug> <20070831210446.GA3447@redhat.com> <1188596252.30138.50.camel@localhost.localdomain> <20070910175050.GA7647@redhat.com> <20070911092041.177b38f3@localhost.localdomain> <20070911121059.GA5059@redhat.com> <18182.12897.376758.264146@zebedee.pink> <470642C3.7090805@redhat.com> Message-ID: <18182.17455.401871.636388@zebedee.pink> Thomas Fitzsimmons writes: > Andrew Haley wrote: > > Andrew Overholt writes: > > > * S?ren Mathiasen [2007-09-11 03:55]: > > > > > > > > Could be nice if the eclipse startup script contained some code to > > > > detect the memory size, and according to that set the permsize to > > > > mem/10 and Xms and Xmx to mem/2 or something close to that. > > > > > > Yeah, but we don't have and don't want to have a wrapper script. I > > > guess we could add it into the binary launcher ... > > > > I think we should just change the limits. For example, it's a fairly > > trivial matter to change the default MaxPermSize in > > hotspot/src/cpu/x86/vm/c2_globals_x86.hpp from the current > > > > define_pd_global(uintx, MaxPermSize, ScaleForWordSize(64*M)); > > > > to something more suitable. Linux doesn't actually allocate memory > > until it's used, so I'm not convinced that the "keep the limit small > > for users with small memory" actually applies. > > > > So, why don't I just patch IcedTea to use your values as defaults? > > I'd rather MaxPermSize be disabled entirely. Upping the limit just puts > off the OOM JVM crash, when really the kernel should be left to handle > memory pressure. I can understand why you say so, but I don't think this is a good idea. Sun's Java has never been tested with an unlimited MaxPermSize, so this would putting us into Space Cadet Explorer territory for AFAICS no important reason. Maybe one day we can do this, but for the time being let's just try changing the defaults. OK? Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From jsumali at redhat.com Fri Oct 5 14:05:59 2007 From: jsumali at redhat.com (Joshua Sumali) Date: Fri, 05 Oct 2007 10:05:59 -0400 Subject: [fedora-java] default vm memory settings for fedora eclipse In-Reply-To: <20071005131606.GA22331@redhat.com> References: <1188588879.14892.11.camel@plug> <20070831210446.GA3447@redhat.com> <1188596252.30138.50.camel@localhost.localdomain> <20070910175050.GA7647@redhat.com> <20070911092041.177b38f3@localhost.localdomain> <20070911121059.GA5059@redhat.com> <18182.12897.376758.264146@zebedee.pink> <20071005124927.GB21567@redhat.com> <18182.13740.498634.360200@zebedee.pink> <20071005131606.GA22331@redhat.com> Message-ID: <470644C7.8040709@redhat.com> Andrew Overholt wrote: > * Andrew Haley [2007-10-05 09:01]: > >> Andrew Overholt writes: >> > * Andrew Haley [2007-10-05 08:47]: >> > > So, why don't I just patch IcedTea to use your values as defaults? >> > >> > That would be awesome. I think Tom Fitzsimmons might actually have some >> > better values, but anything higher would rock. >> >> Alright, so I need to do the experiment: >> >> Duplicate the failures -- you must tell me exactly what to do. >> >> Rebuild with new values. >> >> Confirm that the failures no longer happen. >> > > It may be easier for me to do this. Josh Sumali can help as well as he > can now reliably crash Eclipse within a few minutes. It's difficult to > reproduce with a simple "run these steps" and even with a large > workspace, I find it happens erratically. > > When was the last time I told you something was wrong and it was easy to > reproduce? :) > > Andrew > > ------------------------------------------------------------------------ > > -- > fedora-devel-java-list mailing list > fedora-devel-java-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-java-list > There's no real set list of things to do, but what I find works best is doing many *different* things (as to load classes into perm gen space). This typically involves doing things like: -cvs update, cvs diffing -Source > Format , Source > Clean Up -Right click on a project, enable maven, play around with the maven settings -Running programs differently (Right click > run as > java applet, or java application, OSGI, etc) -Debugging programs differently -Looking at eclipse help (Help Contents, Dynamic Help, etc) Using more plugins would probably be easier in terms of crashing Eclipse, but I can do so with just Maven and Mylyn on Eclipse as plugins (and a 64mb permgen limit). Josh From aph at redhat.com Fri Oct 5 14:08:23 2007 From: aph at redhat.com (Andrew Haley) Date: Fri, 5 Oct 2007 15:08:23 +0100 Subject: [fedora-java] default vm memory settings for fedora eclipse In-Reply-To: <470644C7.8040709@redhat.com> References: <1188588879.14892.11.camel@plug> <20070831210446.GA3447@redhat.com> <1188596252.30138.50.camel@localhost.localdomain> <20070910175050.GA7647@redhat.com> <20070911092041.177b38f3@localhost.localdomain> <20070911121059.GA5059@redhat.com> <18182.12897.376758.264146@zebedee.pink> <20071005124927.GB21567@redhat.com> <18182.13740.498634.360200@zebedee.pink> <20071005131606.GA22331@redhat.com> <470644C7.8040709@redhat.com> Message-ID: <18182.17751.906026.764418@zebedee.pink> Joshua Sumali writes: > There's no real set list of things to do, but what I find works best is > doing many *different* things (as to load classes into perm gen space). > This typically involves doing things like: > > -cvs update, cvs diffing > -Source > Format , Source > Clean Up > -Right click on a project, enable maven, play around with the maven settings > -Running programs differently (Right click > run as > java applet, or > java application, OSGI, etc) > -Debugging programs differently > -Looking at eclipse help (Help Contents, Dynamic Help, etc) > > Using more plugins would probably be easier in terms of crashing > Eclipse, but I can do so with just Maven and Mylyn on Eclipse as plugins > (and a 64mb permgen limit). OK, I'm gonna let you do it. :-) I can supply two binaries for x86_64 quite easily. I can do it for 386 if I have to, but that's much harder for me. (32-bit is *so * twentieth century!) Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From fitzsim at redhat.com Fri Oct 5 14:10:55 2007 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Fri, 05 Oct 2007 10:10:55 -0400 Subject: [fedora-java] default vm memory settings for fedora eclipse In-Reply-To: <18182.17455.401871.636388@zebedee.pink> References: <1188588879.14892.11.camel@plug> <20070831210446.GA3447@redhat.com> <1188596252.30138.50.camel@localhost.localdomain> <20070910175050.GA7647@redhat.com> <20070911092041.177b38f3@localhost.localdomain> <20070911121059.GA5059@redhat.com> <18182.12897.376758.264146@zebedee.pink> <470642C3.7090805@redhat.com> <18182.17455.401871.636388@zebedee.pink> Message-ID: <470645EF.4090102@redhat.com> Andrew Haley wrote: > Thomas Fitzsimmons writes: > > Andrew Haley wrote: > > > Andrew Overholt writes: > > > > * S?ren Mathiasen [2007-09-11 03:55]: > > > > > > > > > > Could be nice if the eclipse startup script contained some code to > > > > > detect the memory size, and according to that set the permsize to > > > > > mem/10 and Xms and Xmx to mem/2 or something close to that. > > > > > > > > Yeah, but we don't have and don't want to have a wrapper script. I > > > > guess we could add it into the binary launcher ... > > > > > > I think we should just change the limits. For example, it's a fairly > > > trivial matter to change the default MaxPermSize in > > > hotspot/src/cpu/x86/vm/c2_globals_x86.hpp from the current > > > > > > define_pd_global(uintx, MaxPermSize, ScaleForWordSize(64*M)); > > > > > > to something more suitable. Linux doesn't actually allocate memory > > > until it's used, so I'm not convinced that the "keep the limit small > > > for users with small memory" actually applies. > > > > > > So, why don't I just patch IcedTea to use your values as defaults? > > > > I'd rather MaxPermSize be disabled entirely. Upping the limit just puts > > off the OOM JVM crash, when really the kernel should be left to handle > > memory pressure. > > I can understand why you say so, but I don't think this is a good > idea. Sun's Java has never been tested with an unlimited MaxPermSize, > so this would putting us into Space Cadet Explorer territory for > AFAICS no important reason. Have you checked if there's a way to make MaxPermSize unlimited using command-line options or other configuration hooks (i.e., in ways that Sun probably would have tested)? If removing the limit requires intrusive patching then I'm fine with just setting it "high". Tom From jsumali at redhat.com Fri Oct 5 14:16:44 2007 From: jsumali at redhat.com (Joshua Sumali) Date: Fri, 05 Oct 2007 10:16:44 -0400 Subject: [fedora-java] default vm memory settings for fedora eclipse In-Reply-To: <18182.17751.906026.764418@zebedee.pink> References: <1188588879.14892.11.camel@plug> <20070831210446.GA3447@redhat.com> <1188596252.30138.50.camel@localhost.localdomain> <20070910175050.GA7647@redhat.com> <20070911092041.177b38f3@localhost.localdomain> <20070911121059.GA5059@redhat.com> <18182.12897.376758.264146@zebedee.pink> <20071005124927.GB21567@redhat.com> <18182.13740.498634.360200@zebedee.pink> <20071005131606.GA22331@redhat.com> <470644C7.8040709@redhat.com> <18182.17751.906026.764418@zebedee.pink> Message-ID: <4706474C.1060701@redhat.com> Andrew Haley wrote: > Joshua Sumali writes: > > > There's no real set list of things to do, but what I find works best is > > doing many *different* things (as to load classes into perm gen space). > > This typically involves doing things like: > > > > -cvs update, cvs diffing > > -Source > Format , Source > Clean Up > > -Right click on a project, enable maven, play around with the maven settings > > -Running programs differently (Right click > run as > java applet, or > > java application, OSGI, etc) > > -Debugging programs differently > > -Looking at eclipse help (Help Contents, Dynamic Help, etc) > > > > Using more plugins would probably be easier in terms of crashing > > Eclipse, but I can do so with just Maven and Mylyn on Eclipse as plugins > > (and a 64mb permgen limit). > > OK, I'm gonna let you do it. :-) > > I can supply two binaries for x86_64 quite easily. I can do it for > 386 if I have to, but that's much harder for me. (32-bit is *so * > twentieth century!) > > Andrew. > > At the moment I only have access to a 32 bit machine for testing, but x86_64 could be tested next Tuesday at the earliest (Monday being a holiday). Also, why 2 binaries? Josh From aph at redhat.com Fri Oct 5 14:26:35 2007 From: aph at redhat.com (Andrew Haley) Date: Fri, 5 Oct 2007 15:26:35 +0100 Subject: [fedora-java] default vm memory settings for fedora eclipse In-Reply-To: <4706474C.1060701@redhat.com> References: <1188588879.14892.11.camel@plug> <20070831210446.GA3447@redhat.com> <1188596252.30138.50.camel@localhost.localdomain> <20070910175050.GA7647@redhat.com> <20070911092041.177b38f3@localhost.localdomain> <20070911121059.GA5059@redhat.com> <18182.12897.376758.264146@zebedee.pink> <20071005124927.GB21567@redhat.com> <18182.13740.498634.360200@zebedee.pink> <20071005131606.GA22331@redhat.com> <470644C7.8040709@redhat.com> <18182.17751.906026.764418@zebedee.pink> <4706474C.1060701@redhat.com> Message-ID: <18182.18843.685062.548531@zebedee.pink> Joshua Sumali writes: > Andrew Haley wrote: > > Joshua Sumali writes: > > > > > There's no real set list of things to do, but what I find works best is > > > doing many *different* things (as to load classes into perm gen space). > > > This typically involves doing things like: > > > > > > -cvs update, cvs diffing > > > -Source > Format , Source > Clean Up > > > -Right click on a project, enable maven, play around with the maven settings > > > -Running programs differently (Right click > run as > java applet, or > > > java application, OSGI, etc) > > > -Debugging programs differently > > > -Looking at eclipse help (Help Contents, Dynamic Help, etc) > > > > > > Using more plugins would probably be easier in terms of crashing > > > Eclipse, but I can do so with just Maven and Mylyn on Eclipse as plugins > > > (and a 64mb permgen limit). > > > > OK, I'm gonna let you do it. :-) > > > > I can supply two binaries for x86_64 quite easily. I can do it for > > 386 if I have to, but that's much harder for me. (32-bit is *so * > > twentieth century!) > At the moment I only have access to a 32 bit machine for testing, but > x86_64 could be tested next Tuesday at the earliest (Monday being a > holiday). > > Also, why 2 binaries? Science. :-) I want to prove that it works with one, and not with the other. Since I can't prove that my pre-patch build is identical to the RPM, you have to test both. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From aph at redhat.com Fri Oct 5 14:33:46 2007 From: aph at redhat.com (Andrew Haley) Date: Fri, 5 Oct 2007 15:33:46 +0100 Subject: [fedora-java] default vm memory settings for fedora eclipse In-Reply-To: <470645EF.4090102@redhat.com> References: <1188588879.14892.11.camel@plug> <20070831210446.GA3447@redhat.com> <1188596252.30138.50.camel@localhost.localdomain> <20070910175050.GA7647@redhat.com> <20070911092041.177b38f3@localhost.localdomain> <20070911121059.GA5059@redhat.com> <18182.12897.376758.264146@zebedee.pink> <470642C3.7090805@redhat.com> <18182.17455.401871.636388@zebedee.pink> <470645EF.4090102@redhat.com> Message-ID: <18182.19274.793501.980079@zebedee.pink> Thomas Fitzsimmons writes: > Andrew Haley wrote: > > Thomas Fitzsimmons writes: > > > Andrew Haley wrote: > > > > Andrew Overholt writes: > > > > > > I'd rather MaxPermSize be disabled entirely. Upping the limit just puts > > > off the OOM JVM crash, when really the kernel should be left to handle > > > memory pressure. > > > > I can understand why you say so, but I don't think this is a good > > idea. Sun's Java has never been tested with an unlimited MaxPermSize, > > so this would putting us into Space Cadet Explorer territory for > > AFAICS no important reason. > > Have you checked if there's a way to make MaxPermSize unlimited > using command-line options or other configuration hooks (i.e., in > ways that Sun probably would have tested)? If removing the limit > requires intrusive patching then I'm fine with just setting it > "high". It's really simple: it just limits PermGen expansion to the preset limit: // ...and no larger or smaller than our max and min allowed. desired_size = MAX2(MIN2(desired_size, _max_gen_size), _min_gen_size); assert(desired_size <= _max_gen_size, "just checking"); There's no special case for "unlimited" or anthing like that. In any case, we wouldn't want to prevent users from setting a limit if they wanted one: that would be removing useful functionality. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From pertusus at free.fr Mon Oct 8 21:09:02 2007 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 8 Oct 2007 23:09:02 +0200 Subject: [fedora-java] difficulties to use swt on fedora Message-ID: <20071008210902.GB3088@free.fr> Hello, I wanted to use swt.jar in a software (http://iriverter.sourceforge.net/download.shtml), but it turned out to be quite complicated to achieve. Maybe I am doing something wrong, but if it is not the case, things should certainly be ameliorated. I found swt.jar to be in libswt3-gtk2, in: /usr/lib/eclipse/swt-gtk-3.3.jar Why not in /usr/share/java/swt.jar? The compilation works with javac -classpath /usr/lib/eclipse/swt-gtk-3.3.jar:. org/thestaticvoid/iriverter/DVD.java On fc7, there seems to be a need to do export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/lib/eclipse/ before starting the application or /usr/lib/eclipse/libswt-pi-gtk-3346.so isn't found, but I hadn't that issue in F8: !!! An unhandled exception occured: class java.lang.UnsatisfiedLinkError --- iriverter 0.16 --- --- Settings: --- --- !!! libswt-pi-gtk-3236: libswt-pi-gtk-3236.so: cannot open shared object file: No such file or directory !!! ....... more error messages ............ -- Pat From overholt at redhat.com Mon Oct 8 21:27:43 2007 From: overholt at redhat.com (Andrew Overholt) Date: Mon, 8 Oct 2007 17:27:43 -0400 Subject: [fedora-java] difficulties to use swt on fedora In-Reply-To: <20071008210902.GB3088@free.fr> References: <20071008210902.GB3088@free.fr> Message-ID: <20071008212742.GA5106@redhat.com> Hi, * Patrice Dumas [2007-10-08 17:14]: > /usr/lib/eclipse/swt-gtk-3.3.jar > > Why not in /usr/share/java/swt.jar? It's in %{_libdir} 'cause it's got arch-specific stuff in it. Care to submit a patch for eclipse.spec to add the version-less symlink? > On fc7, there seems to be a need to do > > export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/lib/eclipse/ What VM is this with? Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pertusus at free.fr Tue Oct 9 07:19:18 2007 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 9 Oct 2007 09:19:18 +0200 Subject: [fedora-java] difficulties to use swt on fedora In-Reply-To: <20071008212742.GA5106@redhat.com> References: <20071008210902.GB3088@free.fr> <20071008212742.GA5106@redhat.com> Message-ID: <20071009071918.GA2616@free.fr> On Mon, Oct 08, 2007 at 05:27:43PM -0400, Andrew Overholt wrote: > Hi, > > * Patrice Dumas [2007-10-08 17:14]: > > /usr/lib/eclipse/swt-gtk-3.3.jar > > > > Why not in /usr/share/java/swt.jar? > > It's in %{_libdir} 'cause it's got arch-specific stuff in it. Care to > submit a patch for eclipse.spec to add the version-less symlink? I think that a version-less symlink should be in /usr/lib/eclipse, but additionally, the version-less symlink should also be in a directory allowing to do a yum install for the file and get it right, therefore in a directory like: /usr/lib/java /usr/lib/java-ext that are both owned by jpackage-utils. And empty in my setting. Would one of those directories be suitable? If no I propose to add another one, with name along /usr/lib/java-jar or /usr/lib/java-lib As a side note gcj depends on jpackage-utils but not ecj nor icedtea, maybe they should? Or is it up to the package that installs something in %{_libdir}/java* to depend on jpackage-utils? > > On fc7, there seems to be a need to do > > > > export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/lib/eclipse/ > > What VM is this with? With gcj sure and ecj, if I recall well. Should I test other VM? (Is icedtea on F7?) On F8 I tested gcj and icedtea, and both worked fine. -- Pat From nicolas.mailhot at laposte.net Tue Oct 9 09:12:42 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 9 Oct 2007 11:12:42 +0200 (CEST) Subject: [fedora-java] difficulties to use swt on fedora In-Reply-To: <20071009071918.GA2616@free.fr> References: <20071008210902.GB3088@free.fr> <20071008212742.GA5106@redhat.com> <20071009071918.GA2616@free.fr> Message-ID: <29915.192.54.193.51.1191921162.squirrel@rousalka.dyndns.org> Le Mar 9 octobre 2007 09:19, Patrice Dumas a ?crit : > On Mon, Oct 08, 2007 at 05:27:43PM -0400, Andrew Overholt wrote: >> Hi, >> >> * Patrice Dumas [2007-10-08 17:14]: >> > /usr/lib/eclipse/swt-gtk-3.3.jar >> > >> > Why not in /usr/share/java/swt.jar? >> >> It's in %{_libdir} 'cause it's got arch-specific stuff in it. Care >> to >> submit a patch for eclipse.spec to add the version-less symlink? > > I think that a version-less symlink should be in /usr/lib/eclipse, > but additionally, the version-less symlink should also be in a > directory allowing to do a yum install for the file and get it right, > therefore in a directory like: > /usr/lib/java > /usr/lib/java-ext > that are both owned by jpackage-utils. And empty in my setting. Would > one of those directories be suitable? If you read the jpackage-utils doc you'll see /usr/lib/java was always reserved for arch-dependant jars. Regards, -- Nicolas Mailhot Who wonders why he wasted a week-end writing doc no one reads anyway From pertusus at free.fr Tue Oct 9 09:27:57 2007 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 9 Oct 2007 11:27:57 +0200 Subject: [fedora-java] difficulties to use swt on fedora In-Reply-To: <29915.192.54.193.51.1191921162.squirrel@rousalka.dyndns.org> References: <20071008210902.GB3088@free.fr> <20071008212742.GA5106@redhat.com> <20071009071918.GA2616@free.fr> <29915.192.54.193.51.1191921162.squirrel@rousalka.dyndns.org> Message-ID: <20071009092757.GD2616@free.fr> On Tue, Oct 09, 2007 at 11:12:42AM +0200, Nicolas Mailhot wrote: > > If you read the jpackage-utils doc you'll see /usr/lib/java was always > reserved for arch-dependant jars. Perfect, I'll do a patch soon. -- Pat From pertusus at free.fr Wed Oct 10 22:12:11 2007 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 11 Oct 2007 00:12:11 +0200 Subject: [fedora-java] difficulties to use swt on fedora In-Reply-To: <20071008212742.GA5106@redhat.com> References: <20071008210902.GB3088@free.fr> <20071008212742.GA5106@redhat.com> Message-ID: <20071010221211.GA16347@free.fr> On Mon, Oct 08, 2007 at 05:27:43PM -0400, Andrew Overholt wrote: > Hi, > > * Patrice Dumas [2007-10-08 17:14]: > > /usr/lib/eclipse/swt-gtk-3.3.jar > > > > Why not in /usr/share/java/swt.jar? > > It's in %{_libdir} 'cause it's got arch-specific stuff in it. Care to > submit a patch for eclipse.spec to add the version-less symlink? I couldn't test completly because after hours of build, it stops with an error that seems to be unrelated: Binary file /var/tmp/eclipse-3.3.0-26.fc8-root-dumas/usr/lib/eclipse/configuration/org.eclipse.osgi/.bundledata.1 matches Binary file /var/tmp/eclipse-3.3.0-26.fc8-root-dumas/usr/lib/eclipse/configuration/org.eclipse.osgi/.lazy.1 matches Found '/var/tmp/eclipse-3.3.0-26.fc8-root-dumas' in installed files; aborting I attach what I came to. Any idea about which version of fedora and RHEL/EPEL will get this or similar patch? -- Pat -------------- next part -------------- ? .build-3.3.0-26.fc8.log ? eclipse-3.3.0 ? eclipse-3.3.0-26.fc8.src.rpm ? eclipse.spec-unversioned_ln.diff Index: eclipse.spec =================================================================== RCS file: /cvs/pkgs/rpms/eclipse/devel/eclipse.spec,v retrieving revision 1.493 diff -u -3 -p -r1.493 eclipse.spec --- eclipse.spec 6 Oct 2007 17:30:28 -0000 1.493 +++ eclipse.spec 10 Oct 2007 22:11:52 -0000 @@ -165,6 +165,8 @@ Requires: libgcj >= 4.0.2 Requires(post): java-gcj-compat >= 1.0.64 Requires(postun): java-gcj-compat >= 1.0.64 %endif +# %{_libdir}/java directory owned by jpackage-utils +Requires: jpackage-utils Requires: gtk2 Requires: firefox Conflicts: mozilla @@ -736,6 +738,7 @@ install -d -m 755 $RPM_BUILD_ROOT%{_data install -d -m 755 $RPM_BUILD_ROOT%{_libdir}/%{name} install -d -m 755 $RPM_BUILD_ROOT%{_libdir}/%{name}/plugins install -d -m 755 $RPM_BUILD_ROOT%{_libdir}/%{name}/features +install -d -m 755 $RPM_BUILD_ROOT%{_libdir}/java # Explode the resulting SDK tarball tar -C $RPM_BUILD_ROOT%{_datadir} -zxf result/linux-gtk-%{eclipse_arch}-sdk.tar.gz @@ -888,6 +891,8 @@ SWTJARVERSION=$(grep v$SWT_VERSION plugi pushd $RPM_BUILD_ROOT%{_libdir}/%{name} ln -s %{_libdir}/%{name}/plugins/org.eclipse.swt.gtk.linux.%{eclipse_arch}_$SWTJARVERSION.jar swt-gtk-%{eclipse_majmin}.%{eclipse_micro}.jar ln -s swt-gtk-%{eclipse_majmin}.%{eclipse_micro}.jar swt-gtk-%{eclipse_majmin}.jar +ln -s swt-gtk-%{eclipse_majmin}.%{eclipse_micro}.jar swt.jar +ln -s ../%{name}/swt-gtk-%{eclipse_majmin}.%{eclipse_micro}.jar ../java/swt.jar popd # Install the eclipse-ecj.jar symlink for java-1.4.2-gcj-compat's "javac" @@ -1248,6 +1253,8 @@ fi %{_datadir}/%{name}/plugins/org.eclipse.swt_* %{_libdir}/%{name}/plugins/org.eclipse.swt.gtk.linux.%{eclipse_arch}_* %{_libdir}/%{name}/swt-gtk*.jar +%{_libdir}/%{name}/swt.jar +%{_libdir}/java/swt.jar %if %{gcj_support} %dir %{_libdir}/gcj/%{name} %{_libdir}/gcj/%{name}/org.eclipse.swt.gtk.linux.%{eclipse_arch}_* From overholt at redhat.com Thu Oct 11 14:24:32 2007 From: overholt at redhat.com (Andrew Overholt) Date: Thu, 11 Oct 2007 10:24:32 -0400 Subject: [fedora-java] difficulties to use swt on fedora In-Reply-To: <20071010221211.GA16347@free.fr> References: <20071008210902.GB3088@free.fr> <20071008212742.GA5106@redhat.com> <20071010221211.GA16347@free.fr> Message-ID: <20071011142432.GA6164@redhat.com> Hi, * Patrice Dumas [2007-10-10 18:12]: > > I couldn't test completly because after hours of build, it stops with an > error that seems to be unrelated: > Binary file /var/tmp/eclipse-3.3.0-26.fc8-root-dumas/usr/lib/eclipse/configuration/org.eclipse.osgi/.bundledata.1 matches > Binary file /var/tmp/eclipse-3.3.0-26.fc8-root-dumas/usr/lib/eclipse/configuration/org.eclipse.osgi/.lazy.1 matches > Found '/var/tmp/eclipse-3.3.0-26.fc8-root-dumas' in installed files; aborting Weird. > I attach what I came to. Any idea about which version of fedora and > RHEL/EPEL will get this or similar patch? Thanks for the patch - it looks good. We can squeeze it into Fedora 8 if it's important to you and/or others. I'll do a build for F8 with it now. Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pertusus at free.fr Thu Oct 11 14:40:43 2007 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 11 Oct 2007 16:40:43 +0200 Subject: [fedora-java] difficulties to use swt on fedora In-Reply-To: <20071011142432.GA6164@redhat.com> References: <20071008210902.GB3088@free.fr> <20071008212742.GA5106@redhat.com> <20071010221211.GA16347@free.fr> <20071011142432.GA6164@redhat.com> Message-ID: <20071011144043.GD3659@free.fr> On Thu, Oct 11, 2007 at 10:24:32AM -0400, Andrew Overholt wrote: > > > I attach what I came to. Any idea about which version of fedora and > > RHEL/EPEL will get this or similar patch? > > Thanks for the patch - it looks good. We can squeeze it into Fedora 8 > if it's important to you and/or others. I'll do a build for F8 with it > now. I want to submit a package that relies on it and I'd like to avoid something complicated with hardcoded versions. It won't be in fedora, but in rpmfusion, though, since it depends on mencode which is not in fedora. So the fedora version that have it determines the first fedora version for my package, so F8 (and RHEL6) seems right. -- Pat From green at redhat.com Thu Oct 11 14:45:45 2007 From: green at redhat.com (Anthony Green) Date: Thu, 11 Oct 2007 07:45:45 -0700 Subject: [fedora-java] java packaging problem: unowned directories Message-ID: <470E3719.2010600@redhat.com> A number of java packages have unowned directories. Some of them were recently called out on fedora-devel-list. Here's what I show on my FC-6 system. I recommend that package owners have a quick look at these... $ ls /usr/lib/gcj | xargs -n1 rpm -qf | grep "not owned by any" file /usr/lib/gcj/avalon-framework is not owned by any package file /usr/lib/gcj/bcel is not owned by any package file /usr/lib/gcj/classpathx-jaf is not owned by any package file /usr/lib/gcj/classpathx-mail is not owned by any package file /usr/lib/gcj/eclipse-changelog is not owned by any package file /usr/lib/gcj/eclipse-emf is not owned by any package file /usr/lib/gcj/eclipse-gef is not owned by any package file /usr/lib/gcj/jakarta-commons-beanutils is not owned by any package file /usr/lib/gcj/jakarta-commons-codec is not owned by any package file /usr/lib/gcj/jakarta-commons-collections is not owned by any package file /usr/lib/gcj/jakarta-commons-digester is not owned by any package file /usr/lib/gcj/jakarta-commons-discovery is not owned by any package file /usr/lib/gcj/jakarta-commons-lang is not owned by any package file /usr/lib/gcj/jakarta-commons-launcher is not owned by any package file /usr/lib/gcj/jakarta-commons-modeler is not owned by any package file /usr/lib/gcj/jakarta-taglibs-standard is not owned by any package file /usr/lib/gcj/jdepend is not owned by any package file /usr/lib/gcj/jzlib is not owned by any package file /usr/lib/gcj/ldapjdk is not owned by any package file /usr/lib/gcj/log4j is not owned by any package file /usr/lib/gcj/mockobjects is not owned by any package file /usr/lib/gcj/mx4j is not owned by any package file /usr/lib/gcj/tomcat5 is not owned by any package file /usr/lib/gcj/velocity is not owned by any package file /usr/lib/gcj/werken-xpath is not owned by any package file /usr/lib/gcj/xdoclet is not owned by any package file /usr/lib/gcj/xerces-j2 is not owned by any package AG -------------- next part -------------- A non-text attachment was scrubbed... Name: green.vcf Type: text/x-vcard Size: 163 bytes Desc: not available URL: From caolanm at redhat.com Thu Oct 11 19:54:10 2007 From: caolanm at redhat.com (Caolan McNamara) Date: Thu, 11 Oct 2007 20:54:10 +0100 Subject: [fedora-java] java arch dir names for mips Message-ID: <1192132450.7004.36.camel@Jehannum> So in OOo we have.. #if defined SPARC #define JFW_PLUGIN_ARCH "sparc" #elif defined INTEL #define JFW_PLUGIN_ARCH "i386" #elif defined POWERPC64 #define JFW_PLUGIN_ARCH "ppc64" #elif defined POWERPC #define JFW_PLUGIN_ARCH "ppc" #elif defined X86_64 #define JFW_PLUGIN_ARCH "amd64" #endif // SPARC, INTEL, POWERPC But does anyone know what the arch names should be for the various mips of mipsel mipseb mips64el and mips64eb, I seem to see "mipsel" used by gcj for mipsel, but mips32 is being used by e.g. http://www.lemote.com/debian/pool/contrib/sun-java_1.5-lemote-b1_mipsel.deb I don't suppose there is an actual standard here, even a de-facto one ? C. From david at zarb.org Mon Oct 15 11:05:37 2007 From: david at zarb.org (David Walluck) Date: Mon, 15 Oct 2007 07:05:37 -0400 Subject: [fedora-java] difficulties to use swt on fedora In-Reply-To: <20071011142432.GA6164@redhat.com> References: <20071008210902.GB3088@free.fr> <20071008212742.GA5106@redhat.com> <20071010221211.GA16347@free.fr> <20071011142432.GA6164@redhat.com> Message-ID: <47134981.1020208@zarb.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andrew Overholt wrote: > Hi, > > * Patrice Dumas [2007-10-10 18:12]: >> >> I couldn't test completly because after hours of build, it stops with an >> error that seems to be unrelated: >> Binary file /var/tmp/eclipse-3.3.0-26.fc8-root-dumas/usr/lib/eclipse/configuration/org.eclipse.osgi/.bundledata.1 matches >> Binary file /var/tmp/eclipse-3.3.0-26.fc8-root-dumas/usr/lib/eclipse/configuration/org.eclipse.osgi/.lazy.1 matches >> Found '/var/tmp/eclipse-3.3.0-26.fc8-root-dumas' in installed files; aborting > > Weird. > >> I attach what I came to. Any idea about which version of fedora and >> RHEL/EPEL will get this or similar patch? > > Thanks for the patch - it looks good. We can squeeze it into Fedora 8 > if it's important to you and/or others. I'll do a build for F8 with it > now. I think you mean to use %{_jndirdir} and not %{_libdir}/java in this patch. Also, I think you should provide versioned swt and swt-gtk symlinks. - -- Sincerely, David Walluck -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.5 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFHE0mAN5thZBYlTwkRAiG5AKCCzQGJEiDYaG2U3DP6McOEssmkoACfYWSX P5o01umUTwIc/8nT1nJbV04= =eVX5 -----END PGP SIGNATURE----- From pertusus at free.fr Mon Oct 15 11:21:16 2007 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 15 Oct 2007 13:21:16 +0200 Subject: [fedora-java] difficulties to use swt on fedora In-Reply-To: <20071011142432.GA6164@redhat.com> References: <20071008210902.GB3088@free.fr> <20071008212742.GA5106@redhat.com> <20071010221211.GA16347@free.fr> <20071011142432.GA6164@redhat.com> Message-ID: <20071015112115.GA2648@free.fr> On Thu, Oct 11, 2007 at 10:24:32AM -0400, Andrew Overholt wrote: > Hi, > > Thanks for the patch - it looks good. We can squeeze it into Fedora 8 > if it's important to you and/or others. I'll do a build for F8 with it > now. You removed the part: # %{_libdir}/java directory owned by jpackage-utils Requires: jpackage-utils It is not a problem, but then %{_libdir}/java should be owned by the package otherwise it may end up being unowned. -- Pat From pertusus at free.fr Mon Oct 15 11:23:34 2007 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 15 Oct 2007 13:23:34 +0200 Subject: [fedora-java] difficulties to use swt on fedora In-Reply-To: <47134981.1020208@zarb.org> References: <20071008210902.GB3088@free.fr> <20071008212742.GA5106@redhat.com> <20071010221211.GA16347@free.fr> <20071011142432.GA6164@redhat.com> <47134981.1020208@zarb.org> Message-ID: <20071015112334.GB2648@free.fr> On Mon, Oct 15, 2007 at 07:05:37AM -0400, David Walluck wrote: > > I think you mean to use %{_jndirdir} and not %{_libdir}/java in this This macro doesn't seems to be defined: rpm --eval %{_jndirdir} %{_jndirdir} > patch. Also, I think you should provide versioned swt and swt-gtk symlinks. What would be the use of such symlinks? Shouldn't everything that use swt add %{_libdir}/java/swt.jar to the classpath? -- Pat From david at zarb.org Mon Oct 15 11:29:23 2007 From: david at zarb.org (David Walluck) Date: Mon, 15 Oct 2007 07:29:23 -0400 Subject: [fedora-java] difficulties to use swt on fedora In-Reply-To: <20071015112334.GB2648@free.fr> References: <20071008210902.GB3088@free.fr> <20071008212742.GA5106@redhat.com> <20071010221211.GA16347@free.fr> <20071011142432.GA6164@redhat.com> <47134981.1020208@zarb.org> <20071015112334.GB2648@free.fr> Message-ID: <47134F13.1020100@zarb.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Patrice Dumas wrote: > On Mon, Oct 15, 2007 at 07:05:37AM -0400, David Walluck wrote: >> >> I think you mean to use %{_jndirdir} and not %{_libdir}/java in this > > This macro doesn't seems to be defined: > > rpm --eval %{_jndirdir} > %{_jndirdir} I meant %{_jnidir}. This should be used instead of %{_libdir}/java. Also, jpackage-utils should be required by the eclipse package regardless. > What would be the use of such symlinks? Shouldn't everything that use > swt add %{_libdir}/java/swt.jar to the classpath? Because some of the files/links are versioned and some aren't. So the convention is to version everything. Generally, yes, one would do $(build-classpath swt), but that doesn't affect the other standard of naming conventions. - -- Sincerely, David Walluck -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.5 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFHE08TN5thZBYlTwkRAm72AJ9FqoAPjkV3bhnnMKHavVYBSGxj1gCfVMun UgEEkcekkZ4G37rgP+tT8qQ= =Epyf -----END PGP SIGNATURE----- From overholt at redhat.com Mon Oct 15 12:11:40 2007 From: overholt at redhat.com (Andrew Overholt) Date: Mon, 15 Oct 2007 08:11:40 -0400 Subject: [fedora-java] difficulties to use swt on fedora In-Reply-To: <47134F13.1020100@zarb.org> References: <20071008210902.GB3088@free.fr> <20071008212742.GA5106@redhat.com> <20071010221211.GA16347@free.fr> <20071011142432.GA6164@redhat.com> <47134981.1020208@zarb.org> <20071015112334.GB2648@free.fr> <47134F13.1020100@zarb.org> Message-ID: <20071015121140.GA3143@redhat.com> * David Walluck [2007-10-15 07:29]: > Also, jpackage-utils should be required by the eclipse package regardless. Why? Some of its dependencies Require it so it'll be brought in. Is there an advantage to requiring it explicitly? Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pertusus at free.fr Mon Oct 15 13:02:02 2007 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 15 Oct 2007 15:02:02 +0200 Subject: [fedora-java] difficulties to use swt on fedora In-Reply-To: <20071015121140.GA3143@redhat.com> References: <20071008210902.GB3088@free.fr> <20071008212742.GA5106@redhat.com> <20071010221211.GA16347@free.fr> <20071011142432.GA6164@redhat.com> <47134981.1020208@zarb.org> <20071015112334.GB2648@free.fr> <47134F13.1020100@zarb.org> <20071015121140.GA3143@redhat.com> Message-ID: <20071015130202.GA2663@free.fr> On Mon, Oct 15, 2007 at 08:11:40AM -0400, Andrew Overholt wrote: > * David Walluck [2007-10-15 07:29]: > > Also, jpackage-utils should be required by the eclipse package regardless. > > Why? Some of its dependencies Require it so it'll be brought in. Is > there an advantage to requiring it explicitly? The dependency chain is not obvious to me, it seems to be through java-1.5.0-gcj. If I am not wrong, it seems to me that a direct Requires would be better. -- Pat From green at redhat.com Mon Oct 15 14:11:27 2007 From: green at redhat.com (Anthony Green) Date: Mon, 15 Oct 2007 07:11:27 -0700 Subject: [fedora-java] Problems building kawa on rawhide with ecj-on-gcj Message-ID: <4713750F.2070109@redhat.com> I can't build kawa on rawhide (gcj 4.1.2) due to errors like the following.... [javac] 1. ERROR in /home/BUILD/kawa-1.9.1/gnu/lists/PrintConsumer.java (at line 9) [javac] public class PrintConsumer extends PrintWriter [javac] ^^^^^^^^^^^^^ [javac] Exception IOException in throws clause of Writer.append(CharSequence, int, int) is not compatible with PrintWriter.append(CharSequence, int, int) And, indeed, our PrintWriter.append methods don't throw IOException. Is this a bug? AG -------------- next part -------------- A non-text attachment was scrubbed... Name: green.vcf Type: text/x-vcard Size: 163 bytes Desc: not available URL: From aph at redhat.com Mon Oct 15 14:20:32 2007 From: aph at redhat.com (Andrew Haley) Date: Mon, 15 Oct 2007 15:20:32 +0100 Subject: [fedora-java] Problems building kawa on rawhide with ecj-on-gcj In-Reply-To: <4713750F.2070109@redhat.com> References: <4713750F.2070109@redhat.com> Message-ID: <18195.30512.780786.678315@zebedee.pink> Anthony Green writes: > I can't build kawa on rawhide (gcj 4.1.2) due to errors like the > following.... > > [javac] 1. ERROR in > /home/BUILD/kawa-1.9.1/gnu/lists/PrintConsumer.java (at line 9) > [javac] public class PrintConsumer extends PrintWriter > [javac] ^^^^^^^^^^^^^ > [javac] Exception IOException in throws clause of > Writer.append(CharSequence, int, int) is not compatible with > PrintWriter.append(CharSequence, int, int) > > And, indeed, our PrintWriter.append methods don't throw IOException. The PrintWriter.append methods in OpenJDK don't either. PrintWriter.append(c) calls out.write(c), which catches IOException and doesn't re-throw it. > Is this a bug? IMO no. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From green at redhat.com Mon Oct 15 14:28:22 2007 From: green at redhat.com (Anthony Green) Date: Mon, 15 Oct 2007 07:28:22 -0700 Subject: [fedora-java] Problems building kawa on rawhide with ecj-on-gcj In-Reply-To: <18195.30512.780786.678315@zebedee.pink> References: <4713750F.2070109@redhat.com> <18195.30512.780786.678315@zebedee.pink> Message-ID: <47137906.2040205@redhat.com> Andrew Haley wrote: > The PrintWriter.append methods in OpenJDK don't either. > PrintWriter.append(c) calls out.write(c), which catches IOException > and doesn't re-throw it. > > > Is this a bug? > > IMO no. So it's a compiler bug? Something must be wrong somewhere... AG -------------- next part -------------- A non-text attachment was scrubbed... Name: green.vcf Type: text/x-vcard Size: 163 bytes Desc: not available URL: From aph at redhat.com Mon Oct 15 14:30:40 2007 From: aph at redhat.com (Andrew Haley) Date: Mon, 15 Oct 2007 15:30:40 +0100 Subject: [fedora-java] Problems building kawa on rawhide with ecj-on-gcj In-Reply-To: <47137906.2040205@redhat.com> References: <4713750F.2070109@redhat.com> <18195.30512.780786.678315@zebedee.pink> <47137906.2040205@redhat.com> Message-ID: <18195.31120.647915.278124@zebedee.pink> Anthony Green writes: > Andrew Haley wrote: > > The PrintWriter.append methods in OpenJDK don't either. > > PrintWriter.append(c) calls out.write(c), which catches IOException > > and doesn't re-throw it. > > > > > Is this a bug? > > > > IMO no. > > So it's a compiler bug? Something must be wrong somewhere... It's a bug in kawa. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From aph at redhat.com Mon Oct 15 14:44:30 2007 From: aph at redhat.com (Andrew Haley) Date: Mon, 15 Oct 2007 15:44:30 +0100 Subject: [fedora-java] Problems building kawa on rawhide with ecj-on-gcj In-Reply-To: <18195.31120.647915.278124@zebedee.pink> References: <4713750F.2070109@redhat.com> <18195.30512.780786.678315@zebedee.pink> <47137906.2040205@redhat.com> <18195.31120.647915.278124@zebedee.pink> Message-ID: <18195.31950.140991.160304@zebedee.pink> Andrew Haley writes: > Anthony Green writes: > > Andrew Haley wrote: > > > The PrintWriter.append methods in OpenJDK don't either. > > > PrintWriter.append(c) calls out.write(c), which catches IOException > > > and doesn't re-throw it. > > > > > > > Is this a bug? > > > > > > IMO no. > > > > So it's a compiler bug? Something must be wrong somewhere... > > It's a bug in kawa. Sorry, misspoke. Perhaps a bug in ecj. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From overholt at redhat.com Mon Oct 15 14:55:46 2007 From: overholt at redhat.com (Andrew Overholt) Date: Mon, 15 Oct 2007 10:55:46 -0400 Subject: [fedora-java] difficulties to use swt on fedora In-Reply-To: <20071015130202.GA2663@free.fr> References: <20071008210902.GB3088@free.fr> <20071008212742.GA5106@redhat.com> <20071010221211.GA16347@free.fr> <20071011142432.GA6164@redhat.com> <47134981.1020208@zarb.org> <20071015112334.GB2648@free.fr> <47134F13.1020100@zarb.org> <20071015121140.GA3143@redhat.com> <20071015130202.GA2663@free.fr> Message-ID: <20071015145546.GA349@redhat.com> * Patrice Dumas [2007-10-15 09:03]: > On Mon, Oct 15, 2007 at 08:11:40AM -0400, Andrew Overholt wrote: > > * David Walluck [2007-10-15 07:29]: > > > Also, jpackage-utils should be required by the eclipse package regardless. > > > > Why? Some of its dependencies Require it so it'll be brought in. Is > > there an advantage to requiring it explicitly? > > The dependency chain is not obvious to me, it seems to be through > java-1.5.0-gcj. If I am not wrong, it seems to me that a direct Requires > would be better. I really don't care, so if people want to see that explicit Requires, feel free to add it to the package in CVS or send me a patch. Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From joe at galway.net Mon Oct 15 15:02:05 2007 From: joe at galway.net (Joe Desbonnet) Date: Mon, 15 Oct 2007 16:02:05 +0100 Subject: [fedora-java] javax.io / gnu.io (RS232 IO) Message-ID: <1cef3e950710150802g2f2d9a1bt6fcb181cd9171100@mail.gmail.com> Just wondering if javax.io / gnu.io packages (for IO eg RS232, parallel port etc) are going to be part of the Fedora Java suite? The project home is at http://www.rxtx.org/ Joe. From fitzsim at redhat.com Mon Oct 15 15:55:02 2007 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Mon, 15 Oct 2007 11:55:02 -0400 Subject: [fedora-java] javax.io / gnu.io (RS232 IO) In-Reply-To: <1cef3e950710150802g2f2d9a1bt6fcb181cd9171100@mail.gmail.com> References: <1cef3e950710150802g2f2d9a1bt6fcb181cd9171100@mail.gmail.com> Message-ID: <47138D56.2090407@redhat.com> Joe Desbonnet wrote: > Just wondering if javax.io / gnu.io packages (for IO eg RS232, > parallel port etc) are going to be part of the Fedora Java suite? The > project home is at http://www.rxtx.org/ I'm not aware of any plans to include it. It would be nice to have though. The dependency on the non-free Java Communications jar may be a problem. Also, packaging JRE extensions in a cross-vendor way is not well-supported yet. That said, I wouldn't discourage someone trying -- a motivated volunteer could create a Fedora feature request. Tom From mefoster at gmail.com Tue Oct 16 10:32:42 2007 From: mefoster at gmail.com (Mary Ellen Foster) Date: Tue, 16 Oct 2007 12:32:42 +0200 Subject: [fedora-java] About "Docs/Beats/Java" and jpackage Message-ID: I was just looking at http://fedoraproject.org/wiki/Docs/Beats/Java and saw that it mentions installing packages from JPackage directly. Note that it's not actually possible, in my experience, to install packages from JPackage on Fedora 7 because of the following: - Fedora has an RPM-older version of jpackage-utils than JPackage - Fedora's jpackage-utils provides rebuild-security-providers, while JPackage's doesn't - All of the JPackage packages depend on their version of jpackage-utils - Many of the Fedora packages depend on rebuild-security-providers All of this means that JPackage packages can't really be used on Fedora. There are also issues to do with Lucene and Geronimo, but they're probably less fundamental. I described all of this in a post to the JPackage list in June when I first tried using JPackage on Fedora: https://www.zarb.org/pipermail/jpackage-discuss/2007-June/011536.html Also, the highest version of Fedora that JPackage seems to officially support is FC6 (see http://www.jpackage.org/yum.php). So I'm not sure it's helpful even to point people at JPackage for Fedora 8, because I'm not sure there's much useful they can do with it. MEF -- Mary Ellen Foster http://homepages.inf.ed.ac.uk/mef/ From mark at klomp.org Tue Oct 16 21:37:21 2007 From: mark at klomp.org (Mark Wielaard) Date: Tue, 16 Oct 2007 23:37:21 +0200 Subject: [fedora-java] Problems building kawa on rawhide with ecj-on-gcj In-Reply-To: <47137906.2040205@redhat.com> References: <4713750F.2070109@redhat.com> <18195.30512.780786.678315@zebedee.pink> <47137906.2040205@redhat.com> Message-ID: <1192570641.3223.35.camel@localhost.localdomain> Hi Anthony, On Mon, 2007-10-15 at 07:28 -0700, Anthony Green wrote: > Andrew Haley wrote: > > The PrintWriter.append methods in OpenJDK don't either. > > PrintWriter.append(c) calls out.write(c), which catches IOException > > and doesn't re-throw it. > > > > > Is this a bug? > > > > IMO no. > > So it's a compiler bug? Something must be wrong somewhere... I suspect this is a 1.4/1.5 issue. PrintWriter extends Writer which implements Appendable in 1.5 which is has return type Appendable (which means Writer in Writer itself). Which means that it has a covariant return type. In the case of PrintWriter there are actually 3 methods, one that returns type PrintWriter and two "invisible" bridge methods with return types Appendable and Writer. If you look with jcf-dump you will notice that the bridge method does throw the IOException, while the variant that returns an Appendable doesn't. The compiler, in 1.4 compatibility mode, doesn't know about covariant return types and checks your code against the wrong variant. Bottom line, your source code is not compatible with the 1.5 core classes (the change is binary compatible though, so if you don't recompile things should work - which I expect isn't an option for a Fedora package). You might have to compile with an explicit -1.5 to get the compiler to handle the bridge methods correctly and pretend your code is 1.5 source code (hoping that doesn't trigger some other source incompatibility). Cheers, Mark From green at redhat.com Tue Oct 16 21:42:13 2007 From: green at redhat.com (Anthony Green) Date: Tue, 16 Oct 2007 14:42:13 -0700 Subject: [fedora-java] Problems building kawa on rawhide with ecj-on-gcj In-Reply-To: <1192570641.3223.35.camel@localhost.localdomain> References: <4713750F.2070109@redhat.com> <18195.30512.780786.678315@zebedee.pink> <47137906.2040205@redhat.com> <1192570641.3223.35.camel@localhost.localdomain> Message-ID: <47153035.9000304@redhat.com> Mark Wielaard wrote: > Bottom line, your source code is not compatible with the 1.5 core > classes (the change is binary compatible though, so if you don't > recompile things should work - which I expect isn't an option for a > Fedora package). You might have to compile with an explicit -1.5 to get > the compiler to handle the bridge methods correctly and pretend your > code is 1.5 source code (hoping that doesn't trigger some other source > incompatibility). I just compiled it all with "gcj -C" and all appears to be good. Thanks, AG -------------- next part -------------- A non-text attachment was scrubbed... Name: green.vcf Type: text/x-vcard Size: 163 bytes Desc: not available URL: From mark at klomp.org Tue Oct 16 21:58:13 2007 From: mark at klomp.org (Mark Wielaard) Date: Tue, 16 Oct 2007 23:58:13 +0200 Subject: [fedora-java] Problems building kawa on rawhide with ecj-on-gcj In-Reply-To: <47153035.9000304@redhat.com> References: <4713750F.2070109@redhat.com> <18195.30512.780786.678315@zebedee.pink> <47137906.2040205@redhat.com> <1192570641.3223.35.camel@localhost.localdomain> <47153035.9000304@redhat.com> Message-ID: <1192571893.3223.48.camel@localhost.localdomain> On Tue, 2007-10-16 at 14:42 -0700, Anthony Green wrote: > Mark Wielaard wrote: > > Bottom line, your source code is not compatible with the 1.5 core > > classes (the change is binary compatible though, so if you don't > > recompile things should work - which I expect isn't an option for a > > Fedora package). You might have to compile with an explicit -1.5 to get > > the compiler to handle the bridge methods correctly and pretend your > > code is 1.5 source code (hoping that doesn't trigger some other source > > incompatibility). > > I just compiled it all with "gcj -C" and all appears to be good. O, that is good. In that case my analysis is either wrong or ecj has a bug. The interaction between 1.5 covariant return types and 1.4 source code is a little tricky. Maybe if you have time and have icedtea installed then maybe you could also try compiling with the included javac in that package. Then we might know which compiler is right. Cheers, Mark From green at redhat.com Wed Oct 17 01:33:50 2007 From: green at redhat.com (Anthony Green) Date: Tue, 16 Oct 2007 18:33:50 -0700 Subject: [fedora-java] Problems building kawa on rawhide with ecj-on-gcj In-Reply-To: <1192571893.3223.48.camel@localhost.localdomain> References: <4713750F.2070109@redhat.com> <18195.30512.780786.678315@zebedee.pink> <47137906.2040205@redhat.com> <1192570641.3223.35.camel@localhost.localdomain> <47153035.9000304@redhat.com> <1192571893.3223.48.camel@localhost.localdomain> Message-ID: <4715667E.3010302@redhat.com> Mark Wielaard wrote: > Maybe if you have time and have icedtea > installed then maybe you could also try compiling with the included > javac in that package. Then we might know which compiler is right. I forgot to mention that I had tried that and the IcedTea javac compiles it as well. AG -------------- next part -------------- A non-text attachment was scrubbed... Name: green.vcf Type: text/x-vcard Size: 163 bytes Desc: not available URL: From choeger at cs.tu-berlin.de Wed Oct 17 10:15:19 2007 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Wed, 17 Oct 2007 12:15:19 +0200 Subject: [fedora-java] packaging eclipse plugin Message-ID: <1192616119.7882.11.camel@s5.math.tu-berlin.de> hey there, ive got a question about packaging my eclipse plugin (Opalipse, an IDE for Opal) (cs.tu-berlin.de/~choeger): what is the default fedora way to install eclipse features/plugins? What do i have to put where? Are there .spec templates (apart the default one which comes with rpmdevtools)? Any hints? regards christoph From overholt at redhat.com Wed Oct 17 17:54:09 2007 From: overholt at redhat.com (Andrew Overholt) Date: Wed, 17 Oct 2007 13:54:09 -0400 Subject: [fedora-java] packaging eclipse plugin In-Reply-To: <1192616119.7882.11.camel@s5.math.tu-berlin.de> References: <1192616119.7882.11.camel@s5.math.tu-berlin.de> Message-ID: <20071017175409.GA24146@redhat.com> Hi, * Christoph H?ger [2007-10-17 06:16]: > > what is the default fedora way to install eclipse features/plugins? > What do i have to put where? Are there .spec templates (apart the > default one which comes with rpmdevtools)? Any hints? You put features in /usr/share/eclipse/features and plugins in /usr/share/eclipse/plugins. The only exceptions are arch-specific stuff that goes in %{_libdir}/eclipse/{features,plugins}. Most eclipse-* packages follow these "rules" pretty well. Take a look at the ones in CVS now to get a sense for how to do things. Find us on #fedora-java or #eclipse-linux on freenode if no one responds to your mail fast enough :) Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mefoster at gmail.com Fri Oct 19 10:20:33 2007 From: mefoster at gmail.com (Mary Ellen Foster) Date: Fri, 19 Oct 2007 12:20:33 +0200 Subject: [fedora-java] Re: About "Docs/Beats/Java" and jpackage In-Reply-To: References: Message-ID: On 16/10/2007, Mary Ellen Foster wrote: > Also, the highest version of Fedora that JPackage seems to officially > support is FC6 (see http://www.jpackage.org/yum.php). So I'm not sure > it's helpful even to point people at JPackage for Fedora 8, because > I'm not sure there's much useful they can do with it. p.s. -- See also this bug report -- at least one other person is also having problems with jpackage/Fedora integration. https://bugzilla.redhat.com/show_bug.cgi?id=260161 If neither project is interested in providing interoperable repositories, that's fine (if sad), but then the documentation should probably not even point at JPackage as a source of packages for a user. MEF -- Mary Ellen Foster http://homepages.inf.ed.ac.uk/mef/ From fitzsim at redhat.com Fri Oct 19 22:28:27 2007 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Fri, 19 Oct 2007 18:28:27 -0400 Subject: [fedora-java] Re: About "Docs/Beats/Java" and jpackage In-Reply-To: References: Message-ID: <47192F8B.5020908@redhat.com> Mary Ellen Foster wrote: > On 16/10/2007, Mary Ellen Foster wrote: >> Also, the highest version of Fedora that JPackage seems to officially >> support is FC6 (see http://www.jpackage.org/yum.php). So I'm not sure >> it's helpful even to point people at JPackage for Fedora 8, because >> I'm not sure there's much useful they can do with it. > > p.s. -- See also this bug report -- at least one other person is also > having problems with jpackage/Fedora integration. > https://bugzilla.redhat.com/show_bug.cgi?id=260161 It's too late to resolve this for Fedora 8, but I can provide post-Fedora 8 updates. The potential resolutions are: 1) get JPackage to accept rebuild-security-providers upstream 2) implement security.d searching in the JREs 3) inline rebuild-security-providers in post scripts I proposed rebuild-security-providers for upstream inclusion but received no response: https://zarb.org/pipermail/jpackage-discuss/2006-February/009592.html Longer term, my plan is to support security.d in IcedTea/OpenJDK. External security providers would drop config files in /etc/java/security/security.d and JREs that support security.d would automatically load them, in addition to the providers listed in java.security. In the short term -- that is, soon after Fedora 8 is released -- I'll inline rebuild-security-providers in relevant post scripts, and release a new jpackage-utils that doesn't contain the script. While solution 3) will silence rpm's complaints, it won't solve the fact that vanilla jpackage-utils doesn't own /etc/java/security/security.d/. So JPackage users will have to pay attention that applications that run on GCJ and employ external security providers are not adversely affected. Tom From david at zarb.org Sat Oct 20 06:57:53 2007 From: david at zarb.org (David Walluck) Date: Sat, 20 Oct 2007 02:57:53 -0400 Subject: [fedora-java] Re: About "Docs/Beats/Java" and jpackage In-Reply-To: <47192F8B.5020908@redhat.com> References: <47192F8B.5020908@redhat.com> Message-ID: <4719A6F1.1020608@zarb.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thomas Fitzsimmons wrote: > While solution 3) will silence rpm's complaints, it won't solve the fact that > vanilla jpackage-utils doesn't own /etc/java/security/security.d/. So JPackage > users will have to pay attention that applications that run on GCJ and employ > external security providers are not adversely affected. There is too much in your email for me to process right now, but Mandriva's jpackage-utils has co-existed peacefully with JPackage since its inception. One just has to make sure that its release is newer than the upstream one. - -- Sincerely, David Walluck -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFHGabxN5thZBYlTwkRAk1CAKCFTQI5qrNaTPBjPkvcShbSr8GdkgCfQvPP zFHUeSYQZuscVXJRi8ECCaA= =OtZb -----END PGP SIGNATURE----- From jafa82 at gmail.com Sat Oct 27 21:00:43 2007 From: jafa82 at gmail.com (Eric Damien) Date: Sat, 27 Oct 2007 17:00:43 -0400 Subject: [fedora-java] Fedora: setup Tomcat+Eclipse+GCJ environment Message-ID: <4723A6FB.1070909@gmail.com> Greetings. I've been using fedora (6,7) for quite a time now, for c++ and regular java (gcj) programming. Now, I want to develop web application, using eclipse and tomcat. I installed Fedora eclipse and the tomcat packages. I downloaded the sysdeo plugin and that's where things started to go wrong: starting tomcat service on its own, I can acces the "http://localhost:8080" page. I setup sysdeo plugin but when I press the "srat tomcat" button, this is what I receive in the console of eclipse: 27-Oct-07 4:59:18 PM org.apache.tomcat.util.digester.Digester startElement SEVERE: Begin event threw error java.lang.NoClassDefFoundError: org.apache.catalina.mbeans.ServerLifecycleListener at java.lang.Class.initializeClass(libgcj.so.8rh) at java.lang.Class.newInstance(libgcj.so.8rh) at org.apache.tomcat.util.digester.ObjectCreateRule.begin(tomcat-util-5.5.23.jar.so) at org.apache.tomcat.util.digester.Rule.begin(tomcat-util-5.5.23.jar.so) at org.apache.tomcat.util.digester.Digester.startElement(tomcat-util-5.5.23.jar.so) at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source) at org.apache.xerces.parsers.AbstractXMLDocumentParser.emptyElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanStartElement(xerces-j2-2.7.1.jar.so) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(xerces-j2-2.7.1.jar.so) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(xerces-j2-2.7.1.jar.so) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source) at org.apache.tomcat.util.digester.Digester.parse(tomcat-util-5.5.23.jar.so) at org.apache.catalina.startup.Catalina.load(catalina-5.5.23.jar.so) at org.apache.catalina.startup.Catalina.load(catalina-5.5.23.jar.so) at java.lang.reflect.Method.invoke(libgcj.so.8rh) at org.apache.catalina.startup.Bootstrap.load(bootstrap.jar.so) at org.apache.catalina.startup.Bootstrap.main(bootstrap.jar.so) Caused by: java.lang.NullPointerException at java.lang.Class.initializeClass(libgcj.so.8rh) ...20 more java.lang.reflect.InvocationTargetException at java.lang.reflect.Method.invoke(libgcj.so.8rh) at org.apache.catalina.startup.Bootstrap.load(bootstrap.jar.so) at org.apache.catalina.startup.Bootstrap.main(bootstrap.jar.so) Caused by: java.lang.NoClassDefFoundError: org.apache.catalina.mbeans.ServerLifecycleListener at java.lang.Class.initializeClass(libgcj.so.8rh) at java.lang.Class.newInstance(libgcj.so.8rh) at org.apache.tomcat.util.digester.ObjectCreateRule.begin(tomcat-util-5.5.23.jar.so) at org.apache.tomcat.util.digester.Rule.begin(tomcat-util-5.5.23.jar.so) at org.apache.tomcat.util.digester.Digester.startElement(tomcat-util-5.5.23.jar.so) at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source) at org.apache.xerces.parsers.AbstractXMLDocumentParser.emptyElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanStartElement(xerces-j2-2.7.1.jar.so) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(xerces-j2-2.7.1.jar.so) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(xerces-j2-2.7.1.jar.so) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source) at org.apache.tomcat.util.digester.Digester.parse(tomcat-util-5.5.23.jar.so) at org.apache.catalina.startup.Catalina.load(catalina-5.5.23.jar.so) at org.apache.catalina.startup.Catalina.load(catalina-5.5.23.jar.so) at java.lang.reflect.Method.invoke(libgcj.so.8rh) ...2 more Caused by: java.lang.NullPointerException at java.lang.Class.initializeClass(libgcj.so.8rh) ...20 more Can somebody help with this? Thanks in advance. From green at redhat.com Wed Oct 31 14:06:34 2007 From: green at redhat.com (Anthony Green) Date: Wed, 31 Oct 2007 07:06:34 -0700 Subject: [fedora-java] Retiring jogl Message-ID: <47288BEA.5060705@redhat.com> I am forced to retire the jogl package because parts of it are licensed under the SGI Free Software License B, which is not actually a Free Software license as per the FSF, and is explicitly not allowed in Fedora. The code in question is java code derived from SGI's OpenGL reference implementation (presumably in C). I've alerted the upstream jogl maintainers in this thread: http://www.javagaming.org/forums/index.php?topic=10718.msg138381#msg138381 AG -------------- next part -------------- A non-text attachment was scrubbed... Name: green.vcf Type: text/x-vcard Size: 163 bytes Desc: not available URL: From choeger at cs.tu-berlin.de Wed Oct 31 18:57:38 2007 From: choeger at cs.tu-berlin.de (=?ISO-8859-15?Q?Christoph_H=F6ger?=) Date: Wed, 31 Oct 2007 19:57:38 +0100 Subject: [fedora-java] axis2 Message-ID: <4728D022.4090306@cs.tu-berlin.de> Hey there, am I right when I say that there is currnently no fedora package for axis2 ? regards christoph