java-devel September 2005

java-devel@lists.fedoraproject.org

23 participants
20 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

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

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-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

gnome java-access-bridge, gcj and idlj
by Caolán McNamara 29 Sep '05

29 Sep '05

openoffice's accessibility solution for gnome is apparently to use the gnome java-access-bridge, is this possible to build with gcj ? ftp://ftp.gnome.org/pub/gnome/sources/java-access-bridge/1.4/ I gave a casual check and it requires "idlj" during it's build which doesn't seem to have a gcj eqivalent, or does it ? C.

2 1

eclipse wtp + tomcat5 couldn't work
by Sagi Ye 25 Sep '05

25 Sep '05

hello, Fedora core 4 installed and updated ( by yum ) to the most lated version. Apache & Tomcat is installed. http://localhost:8080 check is OK. The eclipse web tool (wtp 0.7) installed via eclipse's "software updates" feature. Now I failed to add the Tomcat server to eclipse's reach. In the "New Server Runtime" dialog, eclipse refused to accept "/usr/share/tomcat5" as the "Tomcat installation directory" where I checked do tomcat resides. I just wondered what are eclipse looking for and how it check for a valid server runtime. Or could it be cause that the installation of Tomcat differs in FC4 to other platforms? -- Sagi Ye <sagi.ye(a)gmail.com>

4 9

aot-compile-rpm improvements
by Gary Benson 21 Sep '05

21 Sep '05

I made some changes to aot-compile-rpm this past few days, with the result that it can now cope with jars within jars (required for ears, rars and some wars), incorrectly named classes (the other wars) and classes not in jarfiles at all. If your package contains such things you will find extra solibs and databases being built. This affects tomcat5 and jonas which I'm now rebuilding. When that's done they will have natively compiled applications. Cheers, Gary

2 2

Should non-native Eclipse be noarch?
by Ian Pilcher 20 Sep '05

20 Sep '05

I am trying to use the Rawhide SRPM to build non-native Eclipse 3.1 packages for FC4. (I am using the Java 1.5.0 RPMS from JPackage.) When building with gcj is disabled, this SPEC file sets the BuildArch to noarch. This causes the build to fail, because eclipse_arch gets set to i386 instead of ix86. I'm not sure what the correct fix is. Should a non-native Eclipse build *really* be noarch? There sure seems to be a lot of platform-specific stuff in there, and I note that JPackage's Eclipse 3.0.x packages are i586. So, I can either: * Set the BuildArch to i586 for non-native builds, or * Rework the SPEC file to set eclipse_arch to ix86 for non-native builds. Suggestions welcome. Thanks! -- ======================================================================== Ian Pilcher i.pilcher(a)comcast.net ========================================================================

3 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

java-devel September 2005