avalon-framework and doclet classes
by Anthony Green
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
17 years, 11 months
Release Notes
by Anthony Green
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
18 years
Many dependencies for eclipse-cdt
by Orion Poplawski
Are all of these really necessary?
Dependencies Resolved
=============================================================================
Package Arch Version Repository Size
=============================================================================
Installing:
eclipse-cdt i386 1:3.0.0_fc-1.FC4 CoRA
12 M
Installing for dependencies:
ant-javamail i386 1.6.2-3jpp_8fc CoRA 21 k
cryptix noarch 3.2.0-4jpp_1fc CoRA 395 k
cryptix-asn1 noarch 20011119-4jpp_1fc CoRA
180 k
eclipse-platform i386 1:3.1.1-1jpp_1fc.FC4.4 CoRA
38 M
eclipse-rcp i386 1:3.1.1-1jpp_1fc.FC4.4 CoRA
41 k
jakarta-commons-dbcp noarch 1.2.1-3jpp_1fc CoRA 108 k
jakarta-commons-el i386 1.0-2jpp_3fc CoRA 319 k
jakarta-commons-fileupload noarch 1:1.0-3jpp_1fc CoRA
24 k
jakarta-commons-launcher noarch 0.9-3jpp_1fc CoRA
42 k
jakarta-commons-pool noarch 1.2-2jpp_1fc CoRA 46 k
lucene i386 1.4.3-1jpp_3fc CoRA 795 k
lucene-demo i386 1.4.3-1jpp_3fc CoRA 130 k
puretls noarch 0.9-0.b4.1jpp_2fc CoRA
140 k
tomcat5 i386 5.0.30-5jpp_6fc CoRA 3.5 M
tomcat5-jasper i386 5.0.30-5jpp_6fc CoRA 970 k
tomcat5-servlet-2.4-api i386 5.0.30-5jpp_6fc CoRA
353 k
xerces-j2 i386 2.6.2-4jpp_5fc CoRA 2.2 M
--
Orion Poplawski
System Administrator 303-415-9701 x222
Colorado Research Associates/NWRA FAX: 303-415-9702
3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com
18 years
missing rebuild-gcj-db and aot-compile-rpm scripts
by Thomas Fitzsimmons
Hi,
People using Rawhide java-1.4.2-gcj-compat will have noticed that
rebuild-gcj-db and aot-compile-rpm get deleted when upgrading from <=
1.4.2.0-40jpp_51rh to >= 1.4.2.0-40jpp_52rh. This was caused by a bug
in "update-alternatives --install" where it would remove filenames that
no longer appeared in the alternatives database:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173685
Bill Nottingham has built into Rawhide chkconfig-1.3.24-1, which I
confirmed fixes the bug. In the meantime you can work around the
problem by --force reinstalling java-1.4.2-gcj-compat >=
1.4.2.0-40jpp_52rh and java-1.4.2-gcj-compat-devel >= 1.4.2.0-40jpp_52rh
from your yum cache.
Tom
18 years
Fedora Core 5 Wishlist
by Thomas Fitzsimmons
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
>
18 years
Native Eclipse 3.1 doesn't start
by Dominik Łeszyk
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
18 years
gij and Eclipse CVS checkout finalization
by Andrew Overholt
Hi Andrew and others,
I spent a lot of time a few months ago working on $subj. After many dead
ends, I decided it was more prudent to spend my time working on other
issues. I have now returned to this issue and would like to pass it off to
those who will have more luck than I did figuring out what is going wrong.
Background information:
~~~~~~~~~~~~~~~~~~~~~~
RH Bug #161483 [1]
CVS checkouts in Eclipse take an extremely long time to finish when run
under gij. The issue occurs both when the relevant jars are
natively-compiled and when they are not (although the problem is
exacerbated when run with only bytecode). I have found a few modules that
replicate the issue but the one I have used the most is GNU Classpath. The
problem is independent of network issues as checkouts from a local CVS
server exhibit the same behaviour.
Things to note:
~~~~~~~~~~~~~~
The problem appears to be related to some sort of thread contention. I
wrote a headless Eclipse CVS client (using the same code as the GUI CVS
client) that does not reproduce the problem. Following the actual checkout
of the files from CVS, Eclipse creates synchronization information for the
files it has just checked out. Since this is an initial checkout, all
folders are considered dirty so it descends into each folder. One of my
original theories was that we were incorrectly computing dirty resources
(or getting into some sort of recursive loop) but this is not the case.
Much println'ing has told me that both gcj and the Sun JVM come up with the
same list of dirty folders.
Timing information that I have accumulated has shown that we are not
spending an inordinate amount of time generating or writing the
synchronization information but are instead spending too much time holding
locks on the resources. On average we are holding the locks about 100 -
1000 times longer than the Sun JVM. This can be verified by a sysprof [2]
sample [3] taken which shows a lot of time in Semaphore.acquire().
OProfile results corroborate this evidence.
gnuplot was used at one point to see if the time spent was proportional to
the number of files in the directory or to the disk space of said files.
No correlation was observed.
Note: at one point, I thought the problem was due to missing .sos for some
jars because I could not duplicate the problem on my laptop. It turns out
that if I changed the CVS compression level [4], I could somehow affect the
timing such that it would indeed occur. Hyperthreaded machines seems
impervious to this.
There appears to be no way to reduce this to a test case so we are
unfortunately left with duplicating the symptoms using Eclipse itself.
How to duplicate:
~~~~~~~~~~~~~~~~
I have created a version of Anthony's excellent redhat-eclipse-demo RPM
that contains a snapshot of GNU Classpath (from a while ago). This RPM
will create a local pserver CVS server running on port 2402. It will also
create the user anoncvs and put an exploded GNU Classpath checkout (owned
by this user) in /var/lib/eclipse-demo-cvsroot. You can retrieve a copy of
this RPM here:
http://overholt.ca/redhat-eclipse-demo-2.0-1.noarch.rpm
http://overholt.ca/redhat-eclipse-demo-2.0-1.src.rpm
1. Install Eclipse from either FC4 or rawhide. gcc versions do not seem to
affect this problem and I've done most of my testing with 4.0.2-3 which was
current in rawhide until recently.
2. Fire up Eclipse with a new workspace ... something like:
eclipse -data ~/testcvsissueworkspace
3. Checkout classpath from your local CVS server:
File->Import->Checkout Projects from CVS
Next
localhost, /var/lib/eclipse-demo-cvsroot
anoncvs, anoncvs
pserver, 2402, check 'Save password'
Next
classpath
Finish
4. Observe that checkout hangs at final synchronization
I am at a bit of a loss as to how to proceed. Any and all help is greatly
appreciated. I will provide whatever information is necessary. (I wrote
this email while on a plane and lost a bit of revision I had done just
before my battery died. If anything's amiss, I blame that ;)
Thank you,
Andrew
[1]
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=161483
[2]
http://www.daimi.au.dk/~sandmann/sysprof/
[3]
http://overholt.ca/eclipse/checkout.sysprof
[4]
Window->Preferences->Team->CVS->Connection->Compression
18 years
gcj-dbtool --rebuild
by Thomas Fitzsimmons
Hi,
Here's what "gcj-dbtool --rebuild" needs to do:
Merge all db files in "$prefix/lib/gcj-$gcc_version/classmap.db.d/" into
"$prefix/lib/gcj-$gcc_version/classmap.db".
Even better for FC5 would be eliminating the need for individual .db
files altogether. We could have "gcj-dbtool --rebuild" compare the .sos
in /usr/lib with the database contents and add/remove any new/missing
entries to/from classmap.db. Shipping a .db file per package is one
divergence from JPackage spec files that Fernando's proposal doesn't
address but that an improved gcj-dbtool would.
Tom
18 years
Enhanced aot-compile script
by Fernando Nasser
Hi,
I was thinking of having a 'aot-compile' command that would perform all tasks
related to aot compilation.
For instance:
aot-compile
by itself would perform the additional compilation steps necessary to generate
the .so files etc., as currently done.
aot-compile --rebuilddb
would do the rebuild-gcj-db thing
aot-compile --install <install arguments>
would allow a conditional installation step
and so forth.
In addition to that, 'aot-compile' would either work or be a no-op, depending on
certain conditions, like the presence of GCJ in the system, and/or some
system-wide or local override configuration mechanism.
This way, aot-compile statements can be added to an RPM spec file and that same
spec file can be used to build bytecode or pre-compiled RPMs, depending on the
settings. Adding just this script to jpackage-utils would allow us to eliminate
differences between the spec files upstream and in other distros, except for
having to remove the "BuildArch: noarch" line.
It seems that there are a few cases to consider:
1) gcj is not installed ==> automatic ==> do not precompile
2) gcj is installed, but we don't want to pre-compile ==> override with either
system or local config (we could test for "BuildArch: noarch"...) ==> do not
precompile
3) gcj is installed, and we want to pre-compile ==> automatic ==> precompile
There are perhaps some other conditions, like you want to build the bytecode
with another Java and then use gcj to pre-compile...
IMPORTANT: please note that aot-compile should not be tied to GCJ, but instead
be a characteristic of any Java that is capable of pre-compilation. QUESTION:
how to accommodate the differences in pre-compilation mechanisms? In any case,
we should try and keep the command names generic so if necessary one day the
JVMs that are AOT-capable can provide alternatives for those.
Regards to all,
Fernando
18 years
GNU Classpath hacker room at FOSDEM 2006
by Mark Wielaard
Hi all,
Like the last couple of years we want to come together with all the
projects around GNU Classpath and the various free runtimes, compiler
and tool projects to discuss what has happened in the last year in the
Free Software community and what the next year will bring us during
FOSDEM.
The 6th edition of FOSDEM (Free and Opensource Software Developers'
European Meeting) will take place on February 25+26 2006 in Brussels
(Belgium), at the Solbosch Campus of the ULB (Free University of
Brussels). FOSDEM is a free and non-commercial event for the community
and organized by the community. See http://www.fosdem.org/
We were thinking of the following setup:
- Saturday from 13:00 to 17:30 - "End-User talks" presentations to
promote what we all build together to a wider audience that might have
heard of what we do, but haven't actually seen it in action/put
together. We might also want to have a "lightning" hour with lots of
quick Demos of applications running on a completely free stack (5 - 10
minutes per demo).
- Sunday from 09:00 to 12:30 - "Developer talks" presentations of things
that are in progress and that people want to explain in more depth to
get developers of the other projects to join in a share the fun.
- Sunday from 13:00 to 17:30 - "The Future" hard core interactive
technical hacker discussions on how to integrate the projects more and
move forward in the next year.
Arnaud Vandyck, Dalibor Topic, Mark Wielaard, Michael Koch and and Tom
Tromey will be our "program committee" this year. If you would like to
present something, have an idea for a demo or discussion topic please
let us know at fosdem-at-developer.classpath.org Please mention the
title, a little abstract, which track and whether you want to do a quick
demo, a short 30 min talk or full hour talk (we prefer 30 minute talks
to give everybody a chance to present something). Deadline for proposals
is December 18, so you have a month to think of something cool. Then we
make sure to have some kind of "formal program" at the start of January.
Examples of presentations and reports from previous years:
http://www.gnu.org/software/classpath/events/escape_fosdem05.html
http://www.gnu.org/software/classpath/events/fosdem04.html
Some ideas for interesting topics:
- Free Swing - The Demo!
- Your GNU/Linux distro and the free runtimes - package overview.
- From 0 to 100 in 15 Minutes: Getting started with GNU Classpath
development using Eclipse, JamVM, Mauve, and the ChangeLog plugin!
- Integrating with Objectweb through native-(gcj)-JOnAS
- Writing OpenOffice.org plugins using a free software stack.
- Using GNU Classpath/gcj/kaffe for games
- Using free runtimes on Wine and other win32 environments
- Embedding GNU Classpath in web browsers and support for JNLP
- Security Auditing!
- 1.5 language support in GNU Classpath, gcjx and the free runtimes
- GNU Classpath/OSGi/J2ME/Library splitting and trimming
- Harmony through interfacing.
- Beyond JAPI: what is needed to "really finish" GNU Classpath
Or, "Beyond Java" -- what we can do when we finish 1.5.
Or more generally some kind of presentation about development
metrics: bug rates, rates of change in japi/lines of code/tests,
email volume, stuff like that.
- Debugging, JDWP development efforts.
- etc.
Hope to see you in Brussels on February 25 and 26 2006,
Arnaud, Dalibor, Mark, Michael and Tom
--
Escape the Java Trap with GNU Classpath!
http://www.gnu.org/philosophy/java-trap.html
Join the community at http://planet.classpath.org/
18 years