From foster at in.tum.de Tue Nov 4 16:50:12 2008 From: foster at in.tum.de (Mary Ellen Foster) Date: Tue, 4 Nov 2008 17:50:12 +0100 Subject: [fedora-java] Java library review requests Message-ID: I've resumed my quest to ultimately get JabRef into Fedora. In pursuit of this goal, I've begun packaging the "leaf" libraries that it requires. I've just put four libraries up for review -- I'd be very appreciative if anyone with Java expertise could take a look at them. I can't be an "official" package reviewer, but I'd be glad to do informal reviews of any other Java packages in return. - cglib: https://bugzilla.redhat.com/show_bug.cgi?id=469894 - ktable: https://bugzilla.redhat.com/show_bug.cgi?id=469895 - nachocalendar: https://bugzilla.redhat.com/show_bug.cgi?id=469896 - swingx: https://bugzilla.redhat.com/show_bug.cgi?id=469897 MEF -- Mary Ellen Foster -- http://homepages.inf.ed.ac.uk/mef/ Informatik 6: Robotics and Embedded Systems, Technische Universit?t M?nchen and ICCS, School of Informatics, University of Edinburgh From overholt at redhat.com Tue Nov 4 22:11:44 2008 From: overholt at redhat.com (Andrew Overholt) Date: Tue, 4 Nov 2008 17:11:44 -0500 Subject: [fedora-java] Re: java library deps on custom build In-Reply-To: <1225799233.2778.3.camel@choeger5.umpa.netz> References: <1225799233.2778.3.camel@choeger5.umpa.netz> Message-ID: <20081104221144.GD6986@redhat.com> Hi, (adding fedora-devel-java-list to the discussion) * Christoph H?ger [2008-11-04 07:09]: > > I've just compiled scilab on my f9 laptop and tried to run it, but get a > lot of libraries missing. Ldd says that some java libs (libjava.so, > libjvm.so) are not found. Those libraries float around > in /usr/lib/java... Shouldn't that mean that theyre found automagically > or do I really have to add every single subfolder to LD_LIBRARY_PATH? I forwarded your question to Tom Fitzsimmons and he said this: > If an application is using the JNI Invocation API -- I wouldn't be > surprised if scilab does this -- then the application should dlopen any > Java DSOs it needs. It's annoying to find them because they're > non-standard. The Fedora packages can just hard-code to > java-1.6.0-openjdk's locations, though they need to ensure they have the > proper architecture modifiers in the paths, e.g.: > /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64. OpenOffice has some > helper functions for finding these things. Maybe these could be rolled > into a libjpackage.so convenience library for reuse. > > Tom HTH, Andrew From overholt at redhat.com Wed Nov 5 13:30:01 2008 From: overholt at redhat.com (Andrew Overholt) Date: Wed, 5 Nov 2008 08:30:01 -0500 Subject: [fedora-java] Java library review requests In-Reply-To: References: Message-ID: <20081105133000.GA3689@redhat.com> * Mary Ellen Foster [2008-11-04 11:50]: > I can't be an "official" package reviewer, but I'd be glad to do > informal reviews of any other Java packages in return. If you're a Fedora contributor, you can review a package. Andrew From foster at in.tum.de Wed Nov 5 13:50:59 2008 From: foster at in.tum.de (Mary Ellen Foster) Date: Wed, 5 Nov 2008 14:50:59 +0100 Subject: [fedora-java] Java library review requests In-Reply-To: <20081105133000.GA3689@redhat.com> References: <20081105133000.GA3689@redhat.com> Message-ID: 2008/11/5 Andrew Overholt : > * Mary Ellen Foster [2008-11-04 11:50]: >> I can't be an "official" package reviewer, but I'd be glad to do >> informal reviews of any other Java packages in return. > > If you're a Fedora contributor, you can review a package. Right, yes, I just can't *sponsor* -- I forgot how that works. Is there an easy way to find Java packages up for review? Or should I just look ... MEF -- Mary Ellen Foster -- http://homepages.inf.ed.ac.uk/mef/ Informatik 6: Robotics and Embedded Systems, Technische Universit?t M?nchen and ICCS, School of Informatics, University of Edinburgh From overholt at redhat.com Wed Nov 5 13:52:04 2008 From: overholt at redhat.com (Andrew Overholt) Date: Wed, 5 Nov 2008 08:52:04 -0500 Subject: [fedora-java] Java library review requests In-Reply-To: References: <20081105133000.GA3689@redhat.com> Message-ID: <20081105135204.GB3689@redhat.com> * Mary Ellen Foster [2008-11-05 08:51]: > 2008/11/5 Andrew Overholt : > > * Mary Ellen Foster [2008-11-04 11:50]: > >> I can't be an "official" package reviewer, but I'd be glad to do > >> informal reviews of any other Java packages in return. > > > > If you're a Fedora contributor, you can review a package. > > Right, yes, I just can't *sponsor* -- I forgot how that works. Is > there an easy way to find Java packages up for review? Or should I > just look ... tibbs used to have some pre-defined queries for packages up for review but there's no way to tell in what language the contents are written. Andrew From overholt at redhat.com Wed Nov 5 14:23:47 2008 From: overholt at redhat.com (Andrew Overholt) Date: Wed, 5 Nov 2008 09:23:47 -0500 Subject: [fedora-java] Call for submissions for EclipseCon 2009 Message-ID: <20081105142347.GE3689@redhat.com> Hi, The submission system for EclipseCon 2009 is now open: http://www.eclipsecon.org/2009/submissions?page=submissions/ The deadline is the 24th of November which is coming up very soon. For those who don't know, EclipseCon is a great conference that is taking place this year from 23 - 26 March, 2009 in Santa Clara, California. It's the premiere North American Eclipse gathering and is an awesome place to learn about the latest Eclipse happenings, interact with everyone in the community and generally have a good time. There are a variety of submission categories to choose from so read the descriptions here: http://wiki.eclipse.org/EclipseCon_2009_Category_Descriptions ** New for 2009 ** This year we're having a special 1 day Linux DevCon in conjunction with the Linux Foundation. For this one day sub-conference we are looking for short talks, long talks, and tutorials dedicated to the intersection of Eclipse and Linux. We'd like to hear about Linux developments that will affect Eclipse. Much Eclipse development on and for Linux takes place on "enterprise" distributions so talks discussing more bleeding edge developments and ideas about the future of Linux technologies would be especially welcome. We are also interested in learning about Linux-specific Eclipse tooling and Linux adoption of Eclipse tools - what's good, what's bad, what's missing? What recent and upcoming developments in the Linux ecosystem will affect Eclipse? We would also like to hear about development, deployment, and use of Eclipse technologies in multi-platform environments. What are some areas where Eclipse and Linux technologies can make more effective use of each other? What can Eclipse learn from Linux and other Free Software/Open Source communities and vice versa? Let me know if you have any questions. I look forward to lots of great submissions! Thanks, Andrew From green at redhat.com Mon Nov 10 22:45:06 2008 From: green at redhat.com (Anthony Green) Date: Mon, 10 Nov 2008 14:45:06 -0800 Subject: [fedora-java] Orphaning jakarta-commons-cli Message-ID: <4918B972.4040606@redhat.com> I plan on orphaning jakarta-commons-cli. This package is still required by checkstyle and others, but I have no interest in maintaining it. This old bugzilla..... https://bugzilla.redhat.com/show_bug.cgi?id=453018 ...tells me there's a new version. I have not managed to make time to upgrade the package, so I'm hoping somebody with more interest will make the effort. Contact me if you are willing to take this package over. Thanks! Anthony Green From orion at cora.nwra.com Mon Nov 10 23:20:35 2008 From: orion at cora.nwra.com (Orion Poplawski) Date: Mon, 10 Nov 2008 16:20:35 -0700 Subject: [fedora-java] Help building gridengine-sdm Message-ID: <4918C1C3.4050902@cora.nwra.com> I'm trying to package gridengine-sdm. I have a src.rpm here: http://www.cora.nwra.com/~orion/gridengine-sdm-1.0u1-1.fc9.src.rpm Build error: cat > build_private.properties < References: <4918C1C3.4050902@cora.nwra.com> Message-ID: <870180fe0811101546y50ee20fbp752d132094efbce4@mail.gmail.com> On Mon, Nov 10, 2008 at 4:20 PM, Orion Poplawski wrote: > I'm trying to package gridengine-sdm. I have a src.rpm here: > > http://www.cora.nwra.com/~orion/gridengine-sdm-1.0u1-1.fc9.src.rpm > I get an HTTP 404 on that URL. Regards, -- Jerry James http://loganjerry.googlepages.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From orion at cora.nwra.com Mon Nov 10 23:59:56 2008 From: orion at cora.nwra.com (Orion Poplawski) Date: Mon, 10 Nov 2008 16:59:56 -0700 Subject: [fedora-java] Help building gridengine-sdm In-Reply-To: <4918C1C3.4050902@cora.nwra.com> References: <4918C1C3.4050902@cora.nwra.com> Message-ID: <4918CAFC.6020003@cora.nwra.com> Orion Poplawski wrote: > So why isn't it finding /usr/share/java/ant.jar? > Looks like upstream expects ant.jar to be in ${ant.home}/lib/ant.jar, which would be /usr/share/ant/lib/ant.jar. I've patched to ${java.home}/ant.jar. Should we have a link? -- 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 jmrodri at gmail.com Tue Nov 11 05:20:12 2008 From: jmrodri at gmail.com (Jesus M. Rodriguez) Date: Tue, 11 Nov 2008 00:20:12 -0500 Subject: [fedora-java] Orphaning jakarta-commons-cli In-Reply-To: <4918B972.4040606@redhat.com> References: <4918B972.4040606@redhat.com> Message-ID: On Mon, Nov 10, 2008 at 5:45 PM, Anthony Green wrote: > I plan on orphaning jakarta-commons-cli. This package is still required by > checkstyle and others, but I have no interest in maintaining it. > This old bugzilla..... > https://bugzilla.redhat.com/show_bug.cgi?id=453018 > ...tells me there's a new version. I have not managed to make time to > upgrade the package, so I'm hoping somebody with more interest will make the > effort. Contact me if you are willing to take this package over. > > Thanks! > > Anthony Green I'd be interested. We use this on Spacewalk. jesus From green at redhat.com Tue Nov 11 11:50:41 2008 From: green at redhat.com (Anthony Green) Date: Tue, 11 Nov 2008 03:50:41 -0800 Subject: [fedora-java] Orphaning jakarta-commons-cli In-Reply-To: References: <4918B972.4040606@redhat.com> Message-ID: <49197191.8070009@redhat.com> Jesus M. Rodriguez wrote: > On Mon, Nov 10, 2008 at 5:45 PM, Anthony Green wrote: > >> I plan on orphaning jakarta-commons-cli. This package is still required by >> checkstyle and others, but I have no interest in maintaining it. >> This old bugzilla..... >> https://bugzilla.redhat.com/show_bug.cgi?id=453018 >> ...tells me there's a new version. I have not managed to make time to >> upgrade the package, so I'm hoping somebody with more interest will make the >> effort. Contact me if you are willing to take this package over. >> >> Thanks! >> >> Anthony Green >> > > I'd be interested. We use this on Spacewalk. > Thank you Jesus. I've release ownership in the package db for F-9, F-10 and devel. rakesh at fedoraproject.org has also volunteered to co-maintain. AG > > jesus > From orion at cora.nwra.com Tue Nov 11 16:29:06 2008 From: orion at cora.nwra.com (Orion Poplawski) Date: Tue, 11 Nov 2008 09:29:06 -0700 Subject: [fedora-java] glassfish-jaxb Message-ID: <4919B2D2.7010501@cora.nwra.com> Is there anything preventing glassfish-jaxb from being packaged in Fedora? -- 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 overholt at redhat.com Wed Nov 12 14:01:37 2008 From: overholt at redhat.com (Andrew Overholt) Date: Wed, 12 Nov 2008 09:01:37 -0500 Subject: [fedora-java] glassfish-jaxb In-Reply-To: <4919B2D2.7010501@cora.nwra.com> References: <4919B2D2.7010501@cora.nwra.com> Message-ID: <20081112140136.GG6676@redhat.com> * Orion Poplawski [2008-11-11 11:36]: > Is there anything preventing glassfish-jaxb from being packaged in Fedora? I think Alex may have looked at this recently. Alex? Andrew From overholt at redhat.com Wed Nov 12 14:03:22 2008 From: overholt at redhat.com (Andrew Overholt) Date: Wed, 12 Nov 2008 09:03:22 -0500 Subject: [fedora-java] Help building gridengine-sdm In-Reply-To: <4918CAFC.6020003@cora.nwra.com> References: <4918C1C3.4050902@cora.nwra.com> <4918CAFC.6020003@cora.nwra.com> Message-ID: <20081112140321.GH6676@redhat.com> * Orion Poplawski [2008-11-10 19:01]: > Orion Poplawski wrote: >> So why isn't it finding /usr/share/java/ant.jar? >> > > Looks like upstream expects ant.jar to be in ${ant.home}/lib/ant.jar, > which would be /usr/share/ant/lib/ant.jar. I've patched to > ${java.home}/ant.jar. Should we have a link? If upstream ant packages things in a lib/ subdir, I'd be inclined to say yes. Maybe we should check with JPackage as to why they don't do this. Andrew From akurtako at redhat.com Wed Nov 12 14:38:06 2008 From: akurtako at redhat.com (Alexander Kurtakov) Date: Wed, 12 Nov 2008 15:38:06 +0100 Subject: [fedora-java] glassfish-jaxb In-Reply-To: <20081112140136.GG6676@redhat.com> References: <4919B2D2.7010501@cora.nwra.com> <20081112140136.GG6676@redhat.com> Message-ID: <491AEA4E.5000200@redhat.com> Andrew Overholt wrote: > * Orion Poplawski [2008-11-11 11:36]: > >> Is there anything preventing glassfish-jaxb from being packaged in Fedora? >> > > I think Alex may have looked at this recently. Alex? > > Andrew > We have ws-jaxme in Fedora - the jaxb implementation from apache and we are using it in eclipse-mylyn. My opinion is that it would be better if we bet on the glassfish JEE apis. But I'm not planning any work on this. Jaxb and other glassfish modules are already in jpackage repos so we should better import them directly from there. These should be coordinated with jboss/jpackage team to not duplicate work. Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From orion at cora.nwra.com Wed Nov 12 15:55:47 2008 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 12 Nov 2008 08:55:47 -0700 Subject: [fedora-java] Help building gridengine-sdm In-Reply-To: <20081112140321.GH6676@redhat.com> References: <4918C1C3.4050902@cora.nwra.com> <4918CAFC.6020003@cora.nwra.com> <20081112140321.GH6676@redhat.com> Message-ID: <491AFC83.5040403@cora.nwra.com> Andrew Overholt wrote: > * Orion Poplawski [2008-11-10 19:01]: >> Orion Poplawski wrote: >>> So why isn't it finding /usr/share/java/ant.jar? >>> >> Looks like upstream expects ant.jar to be in ${ant.home}/lib/ant.jar, >> which would be /usr/share/ant/lib/ant.jar. I've patched to >> ${java.home}/ant.jar. Should we have a link? > > If upstream ant packages things in a lib/ subdir, I'd be inclined to say > yes. Maybe we should check with JPackage as to why they don't do this. > > Andrew I've reopened https://bugzilla.redhat.com/show_bug.cgi?id=179759 -- 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 orcanbahri at yahoo.com Wed Nov 19 06:14:33 2008 From: orcanbahri at yahoo.com (Orcan Ogetbil) Date: Tue, 18 Nov 2008 22:14:33 -0800 (PST) Subject: [fedora-java] How to link C++ code to a java library? Message-ID: <628653.57495.qm@web32807.mail.mud.yahoo.com> Hi, I recently got this query for itext [1] that is maintained in Fedora by me. I've been asked to provide a "JNI subpackage" [2]. Unfortunately, I am not familiar with JNI. This person wants to package pdftk [3], which is a c++ application. The original pdftk code contains an old version of itext and it links to it statically. Meanwhile, the old version of itext had licensing issues and it had been removed from Fedora almost 2 years ago. But these issues got resolved recently and I packaged itext for Fedora once again. Now the question is: Can we link pdftk dynamically to new itext we have on the system? After some consultation in IRC, I've been told that JNI is not what we need in this case. And a suggestion came up: Apparently we can use GCJ to do this job. But this will require non-trivial hacking. Can anyone point me to some guidelines for this and/or give me a head-start? Thanks, -oget Refs: [1] http://www.lowagie.com/iText/download.html [2] https://bugzilla.redhat.com/show_bug.cgi?id=471811 [3] http://www.pdfhacks.com/pdftk/ From mark at klomp.org Wed Nov 19 08:33:52 2008 From: mark at klomp.org (Mark Wielaard) Date: Wed, 19 Nov 2008 09:33:52 +0100 Subject: [fedora-java] How to link C++ code to a java library? In-Reply-To: <628653.57495.qm@web32807.mail.mud.yahoo.com> References: <628653.57495.qm@web32807.mail.mud.yahoo.com> Message-ID: <1227083632.3648.7.camel@hermans.wildebeest.org> Hi Orcan, On Tue, 2008-11-18 at 22:14 -0800, Orcan Ogetbil wrote: > After some consultation in IRC, I've been told that JNI is not what we > need in this case. And a suggestion came up: Apparently we can use GCJ > to do this job. But this will require non-trivial hacking. Can anyone > point me to some guidelines for this and/or give me a head-start? The program, pdftk, is a c++ program that uses gcj's CNI (not JNI) feature to call java classes. Here is some background information on CNI: http://gcc.gnu.org/onlinedocs/gcj/About-CNI.html In principle you would only need to provide CNI headers for the itext classes (see gcjh) and a shared library build from the itext classes or jar file (see gcj). But it depends a bit on coordinating with the pdftk packager. Currently the pdftk build seems to just bundle all of itext and compile it into one big static library. Cheers, Mark From orcanbahri at yahoo.com Wed Nov 19 08:36:28 2008 From: orcanbahri at yahoo.com (Orcan Ogetbil) Date: Wed, 19 Nov 2008 00:36:28 -0800 (PST) Subject: [fedora-java] Suggestions to improve the JAVA guidelines Message-ID: <827884.78114.qm@web32808.mail.mud.yahoo.com> Hi, As I promised overholt on IRC, I wanted to share my views about the Fedora Java packaging guidelines from a non-Java-coder point of view. JAVA GUIDELINES: - "JNI-using JAR files" This link is broken. It can be fixed easily. - BuildRequires: jpackage-utils Why do we need this? I understand Requires: jpackage-utils for directory ownership etc, but the BR is not necessary for most packages (at least all the ones I saw so far). I think this should *not* be required. - In certain cases, we can build applications GCJ-natively (producing .so files). But these won't work with any JVM. What should be the packager's primary preference? GCJ-native or OpenJDK? The first one runs faster, but the second one has larger coverage. For instance, tuxguitar (that I packaged) provides GNU Makefiles (that use GCJ) for this. Are the resulting .so files going to be the same as the ones built by aot-compile-rpm? (More about AOT later) This case has confused me a lot in the past. - Some explanation in the beginning about what GCJ can do and what openjdk can do; and some information about byte-code vs. machine-code will be very useful. - BuildRequires: java-devel [>= specific_version] How will the packager get to know the "specific_version"? For openjdk this is 1:1.6.0 , but for GCJ this is 1.5.0 . Are there other numbers that we need to know? Can't we put the numbers for all the cases in the guidelines? - The Specfile Templates for ant and maven contradict with what was written in the BuildRequires and Requires section. - the abbreviation "SNPG" should be defined in the first possible place, not in the third iteration (both for ant and maven). - "Will this preserve the line ending as the this page says it must?" This would be an artistic ending if we were writing a novel. But I think a guideline shouldn't end with open questions :) GCJ GUIDELINES: - It would be nice if there was a definition of GCJ-AOT bits. What do they do? Why do we like them? What does gij do? etc - "Note: For Fedora versions < 8, no JDK was available other than GCJ so java packages with executable code MUST have the GCJ AOT bits." This notice can be removed safely. - The occurences of %attr(-,root,root) should be removed. - GCJ AOT bits SHOULD be built and included in packages. This needs to be more explicit. ie. 's at in packages at in all Java packages@'. I also think that this sentence should go to JAVA GUIDELINES so people click on the link for "GCJ Guidelines". The way that "GCJ Guidelines" link is put there, doesn't give an impression that it should be visited for any possible Java package. These are all issues I encountered. If I remember more I will post them here. I thought a review on the guidelines from a Java-ignorant person would help other Java-ignorant people in the future. Thanks for reading :) -oget From orcanbahri at yahoo.com Wed Nov 19 20:23:48 2008 From: orcanbahri at yahoo.com (Orcan Ogetbil) Date: Wed, 19 Nov 2008 12:23:48 -0800 (PST) Subject: [fedora-java] Suggestions to improve the JAVA guidelines In-Reply-To: <827884.78114.qm@web32808.mail.mud.yahoo.com> Message-ID: <944056.4440.qm@web32808.mail.mud.yahoo.com> Apparently Conrad forgot to send his reply to the mailing list. With his permission I'm quoting the message he sent to me: --- On Wed, 11/19/08, Conrad Meyer wrote: > > Hi, > > As I promised overholt on IRC, I wanted to share my > views about the Fedora > > Java packaging guidelines from a non-Java-coder point > of view. > > > > JAVA GUIDELINES: > > > > - "JNI-using JAR files" > > This link is broken. It can be fixed easily. > > > > - BuildRequires: jpackage-utils > > Why do we need this? I understand Requires: > jpackage-utils for directory > > ownership etc, but the BR is not necessary for most > packages (at least all > > the ones I saw so far). I think this should *not* be > required. > > rpm -ql jpackage-utils | grep /usr/bin > > A lot of these are useful. > Yes, I agree. But can't we leave the BR out for those packages which don't use these tools? > > - In certain cases, we can build applications > GCJ-natively (producing .so > > files). But these won't work with any JVM. What > should be the packager's > > primary preference? GCJ-native or OpenJDK? The first > one runs faster, but > > the second one has larger coverage. > > We prefer both, but only require .class files (compiled by > either GCJ or > OpenJDK). > > > For instance, tuxguitar (that I packaged) provides GNU > Makefiles (that use > > GCJ) for this. Are the resulting .so files going to be > the same as the ones > > built by aot-compile-rpm? (More about AOT later) > > > > This case has confused me a lot in the past. > > I think we require you to ship .class files as well if > it's a java project. > Let's make this clear: .jar files are nothing but containers of .class files and a manifest file, right? When you say we require .class files, does that imply that we require them either standalone or inside some .jar file? If yes, these statements should go to the guidelines. Also, I'd be glad if someone answers my question above? > > - Some explanation in the beginning about what GCJ can > do and what openjdk > > can do; and some information about byte-code vs. > machine-code will be very > > useful. > > > > - BuildRequires: java-devel [>= specific_version] > > How will the packager get to know the > "specific_version"? For openjdk this > > is 1:1.6.0 , but for GCJ this is 1.5.0 . Are there > other numbers that we > > need to know? Can't we put the numbers for all the > cases in the guidelines? > > Just those, I think. Adding them somewhere couldn't > hurt. > > > - The Specfile Templates for ant and maven contradict > with what was written > > in the BuildRequires and Requires section. > > How? > In the "BuildRequires and Requires section", it states that we need to put explicit versions for R:java and BR:java-devel. Yet in the templates no explicit versions were used or indicated. > > - the abbreviation "SNPG" should be defined > in the first possible place, > > not in the third iteration (both for ant and maven). > > It's commonly used by other > non-normal-packaging-guidelines documentation, but > this confused me at first as well. > > > - "Will this preserve the line ending as the this > page says it must?" > > This would be an artistic ending if we were writing a > novel. But I think a > > guideline shouldn't end with open questions :) > > > > GCJ GUIDELINES: > > > > - It would be nice if there was a definition of > GCJ-AOT bits. What do they > > do? Why do we like them? What does gij do? etc > > > > - "Note: For Fedora versions < 8, no JDK was > available other than GCJ so > > java packages with executable code MUST have the GCJ > AOT bits." > > > > This notice can be removed safely. > > When this was written F-7 wasn't yet EOL, I think. > Agreed. > > > - The occurences of > > %attr(-,root,root) > > should be removed. > > > > - GCJ AOT bits SHOULD be built and included in > packages. > > This needs to be more explicit. ie. 's at in > packages at in all Java packages@'. > > Eh, it's in the GCJ/Java guidelines page, not anything > for all packages. > I am not saying "all packages". I say "all Java packages". I have to say that being explicit clears an important amount of confusion in most cases I encounter in life. > > I also think that this sentence should go to JAVA > GUIDELINES so people > > click on the link for "GCJ Guidelines". The > way that "GCJ Guidelines" link > > is put there, doesn't give an impression that it > should be visited for any > > possible Java package. > > Makes sense. > > > These are all issues I encountered. If I remember more > I will post them > > here. I thought a review on the guidelines from a > Java-ignorant person > > would help other Java-ignorant people in the future. > Thanks for reading :) > > > > -oget > > I agree with most of your criticisms and would welcome > these changes. I think > the wiki page is locked though. > > Regards, > -- Cheers, -oget From overholt at redhat.com Thu Nov 20 16:17:47 2008 From: overholt at redhat.com (Andrew Overholt) Date: Thu, 20 Nov 2008 11:17:47 -0500 Subject: [fedora-java] Drop GCJ AOT bits for F11? Message-ID: <20081120161746.GC9094@redhat.com> Hi, Back when we wrote the initial Java packaging guidelines, we said that packagers *should* include GCJ AOT bits. Should we remove this requirement for Fedora 11 and beyond? Also, GCJ is still in the base install set for Fedora. Should we remove this and make OpenJDK a default? Andrew From aph at redhat.com Thu Nov 20 16:33:26 2008 From: aph at redhat.com (Andrew Haley) Date: Thu, 20 Nov 2008 16:33:26 +0000 Subject: [fedora-java] Drop GCJ AOT bits for F11? In-Reply-To: <20081120161746.GC9094@redhat.com> References: <20081120161746.GC9094@redhat.com> Message-ID: <49259156.5090709@redhat.com> Andrew Overholt wrote: > Back when we wrote the initial Java packaging guidelines, we said that > packagers *should* include GCJ AOT bits. Should we remove this > requirement for Fedora 11 and beyond? > > Also, GCJ is still in the base install set for Fedora. Should we remove > this and make OpenJDK a default? This is a bit premature. We still don't have the OpenJDK JIT for PPC and ARM arches. We're working hard on it but it's not ready yet for prime-time. Without the JIT, OpenJDK is crushingly slow on these arches. Having said that, there's no reason not to make OpenJDK the default on the arches where it performs well: x86 and 8x6_64 at the monent. Andrew. From overholt at redhat.com Thu Nov 20 16:43:16 2008 From: overholt at redhat.com (Andrew Overholt) Date: Thu, 20 Nov 2008 11:43:16 -0500 Subject: [fedora-java] Drop GCJ AOT bits for F11? In-Reply-To: <49259156.5090709@redhat.com> References: <20081120161746.GC9094@redhat.com> <49259156.5090709@redhat.com> Message-ID: <20081120164315.GA4219@redhat.com> * Andrew Haley [2008-11-20 11:33]: > Andrew Overholt wrote: > > > Back when we wrote the initial Java packaging guidelines, we said that > > packagers *should* include GCJ AOT bits. Should we remove this > > requirement for Fedora 11 and beyond? > > > > [...] > > This is a bit premature. We still don't have the OpenJDK JIT for PPC and > ARM arches. We're working hard on it but it's not ready yet for prime-time. > Without the JIT, OpenJDK is crushingly slow on these arches. Should Smolt stats on architecture users affect this decision? It says about 0.7% of users are on platforms without OpenJDK JITs. http://smolts.org/static/stats/stats.html Andrew From aph at redhat.com Thu Nov 20 17:00:50 2008 From: aph at redhat.com (Andrew Haley) Date: Thu, 20 Nov 2008 17:00:50 +0000 Subject: [fedora-java] Drop GCJ AOT bits for F11? In-Reply-To: <20081120164315.GA4219@redhat.com> References: <20081120161746.GC9094@redhat.com> <49259156.5090709@redhat.com> <20081120164315.GA4219@redhat.com> Message-ID: <492597C2.4040805@redhat.com> Andrew Overholt wrote: > * Andrew Haley [2008-11-20 11:33]: >> Andrew Overholt wrote: >> >>> Back when we wrote the initial Java packaging guidelines, we said that >>> packagers *should* include GCJ AOT bits. Should we remove this >>> requirement for Fedora 11 and beyond? >>> >>> Also, GCJ is still in the base install set for Fedora. Should we remove >>> this and make OpenJDK a default? >> >> This is a bit premature. We still don't have the OpenJDK JIT for PPC and >> ARM arches. We're working hard on it but it's not ready yet for prime-time. >> Without the JIT, OpenJDK is crushingly slow on these arches. > > Should Smolt stats on architecture users affect this decision? It says > about 0.7% of users are on platforms without OpenJDK JITs. > > http://smolts.org/static/stats/stats.html I was hoping to be able to keep all arches going with gcj until a really first-rate OpenJDK solution was available everywhere. I don't think we want to make the useers of these arches into second- class citizens: Fedora ARM, in particular, is great for mobile devices and hasn't been supported for very long. I think its usage will increase. Sure, the number of users is low, but on lower-performance boxes the penalty of not having gcj and gcj-compiled packages available is quite severe. I wouldn't object to weakening the "should" to a "may" where aot-compiling is a problem. Even without precompiled applications, gcj is still a lot faster than the OpenJDK C++ interpreter. Andrew. From konrad at tylerc.org Thu Nov 20 17:09:19 2008 From: konrad at tylerc.org (Conrad Meyer) Date: Thu, 20 Nov 2008 09:09:19 -0800 Subject: [fedora-java] Drop GCJ AOT bits for F11? In-Reply-To: <492597C2.4040805@redhat.com> References: <20081120161746.GC9094@redhat.com> <20081120164315.GA4219@redhat.com> <492597C2.4040805@redhat.com> Message-ID: <200811200909.19560.konrad@tylerc.org> On Thursday 20 November 2008 09:00:50 am Andrew Haley wrote: > Andrew Overholt wrote: > > * Andrew Haley [2008-11-20 11:33]: > >> Andrew Overholt wrote: > >>> Back when we wrote the initial Java packaging guidelines, we said that > >>> packagers *should* include GCJ AOT bits. Should we remove this > >>> requirement for Fedora 11 and beyond? > >>> > >>> Also, GCJ is still in the base install set for Fedora. Should we > >>> remove this and make OpenJDK a default? > >> > >> This is a bit premature. We still don't have the OpenJDK JIT for PPC > >> and ARM arches. We're working hard on it but it's not ready yet for > >> prime-time. Without the JIT, OpenJDK is crushingly slow on these arches. > > > > Should Smolt stats on architecture users affect this decision? It says > > about 0.7% of users are on platforms without OpenJDK JITs. > > > > http://smolts.org/static/stats/stats.html > > I was hoping to be able to keep all arches going with gcj until a > really first-rate OpenJDK solution was available everywhere. I don't > think we want to make the useers of these arches into second- class > citizens: Fedora ARM, in particular, is great for mobile devices and > hasn't been supported for very long. I think its usage will increase. > > Sure, the number of users is low, but on lower-performance boxes the > penalty of not having gcj and gcj-compiled packages available is quite > severe. I wouldn't object to weakening the "should" to a "may" where > aot-compiling is a problem. Even without precompiled applications, > gcj is still a lot faster than the OpenJDK C++ interpreter. > > Andrew. I'm also for keeping gcj (for now). OpenJDK is great where it JITs but it's miserable on PPC (e.g. my laptop). I think the guidelines could say something about "if you run into a problem with a non trivial fix compiling gcj AOT bits, it's ok to drop the aot bits". Regards, -- Conrad Meyer From Victor.Vasilyev at Sun.COM Thu Nov 20 19:40:25 2008 From: Victor.Vasilyev at Sun.COM (Victor Vasilyev) Date: Thu, 20 Nov 2008 22:40:25 +0300 Subject: [fedora-java] Suggestions to improve the JAVA guidelines In-Reply-To: <944056.4440.qm@web32808.mail.mud.yahoo.com> References: <944056.4440.qm@web32808.mail.mud.yahoo.com> Message-ID: <4925BD29.5000208@sun.com> Orcan, Orcan Ogetbil wrote: > Let's make this clear: .jar files are nothing but containers of .class files and a manifest file, right? A JAR file can have a bit more functions than providing a simplest ZIP archive of .class files and a manifest file. But, globally you are right, JAR is container for resources intended to be used by Java program(s). Complete info about it in the JAR File Specification [1] . IMHO Ideally, a JAR file in the target software package (i.e. in the binary RPM) should be the same as the JAR file that is originally provided by its Java software project. Of course, it is true only if there are no intentions to change original behavior of the Java applications that are based on that JAR file. BTW Such viewpoint gives me idea that repackaging of JARs via brp-java-repack-jars is not good for pure Java software at all. Note, it doesn't meet a requirement declared in the message [2] : "... a jar ... needs to be repacked if (a) it is destined for /usr/share/ ..." [1] http://java.sun.com/javase/6/docs/technotes/guides/jar/jar.html [2] https://www.redhat.com/archives/fedora-devel-java-list/2008-September/msg00042.html Cheers, Victor Vasilyev From overholt at redhat.com Thu Nov 20 19:49:44 2008 From: overholt at redhat.com (Andrew Overholt) Date: Thu, 20 Nov 2008 14:49:44 -0500 Subject: [fedora-java] Drop GCJ AOT bits for F11? In-Reply-To: <492597C2.4040805@redhat.com> References: <20081120161746.GC9094@redhat.com> <49259156.5090709@redhat.com> <20081120164315.GA4219@redhat.com> <492597C2.4040805@redhat.com> Message-ID: <20081120194944.GJ4219@redhat.com> * Andrew Haley [2008-11-20 12:00]: > I was hoping to be able to keep all arches going with gcj until a > really first-rate OpenJDK solution was available everywhere. Do we anticipate this happening before the F11 freeze? When I asked this question it wasn't meant as a "let's do it today!" kind of thing but more a "we need to seriously think about this for F11 now that F10 is basically out the door" :) . > Sure, the number of users is low, but on lower-performance boxes the > penalty of not having gcj and gcj-compiled packages available is quite > severe. Do we have numbers on this? I know you are correct but having hard numbers would be nice. Andrew From mark at klomp.org Fri Nov 21 13:36:15 2008 From: mark at klomp.org (Mark Wielaard) Date: Fri, 21 Nov 2008 14:36:15 +0100 Subject: [fedora-java] Drop GCJ AOT bits for F11? In-Reply-To: <20081120194944.GJ4219@redhat.com> References: <20081120161746.GC9094@redhat.com> <49259156.5090709@redhat.com> <20081120164315.GA4219@redhat.com> <492597C2.4040805@redhat.com> <20081120194944.GJ4219@redhat.com> Message-ID: <1227274575.4715.20.camel@dijkstra.wildebeest.org> On Thu, 2008-11-20 at 14:49 -0500, Andrew Overholt wrote: > * Andrew Haley [2008-11-20 12:00]: > > Sure, the number of users is low, but on lower-performance boxes the > > penalty of not having gcj and gcj-compiled packages available is quite > > severe. > > Do we have numbers on this? I know you are correct but having hard > numbers would be nice. I only have anecdotal evidence (I did these experiments a long time ago). Running eclipse fully interpreted, through for example jamvm (sadly not packaged for Fedora yet), is on the order of 4 to 8 times as slow as running eclipse interpreted with gij and aot-compiled core class libraries. And the jamvm interpreter is faster than the standard interpreter that comes with hotspot. Comparing gij on a pure-bytecode program versus a the same compiled aot with gcj doesn't directly give you the correct (hard) numbers though. Since gij will at least use the aot compiled core-library (so at least things like your String operations and HashMaps, etc are optimized). I believe Andrew Hughes (CCed) has a zero-on-x86 install. So he might be able to give a real number of how much slower zero-interpreted against full hotspot and/or a fully gcj native compiled program is. Cheers, Mark From orion at cora.nwra.com Fri Nov 21 17:08:06 2008 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 21 Nov 2008 10:08:06 -0700 Subject: [fedora-java] openjdk's rt.jar Message-ID: <4926EAF6.9010500@cora.nwra.com> -rw-r--r-- 1 root root 54M 2008-09-08 13:39 ./java-1.6.0-openjdk-1.6.0.0/jre/lib/rt.jar -rw-r--r-- 1 root root 24M 2008-10-21 15:40 ./java-1.6.0-sun-1.6.0.10/jre/lib/rt.jar Why so much bigger? -- 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 Nov 21 17:18:12 2008 From: aph at redhat.com (Andrew Haley) Date: Fri, 21 Nov 2008 17:18:12 +0000 Subject: [fedora-java] openjdk's rt.jar In-Reply-To: <4926EAF6.9010500@cora.nwra.com> References: <4926EAF6.9010500@cora.nwra.com> Message-ID: <4926ED54.4070000@redhat.com> Orion Poplawski wrote: > -rw-r--r-- 1 root root 54M 2008-09-08 13:39 > ./java-1.6.0-openjdk-1.6.0.0/jre/lib/rt.jar > -rw-r--r-- 1 root root 24M 2008-10-21 15:40 > ./java-1.6.0-sun-1.6.0.10/jre/lib/rt.jar > > Why so much bigger? I'd open them up and diff the trees. Andrew. From david at zarb.org Fri Nov 21 17:30:05 2008 From: david at zarb.org (David Walluck) Date: Fri, 21 Nov 2008 12:30:05 -0500 Subject: [fedora-java] openjdk's rt.jar In-Reply-To: <4926ED54.4070000@redhat.com> References: <4926EAF6.9010500@cora.nwra.com> <4926ED54.4070000@redhat.com> Message-ID: <4926F01D.40302@zarb.org> Andrew Haley wrote: > Orion Poplawski wrote: >> -rw-r--r-- 1 root root 54M 2008-09-08 13:39 >> ./java-1.6.0-openjdk-1.6.0.0/jre/lib/rt.jar >> -rw-r--r-- 1 root root 24M 2008-10-21 15:40 >> ./java-1.6.0-sun-1.6.0.10/jre/lib/rt.jar >> >> Why so much bigger? > > I'd open them up and diff the trees. Or use the diff-jars script from jpackage-utils. -- Sincerely, David Walluck From ahughes at redhat.com Fri Nov 21 18:11:40 2008 From: ahughes at redhat.com (Andrew John Hughes) Date: Fri, 21 Nov 2008 18:11:40 +0000 Subject: [fedora-java] openjdk's rt.jar In-Reply-To: <4926ED54.4070000@redhat.com> References: <4926EAF6.9010500@cora.nwra.com> <4926ED54.4070000@redhat.com> Message-ID: <4926F9DC.4060201@redhat.com> Andrew Haley wrote: > Orion Poplawski wrote: >> -rw-r--r-- 1 root root 54M 2008-09-08 13:39 >> ./java-1.6.0-openjdk-1.6.0.0/jre/lib/rt.jar >> -rw-r--r-- 1 root root 24M 2008-10-21 15:40 >> ./java-1.6.0-sun-1.6.0.10/jre/lib/rt.jar >> >> Why so much bigger? > > I'd open them up and diff the trees. > > Andrew. > > > -- > fedora-devel-java-list mailing list > fedora-devel-java-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-java-list Interesting. Assuming they both have similar contents, it could be that the IcedTea builds enable debug info. -- Andrew :) From orion at cora.nwra.com Fri Nov 21 19:14:29 2008 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 21 Nov 2008 12:14:29 -0700 Subject: [fedora-java] openjdk's rt.jar In-Reply-To: <4926ED54.4070000@redhat.com> References: <4926EAF6.9010500@cora.nwra.com> <4926ED54.4070000@redhat.com> Message-ID: <49270895.4090206@cora.nwra.com> Andrew Haley wrote: > Orion Poplawski wrote: >> -rw-r--r-- 1 root root 54M 2008-09-08 13:39 >> ./java-1.6.0-openjdk-1.6.0.0/jre/lib/rt.jar >> -rw-r--r-- 1 root root 24M 2008-10-21 15:40 >> ./java-1.6.0-sun-1.6.0.10/jre/lib/rt.jar >> >> Why so much bigger? > > I'd open them up and diff the trees. > > Andrew. > I think it's compression level. Here are the uncompressed sizes: 167480 rt-sun 171788 rt-openjdk [root at cynosure rt-sun]# dus 16 META-INF 48 sunw 7060 org 22396 java 30156 javax 38972 sun 68824 com [root at cynosure rt-openjdk]# dus 16 META-INF 48 sunw 1336 net 7148 org 23576 java 31792 javax 39652 sun 68212 com If I repack rt-openjdk: zip -r rt-openjdk.zip rt-openjdk 27M 2008-11-21 11:55 rt-openjdk.zip So, we're packing jars with minimal compression? No, /usr/lib/rpm/redhat/brp-java-repack-jars uses zip -9 and java-1.6.0-openjdk turns off __jar_repack. So, something in the openjdk build does it... Looks like it's built with: if ! test -d /builddir/build/BUILD/icedtea6-1.4/bootstrap/jdk1.6.0 ; \ then \ /usr/lib/jvm/java-openjdk/bin/jar cf bootstrap/jdk1.7.0/jre/lib/rt-closed.jar -C lib/rt com -C lib/rt java \ -C lib/rt javax -C lib/rt netscape -C lib/rt net -C lib/rt sun ; \ else \ /builddir/build/BUILD/icedtea6-1.4/bootstrap/jdk1.6.0/bin/jar cf bootstrap/jdk1.7.0/jre/lib/rt-closed.jar -C lib/rt com -C lib/rt java \ -C lib/rt javax -C lib/rt netscape -C lib/rt net -C lib/rt sun ; \ fi So, does the "jar" command use compression? -- 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 ahughes at redhat.com Fri Nov 21 19:34:46 2008 From: ahughes at redhat.com (Andrew John Hughes) Date: Fri, 21 Nov 2008 19:34:46 +0000 Subject: [fedora-java] openjdk's rt.jar In-Reply-To: <49270895.4090206@cora.nwra.com> References: <4926EAF6.9010500@cora.nwra.com> <4926ED54.4070000@redhat.com> <49270895.4090206@cora.nwra.com> Message-ID: <49270D56.50700@redhat.com> Orion Poplawski wrote: > Andrew Haley wrote: >> Orion Poplawski wrote: >>> -rw-r--r-- 1 root root 54M 2008-09-08 13:39 >>> ./java-1.6.0-openjdk-1.6.0.0/jre/lib/rt.jar >>> -rw-r--r-- 1 root root 24M 2008-10-21 15:40 >>> ./java-1.6.0-sun-1.6.0.10/jre/lib/rt.jar >>> >>> Why so much bigger? >> >> I'd open them up and diff the trees. >> >> Andrew. >> > > I think it's compression level. Here are the uncompressed sizes: > > 167480 rt-sun > 171788 rt-openjdk > > [root at cynosure rt-sun]# dus > 16 META-INF > 48 sunw > 7060 org > 22396 java > 30156 javax > 38972 sun > 68824 com > > [root at cynosure rt-openjdk]# dus > 16 META-INF > 48 sunw > 1336 net > 7148 org > 23576 java > 31792 javax > 39652 sun > 68212 com > > If I repack rt-openjdk: zip -r rt-openjdk.zip rt-openjdk > > 27M 2008-11-21 11:55 rt-openjdk.zip > > So, we're packing jars with minimal compression? No, > /usr/lib/rpm/redhat/brp-java-repack-jars uses zip -9 and > java-1.6.0-openjdk turns off __jar_repack. > > So, something in the openjdk build does it... > > Looks like it's built with: > > if ! test -d /builddir/build/BUILD/icedtea6-1.4/bootstrap/jdk1.6.0 ; \ > then \ > /usr/lib/jvm/java-openjdk/bin/jar cf > bootstrap/jdk1.7.0/jre/lib/rt-closed.jar -C lib/rt com -C lib/rt java \ > -C lib/rt javax -C lib/rt netscape -C lib/rt net -C lib/rt sun ; \ > else \ > /builddir/build/BUILD/icedtea6-1.4/bootstrap/jdk1.6.0/bin/jar cf > bootstrap/jdk1.7.0/jre/lib/rt-closed.jar -C lib/rt com -C lib/rt java \ > -C lib/rt javax -C lib/rt netscape -C lib/rt net -C lib/rt sun ; \ > fi > > So, does the "jar" command use compression? > That's not building the final rt.jar. That's just the faked binary plugs (which we don't actually need any more btw...) The IcedTea build is basically done in two stages: an autoconf/automake IcedTea part which sets up the environment and then fires a second stage which runs the underlying OpenJDK makefiles. For bootstrap builds, the OpenJDK make is run twice, the second time with the results of the first build as the build JDK. rt.jar is built as part of Sun's OpenJDK make process. The offending line is: /builder/builds/icedtea/bootstrap/jdk1.6.0/bin/jar c0mf /builder/builds/icedtea/openjdk-ecj/build/linux-amd64/tmp/manifest.tmp /builder/builds/icedtea/openjdk-ecj/build/linux-amd64/tmp/rt-orig.jar \ `/bin/cat /builder/builds/icedtea/openjdk-ecj/build/linux-amd64/tmp/jarfilelists/rt_jar_list`) I have no idea why 0 is being used to suppress compression, given this is presumably the same build process Sun uses for the proprietary JDK. I'll take a look. -- Andrew :) From David.Herron at Sun.COM Fri Nov 21 20:16:44 2008 From: David.Herron at Sun.COM (David Herron @ Sun) Date: Fri, 21 Nov 2008 12:16:44 -0800 Subject: [fedora-java] openjdk's rt.jar In-Reply-To: <4926F9DC.4060201@redhat.com> References: <4926EAF6.9010500@cora.nwra.com> <4926ED54.4070000@redhat.com> <4926F9DC.4060201@redhat.com> Message-ID: <4927172C.8080000@sun.com> Andrew John Hughes wrote: > Andrew Haley wrote: >> Orion Poplawski wrote: >>> -rw-r--r-- 1 root root 54M 2008-09-08 13:39 >>> ./java-1.6.0-openjdk-1.6.0.0/jre/lib/rt.jar >>> -rw-r--r-- 1 root root 24M 2008-10-21 15:40 >>> ./java-1.6.0-sun-1.6.0.10/jre/lib/rt.jar >>> >>> Why so much bigger? >> >> I'd open them up and diff the trees. >> >> Andrew. > > Interesting. Assuming they both have similar contents, it could be > that the IcedTea builds enable debug info. > -- > Andrew :) We also appear to be using pack200 for packaging the .jar's and IIRC that strips out a bunch of stuff. Assuming that 1.6.0.10 rt.jar above came from a DLJ bundle, I just looked at the DLJ bundle and it's doing unpack200 ... and there are files whose name ends with '.pack' inside. - David From ahughes at redhat.com Mon Nov 24 14:31:18 2008 From: ahughes at redhat.com (Andrew John Hughes) Date: Mon, 24 Nov 2008 14:31:18 +0000 Subject: [fedora-java] openjdk's rt.jar In-Reply-To: <4927172C.8080000@sun.com> References: <4926EAF6.9010500@cora.nwra.com> <4926ED54.4070000@redhat.com> <4926F9DC.4060201@redhat.com> <4927172C.8080000@sun.com> Message-ID: <492ABAB6.5050606@redhat.com> David Herron @ Sun wrote: > Andrew John Hughes wrote: >> Andrew Haley wrote: >>> Orion Poplawski wrote: >>>> -rw-r--r-- 1 root root 54M 2008-09-08 13:39 >>>> ./java-1.6.0-openjdk-1.6.0.0/jre/lib/rt.jar >>>> -rw-r--r-- 1 root root 24M 2008-10-21 15:40 >>>> ./java-1.6.0-sun-1.6.0.10/jre/lib/rt.jar >>>> >>>> Why so much bigger? >>> >>> I'd open them up and diff the trees. >>> >>> Andrew. >> >> Interesting. Assuming they both have similar contents, it could be >> that the IcedTea builds enable debug info. >> -- >> Andrew :) > > We also appear to be using pack200 for packaging the .jar's and IIRC > that strips out a bunch of stuff. > > Assuming that 1.6.0.10 rt.jar above came from a DLJ bundle, I just > looked at the DLJ bundle and it's doing unpack200 ... and there are > files whose name ends with '.pack' inside. > > - David > But isn't this the same 'we' i.e. why isn't the OpenJDK build doing this? -- Andrew :) From David.Herron at Sun.COM Mon Nov 24 17:06:43 2008 From: David.Herron at Sun.COM (David Herron @ Sun) Date: Mon, 24 Nov 2008 09:06:43 -0800 Subject: [fedora-java] openjdk's rt.jar In-Reply-To: <492ABAB6.5050606@redhat.com> References: <4926EAF6.9010500@cora.nwra.com> <4926ED54.4070000@redhat.com> <4926F9DC.4060201@redhat.com> <4927172C.8080000@sun.com> <492ABAB6.5050606@redhat.com> Message-ID: <492ADF23.3070609@sun.com> Andrew John Hughes wrote: > David Herron @ Sun wrote: >> Andrew John Hughes wrote: >>> Andrew Haley wrote: >>>> Orion Poplawski wrote: >>>>> -rw-r--r-- 1 root root 54M 2008-09-08 13:39 >>>>> ./java-1.6.0-openjdk-1.6.0.0/jre/lib/rt.jar >>>>> -rw-r--r-- 1 root root 24M 2008-10-21 15:40 >>>>> ./java-1.6.0-sun-1.6.0.10/jre/lib/rt.jar >>>>> >>>>> Why so much bigger? >>>> >>>> I'd open them up and diff the trees. >>>> >>>> Andrew. >>> >>> Interesting. Assuming they both have similar contents, it could be >>> that the IcedTea builds enable debug info. >>> -- >>> Andrew :) >> >> We also appear to be using pack200 for packaging the .jar's and IIRC >> that strips out a bunch of stuff. >> >> Assuming that 1.6.0.10 rt.jar above came from a DLJ bundle, I just >> looked at the DLJ bundle and it's doing unpack200 ... and there are >> files whose name ends with '.pack' inside. >> >> - David >> > But isn't this the same 'we' i.e. why isn't the OpenJDK build doing this? > -- > Andrew :) > > -- > fedora-devel-java-list mailing list > fedora-devel-java-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-java-list Good question, I don't know. I just grepped through the source tree which will soon be posted as the openjdk6 tree and don't see any use of pack200. I found the makefiles that build pack200 but it doesn't appear to be used in an openjdk build. - David From ismael at olea.org Tue Nov 25 18:52:27 2008 From: ismael at olea.org (Ismael Olea) Date: Tue, 25 Nov 2008 19:52:27 +0100 Subject: [fedora-java] Problem with CLASSPATH Message-ID: <1227639147.17630.26.camel@lisergia.olea.org> Hi: First, I'm not a programer. I'm maintaining OmegaT and dependencies in Fedora, all java based. Since first moment I'm experiencing problems with the CLASSPATH. When removing it from the MANIFEST I can't get the jvm to find the dependencies, no matter I set them by the CLASSPATH variable or the -cp option. I'm supposing I'm doing (or not doing) something almost trivial. Anybody have any idea of what I'm doing wrong? Any document to read? Of course I've readed the Fedora Java package guidelines but doesn't helped me. Thanks in advance. -- A. Ismael Olea Gonz?lez http://olea.org/diario/ El mundo debe empezar a tener miedo a un planeta OLEA -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Esta parte del mensaje est? firmada digitalmente URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3242 bytes Desc: not available URL: From aph at redhat.com Wed Nov 26 11:39:04 2008 From: aph at redhat.com (Andrew Haley) Date: Wed, 26 Nov 2008 11:39:04 +0000 Subject: [fedora-java] Problem with CLASSPATH In-Reply-To: <1227639147.17630.26.camel@lisergia.olea.org> References: <1227639147.17630.26.camel@lisergia.olea.org> Message-ID: <492D3558.6040801@redhat.com> Ismael Olea wrote: > First, I'm not a programer. I'm maintaining OmegaT and dependencies in > Fedora, all java based. > > Since first moment I'm experiencing problems with the CLASSPATH. When > removing it from the MANIFEST I can't get the jvm to find the > dependencies, no matter I set them by the CLASSPATH variable or the -cp > option. > > I'm supposing I'm doing (or not doing) something almost trivial. Anybody > have any idea of what I'm doing wrong? Any document to read? > > Of course I've readed the Fedora Java package guidelines but doesn't > helped me. It's hard to say, because you haven't told us what you are doing, Does OmegaT have a startup script? If so, do something like this: LOCALCLASSPATH="$(/usr/bin/build-classpath jaxp_parser_impl xml-commons-apis)" java -classpath "$LOCALCLASSPATH" ... That's what the other Java startup scripts do. There are plenty of examples. Andrew. From ismael at olea.org Wed Nov 26 15:24:15 2008 From: ismael at olea.org (Ismael Olea) Date: Wed, 26 Nov 2008 16:24:15 +0100 Subject: [fedora-java] Problem with CLASSPATH In-Reply-To: <492D3558.6040801@redhat.com> References: <1227639147.17630.26.camel@lisergia.olea.org> <492D3558.6040801@redhat.com> Message-ID: <22a365930811260724s11c7270h9ef21f643a5514c4@mail.gmail.com> 2008/11/26 Andrew Haley > > It's hard to say, because you haven't told us what you are doing, > I know, but I prefered not to flood you with not relevant details. > Does OmegaT have a startup script? If so, do something like this: > of course. > > LOCALCLASSPATH="$(/usr/bin/build-classpath jaxp_parser_impl > xml-commons-apis)" > > java -classpath "$LOCALCLASSPATH" ... > I tried several combinations like this. And the results are exactly the same. That's what the other Java startup scripts do. There are plenty > of examples. > I know, and I have been investigating a lot by my own. That's way I feel puzzled. I tested with openjdk and sunjdk with same results too. It's a lot weird. The example: [olea at lisergia ~]$ /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/bin/java -cp /usr/share/java/vldocking-2.1.4.jar -jar /usr/share/java/OmegaT.jar 53063: Info: =================================================================== 53063: Info: OmegaT - 2.0.0 (Wed Nov 26 16:16:43 CET 2008) Locale es_ES Exception in thread "main" java.lang.NoClassDefFoundError: com/vlsolutions/swing/docking/DockingDesktop at org.omegat.Main.main(Unknown Source) Caused by: java.lang.ClassNotFoundException: com.vlsolutions.swing.docking.DockingDesktop at java.net.URLClassLoader$1.run(URLClassLoader.java:217) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:205) at java.lang.ClassLoader.loadClass(ClassLoader.java:323) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294) at java.lang.ClassLoader.loadClass(ClassLoader.java:268) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:336) ... 1 more As you can imagine there are more dependencies but the first error is always for vldocking... which is really in the path!! Attached is the output with the -verbose flag. Of course compilation is always succesful, since the build.xml contens the beautiful line: But I think this doesn't affect the runtime linking... Any suggestion, please? -- Ismael Olea http://olea.org/diario/ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: omegat.log Type: application/octet-stream Size: 56732 bytes Desc: not available URL: From mefoster at gmail.com Wed Nov 26 16:20:39 2008 From: mefoster at gmail.com (Mary Ellen Foster) Date: Wed, 26 Nov 2008 17:20:39 +0100 Subject: [fedora-java] Problem with CLASSPATH In-Reply-To: <22a365930811260724s11c7270h9ef21f643a5514c4@mail.gmail.com> References: <1227639147.17630.26.camel@lisergia.olea.org> <492D3558.6040801@redhat.com> <22a365930811260724s11c7270h9ef21f643a5514c4@mail.gmail.com> Message-ID: 2008/11/26 Ismael Olea : > [olea at lisergia ~]$ /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/bin/java -cp > /usr/share/java/vldocking-2.1.4.jar -jar /usr/share/java/OmegaT.jar If you're executing a jar file (as above) then the "-cp" argument is ignored entirely. You should put the OmegaT jar on the classpath as well and give the name of the main class in the script instead. I think executing jars is actually officially discouraged in Fedora even ... MEF -- Mary Ellen Foster -- http://homepages.inf.ed.ac.uk/mef/ Informatik 6: Robotics and Embedded Systems, Technische Universit?t M?nchen and ICCS, School of Informatics, University of Edinburgh From ismael at olea.org Wed Nov 26 17:49:45 2008 From: ismael at olea.org (Ismael Olea) Date: Wed, 26 Nov 2008 18:49:45 +0100 Subject: [fedora-java] Problem with CLASSPATH In-Reply-To: References: <1227639147.17630.26.camel@lisergia.olea.org> <492D3558.6040801@redhat.com> <22a365930811260724s11c7270h9ef21f643a5514c4@mail.gmail.com> Message-ID: <22a365930811260949o6d117190ic3be1b2a10f8cf1d@mail.gmail.com> Thanks very much! After reading your email I've mimic the bsh launch script and now the thing is working as expected. Thans! 2008/11/26 Mary Ellen Foster > 2008/11/26 Ismael Olea : > > [olea at lisergia ~]$ /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/bin/java > -cp > > /usr/share/java/vldocking-2.1.4.jar -jar /usr/share/java/OmegaT.jar > > If you're executing a jar file (as above) then the "-cp" argument is > ignored entirely. You should put the OmegaT jar on the classpath as > well and give the name of the main class in the script instead. I > think executing jars is actually officially discouraged in Fedora even > ... > > MEF > > -- > Mary Ellen Foster -- http://homepages.inf.ed.ac.uk/mef/ > Informatik 6: Robotics and Embedded Systems, Technische Universit?t M?nchen > and ICCS, School of Informatics, University of Edinburgh > > -- > fedora-devel-java-list mailing list > fedora-devel-java-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-java-list > -- Ismael Olea http://olea.org/diario/ -------------- next part -------------- An HTML attachment was scrubbed... URL: