java-devel October 2005

java-devel@lists.fedoraproject.org

17 participants
17 discussions

avalon-framework and doclet classes
by Anthony Green 06 Jan '06

06 Jan '06

Gary - I was trying to build something recently that required org.apache.avalon.framework.logger.Log4JLogger from avalon-framework. The avalon-framework.jar file in FC4 appears to be missing this class. I grabbed the SRPM file from rawhide and attempted to build that instead. The build failed with this... [javadoc] java.lang.ClassNotFoundException: com.sun.tools.doclets.standard.Standard not found in gnu.gcj.runtime.SystemClassLoader{urls=[file:./,file:./], parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}} I've seen this before. It seems that our com-sun-javadoc or com-sun-tools-doclets-Taglet jar should be on the default classpath somehow. In any case, I noticed that this build of the jar file includes the proper class, but as far as I can tell, this is the same SRPM that was used in FC4. Why wouldn't the FC4 jar file contain the Log4JLogger class? Thanks! AG

4 9

Release Notes
by Anthony Green 28 Nov '05

28 Nov '05

The current "Java" content for the release notes (from FC4) are pretty slim. I'll quote them below with my comments and questions... > Fedora Core 4 users are advised not to use the Java RPM provided by > Sun. It contains Provides that conflict with names used in packages > provided as part of Fedora Core 4. Because of this, Sun Java might > disappear from an installed system during package upgrade operations. I assume this is still true. Does anybody have a pointer to the details? > Fedora Core 4 users should use either the RPM available from > http://www.jpackage.org/, or manually install the Sun Java tarball > into `/opt/`. I think we should discourage the /opt solution, since it doesn't integrate with out alternatives-based solution. Also, I thought there were problems with using the binary RPM from JPackage, and users _have_ to rebuild from the SRPM. Does anybody know about this? > Sun Java 1.5+ is recommended for stability purposes. Is this really true? What about IBM or BEA? Should we even be making specific recommendations here? Perhaps this is best avoided. Thanks, AG

6 6

Fedora Core 5 Wishlist
by Thomas Fitzsimmons 16 Nov '05

16 Nov '05

Hi, I tried to send this yesterday but there was a problem with the Fedora list servers. Tom -------- Forwarded Message -------- > From: Thomas Fitzsimmons <fitzsim(a)redhat.com> > To: fedora-devel-java-list(a)redhat.com > Subject: Fedora Core 5 Wishlist > Date: Tue, 13 Sep 2005 21:16:31 -0400 > > Hi, > > I've been thinking about my GCJ-related goals for Fedora Core 5, due out > February 2006. Here's a categorized list: > > java-gcj-compat > =============== > > - GNU Crypto fix for Eclipse extssh support: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=146782 > > Casey Marshall has already committed a Diffie-Hellman JCE provider to > GNU Classpath so this is just a matter of testing. > > - import all JAWT fixes: > > All the necessary patches are already in GNU Classpath and libgcj so > this is just a matter of testing that JOGL works properly on our > java-1.4.2-gcj-compat RPM. > > - Jessie merged into GNU Classpath > > - GNU Crypto core algorithms merged into GNU Classpath > > - gjdoc merged into GNU Classpath and thus ... > > - an --enable-javadocs option to libgcj > > - gcjx becomes java-gcj-compat's javac and javah commands: > > Not sure if this one is doable in time; I don't mean full gcjx, just > the bytecode-compiler portion of it split off into a standalone javac > executable. > > - include Tritonus or some sound implementation > > AWT > === > > - ImageMagick backend for ImageIO > > - Graphics/Imaging refactoring for GTK 2.8 and Cairo > > - MegaMek packages in Fedora Extras: > > http://megamek.sourceforge.net/ > > This just involves a few AWT bug fixes now. > > - fix all 1.5 japi issues in the java.awt.* packages > > - fix all 1.5 japi issues in the javax.imageio.* packages > > Swing > ===== > > - RHDB tools in Fedora Extras: > > http://sources.redhat.com/rhdb/administrator.html > > http://sources.redhat.com/rhdb/visualexplain.html > > http://sources.redhat.com/rhdb/controlcenter.html > > This will also require updating these tools to support PostgreSQL 8.0. > > - Limewire in Fedora Extras: > > http://www.limewire.org/ > > It would be absolutely awesome to have this Swing app working on the > free stack but I'm not sure it's doable in the FC5 time frame. Would > anyone like to undertake it? ;-) > > SWT > === > > - Azureus in Fedora Extras: > > http://azureus.sourceforge.net/ > > Again, not sure if this is doable before FC5 but this would be awesome > to have. > > gcjwebplugin > ============ > > - implement and test security features in GNU Classpath to allow running > untrusted bytecode > > It's very unlikely that this one will be finished before FC5 but I'd > like to at least have started the implementation by then. > > I'm hoping this list will inspire some volunteers, especially for the > big apps and GNU Classpath's security framework. Most of these items > are very doable and will greatly improve the free JPackage stack on > Fedora. > > Tom >

9 36

Native Eclipse 3.1 doesn't start
by Dominik Łeszyk 16 Nov '05

16 Nov '05

Hello, I'm really fresh to java-fedora stuff so maybe it's the reason for my problem: after compiling Eclipse 3.1 using the script from 'GNU Classpath Wiki' [1] I can't start it. There is an error log: !SESSION Tue Sep 13 13:36:30 GMT+02:00 2005 ------------------------------------ !ENTRY org.eclipse.core.launcher 4 0 2005-09-13 13:36:30.114 !MESSAGE Exception launching the Eclipse Platform: !STACK java.lang.ClassNotFoundException: org.eclipse.core.runtime.adaptor.EclipseStarter not found in org.eclipse.core.launcher.MainStartupClassLoader{urls= [file:/home/lechique/eclipse_test/./plugins/org.eclipse.osgi_3.1.0.jar.so], parent=null} at java.net.URLClassLoader.findClass(java.lang.String) (/usr/lib/libgcj.so.6.0.0) at java.lang.ClassLoader.loadClass(java.lang.String, boolean) (/usr/lib/libgcj.so.6.0.0) at java.lang.ClassLoader.loadClass(java.lang.String) (/usr/lib/libgcj.so.6.0.0) at org.eclipse.core.launcher.Main.invokeFramework(java.lang.String[], java.net.URL[]) (/home/lechique/eclipse_test/startup.jar.so) at org.eclipse.core.launcher.Main.basicRun(java.lang.String[]) (/home/lechique/eclipse_test/startup.jar.so) at org.eclipse.core.launcher.Main.run(java.lang.String[]) (/home/lechique/eclipse_test/startup.jar.so) at org.eclipse.core.launcher.Main.main(java.lang.String[]) (/home/lechique/eclipse_test/startup.jar.so) at gnu.java.lang.MainThread.call_main() (/usr/lib/libgcj.so.6.0.0) at gnu.java.lang.MainThread.run() (/usr/lib/libgcj.so.6.0.0) The compilation process went pretty smoothly (without any errors) and path for db file (gnu.gcj.precompiled.db.path) was set correctly. I don't understand but it seems that classloader doesn't see original jar libraries. Am I correct? What should I do? [1] http://developer.classpath.org/mediation/ClasspathShowcase Best Regards, Lechique Pozdrawia, Lechique -- "Mistakes are the portals of discovery" James Joyce

2 1

ecj problem and patch
by Anthony Green 29 Oct '05

29 Oct '05

As discussed on #fedora-java IRC (irc.freenode.net) The Eclipse batch compiler appears to place bootclasspath before classpath, making it impossible to override classes in libgcj.jar. This is a problem for jpackages wanting to use xml-commons-apis, which provides an alternate version of org.w3c.dom. I produced the following patch, which needs to be applied last in our set of Eclipse patches. Another snag I hit was that the FC4 Eclipse SRPM doesn't build anymore, since the archived make files reference an outdated version of mozilla. swttmp/build.sh should probably contain something like this instead of hardcoded values: GECKO_INCLUDES=`pkg-config mozilla-gtkmozembed --cflags` GECKO_LIBS='pkg-config mozilla-gtkmozembed --libs` But I see that patching this isn't simple because build.sh is extracted from a .zip file at build time. Hopefully overholt has a good idea for fixing this. While eclipse didn't build - it did build enough to give me a jdtcore.jar file I could manually install (after generating jdtcore.jar.so by hand). My tests of the patched compiler indicate that this is a step closer to the right solution. Can we get this into FC4 and rawhide? AG

4 5

Latest OO.o requires java-1.4.2-gcj-compat?
by Ian Pilcher 28 Oct '05

28 Oct '05

The latest openoffice.org update has brought back this requirement. Why? -- ======================================================================== Ian Pilcher i.pilcher(a)comcast.net ========================================================================

2 1

Non-native Eclipse 3.1 builds - now what?
by Ian Pilcher 28 Oct '05

28 Oct '05

Starting with the Eclipse 3.1 SRPM in Rawhide, I've managed to build "non-native" packages on Fedora Core 4. I had to work around the following issues: * nspr-devel vs. mozilla-nspr-devel: Since nspr-devel (in Rawhide) provides mozilla-nspr-devel, I changed the BuildRequires to mozilla-nspr-devel. The location of the header files also changes, so I modified eclipse-libswt-mozilla.patch to look in both /usr/include/nspr4 and /usr/include/mozilla-1.7.10/nspr. * Location of libjawt.so: The SWT build script seems to have the IBM JDK file layout hardcoded in its build scripts. I've bugzilla'ed this at https://bugs.eclipse.org/bugs/show_bug.cgi?id=110199. For now, I'm inclined to simply BuildRequire an IBM JDK for non-native builds. Any thoughts on exactly what I should require and how I should set JAVA_HOME would be appreciated. * Non-native builds are not noarch. I set the ExclusiveArch's for non-native builds to %{ix86} x86_64 ppc ppc64 ia64, which are the architectures supported by Eclipse itself. The real question is what next? It would be nice if the resulting SPEC file could be used for both Fedora Core (4 and devel) and JPackage. How should I go about "conditionalizing" things? Note BTW, that changing the package VERSION to 3.1.0_fc is pretty nasty. Can this be moved to the RELEASE? Thanks! -- ======================================================================== Ian Pilcher i.pilcher(a)comcast.net ========================================================================

2 3

Re: Fedora Core 4 Test Update: eclipse-3.1.1-1jpp_1fc.FC4.1
by Andrew Overholt 24 Oct '05

24 Oct '05

* Andrew Overholt <overholt(a)redhat.com> [2005-10-24 17:18]: > --------------------------------------------------------------------- > Fedora Test Update Notification > FEDORA-2005-1017 > 2005-10-24 > --------------------------------------------------------------------- > > Product : Fedora Core 4 > Name : eclipse > Version : 3.1.1 > Release : 1jpp_1fc.FC4.1 > Summary : An open, extensible IDE > Description : > The Eclipse Platform is designed for building integrated development > environments (IDEs) that can be used to create applications as diverse > as web sites, embedded Java(tm) programs, C++ programs, and Enterprise > JavaBeans(tm). > > --------------------------------------------------------------------- > Update Information: > > This is a release of Eclipse 3.1.1 natively-compiled for > FC4. I had been holding off on releasing this, hoping that > we could fix > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=161483 > first, but that looks unlikely at the moment. Since that > bug does not affect all users (and there are some > workarounds for those cases), I'm going ahead with this release. > > Please test and comment on the bugs listed. Sorry, these are the potentially fixed bugs: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=159564 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=161518 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=161635 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=162383 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=162443 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=163079 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=164095 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=165204 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=165330 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=167548 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168040 Thanks, Andrew

1 0

Re: [fedora-java] batik [Fwd: Re: com.sun.image.*]
by Brion Vibber 24 Oct '05

24 Oct '05

Anthony Green wrote: > If anybody is interested in running batik on our free stack, here's some > info on what needs doing... Has anybody been working on this? We'd be interested in using Batik to rasterize SVG content for Wikipedia, and as we have a bit of a free software fetish it would be nice to make sure it can run under GCJ. (Currently we're using librsvg, which is not totally satisfactory as there are some things it doesn't render too well.) If nobody's working on it, I might pick it up sometime in the next while depending on how hard it looks. :) -- brion vibber (brion @ pobox.com / brion @ wikimedia.org) > --- Begin Message --- > From: Thomas DeWeese <Thomas DeWeese Kodak com> > To: batik-dev xmlgraphics apache org > Subject: Re: com.sun.image.* > Date: Wed, 24 Aug 2005 20:05:34 -0400 > Hi Anthony, > > Anthony Green wrote: > > > batik 1.6 (as packaged by jpackage.org) builds nicely on the Fedora > > Core 4 Linux distribution with a fully Free and Open Source java stack > > (gcj, the Eclipse compiler, etc), with the exception of a few classes > > using com.sun.image.codec.jpeg.*. > > > > The com.sun.image.code.jpeg.* classes aren't part of the standard java > > platform, and there are no Free or Open Source implementations of the > > classes available for us to use. Can similar functionality be achieved > > through the use of core classes, like ImageIO? > > I would imagine so. There are some potential issues with the > handling of colorspaces but my understanding is that imageio > tends to be more complete in general. > > > If so, are there any plans for such a migration? > > The basic problem is that javax.imageio is only available in > JDK 1.4 and higher. Currently Batik target's 1.3 and higher. > However we recently created a source tree for JDK 1.4 specific > classes (only compiled for JDK 1.4 of course). So it might be > possible to add to the current support with this. > > > Getting batik to build with free software solutions opens the door to > > including it, and applications that depend on it, in fully free Linux > > distributions, like Fedora and Debian. > > Any help from the these communities would be very welcome!

3 8

JOnAS 4.3.3 on gcj: test results
by Andrew Haley 22 Oct '05

22 Oct '05

I fixed a few testsuite and gcj bugs and re-ran the conformance tests on jonas-4.3.3-1jpp_13fc. We're up to 94.39%. Results here: http://people.redhat.com/~aph/current-jonas-on-gcj-conformance-test-results… Not that you won't be able to do this until the bug fixes for the testsuite go in to rawhide. The main cause for concern seems to be org.objectweb.jonas.jtests.clients.jms, almost all of which fail. I'm not sure what is going on there. Andrew.

3 5

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

java-devel October 2005