Anyone interested in working on $subj? Since we're using the Eclipse
compiler as our bytecode compiler, the java stack is incomplete on
platforms on which we don't build Eclipse.
I don't know how easy this will be, but I'm hoping it's just a matter of
adding the required files (ie. duplicating the work of, say, ia64 for s390
and ppc64 for s390x) and adding sections where appropriate.
Ideally we'd contribute this work back upstream to the Eclipse Foundation,
but I think Ben Konrath mentioned something about doing that requiring
machines or builds or something? Ben, any comments on that?
I don't have any machines on which to test this work, and I'll do it myself
if no one is interested, but I thought I'd open the door if anyone wants to
give it a shot. We should probably have it ASAP so that our platform
coverage is complete.
Le lundi 14 mars 2005 à 16:09 +0000, Gary Benson a écrit :
> Before I jump in feet first, can I clarify what the ultimate goal is.
> As far as I see it, currently the command "build-classpath bcel" will
> print out "/usr/share/java/bcel.jar". You would like it to print out
> "/usr/share/java/regexp.jar:/usr/share/java/bcel.jar". Am I correct?
Ok, you asked it you'll get it;) CC-ing fedora-devel-java, Steve Cohen
(who also expressed some interest lately) and the common java packaging
list (since I do believe this is larger than JPackage alone and is
cojapas material at least).
The ultimate goal as you write is to generate a
classic /usr/share/java/regexp.jar:/usr/share/java/bcel.jar classpath
(or populate a directory with jar symlinks, those being the two main
ways an application creates its own classpath). A lot of people me
included feel you can't create classpathes like this from the jar files
alone, and you need additional metadata, probably in standalone files
like is already the case for various Unix systems. There is broad
agreement on what those files should contain.
A lesser number of people want these standalone files to be in XML. I'm
among this group, mainly because we will have to deal with windows users
at some point and I don't even want to deal with problems like CRLF in
I'll describe now broadly what I personally think these XML files
contents should be. The thing that converts these files to the
aforementioned path is left to your discretion. Like you rightly wrote,
once such an engine is written and proves the validity of the approach
it can be rewritten in other langages. The main thing is not to have to
rewrite all the description files all the times, and keep the output
stable so startup scripts do not need rewriting either.
1. a single XML file should describe one classpath unit provided by a
2. a classpath unit is most of the times a jar file or a set of jar
files. But it is not always the case : it can also contain stuff like
property files, xml files, even sometimes resources like sound files,
3. on some platforms all those files are lumped in a single per-app dir.
On others like Linux common conventions like the FHS mandate separation
of configuration and data parts
4. likewise on multi-user systems separate users must be able to
overload the configuration parts transparently
5. lastly while the configuration of an infrastructure is often
system-wide in scope, sometimes it's very useful to be able to overload
it on a per-app basis (a common example would be log4j - you don't want
all the apps in the system share the same log files, even if you want
them to share the log4j code)
6. therefore while a classpath unit descriptor should list the files
that compose it, exact file location should be left to separate policy
files (for example given a set of files search the jars
in /usr/share/java, the .properties in the same dir then ~/.java
then /etc/java, etc)
7. when a classpath unit is an implementation of a common java
infrastructure like jmx it should declare it
8. this means the possibility of simultaneous installations of several
implementations of the same thing on a given system exists. While some
objective factors like jvm compatibility (I'll get to this point later)
can be used to choose a particular implementations, sometimes you'll
just have several valid choices. It is probably very dangerous to let
classpath units self-declare their relative priorities (everyone would
want to be king). Therefore we need separate policy files that list
implementation priorities (probably distro specific, maybe overloadable
by the user, should list all known implementations to be effective and
the system then should choose between the implementations actually
9. a particular classpath unit must list all the other classpath units
it depends on. Some of them might be mandatory (won't work without them)
others might be opportunistic (use them if they're here, if not the app
will still work without them)
10. a particular classpath unit might use jni and require a particular
library to be in the app library path (now since we've already decided
to output a java classpath, I don't know if it's better to do such
resolution in a separate utility that takes a classpath in input and
outputs a LD_LIBRARY_PATH, if you use the same command to output one of
them depending on a CLI parameter or if you always output two lines, one
with the classpath the other with the LD_LIBRARY_PATH. And apps like
tomcat that want directories of jars are yet another problem)
11. a particular classpath unit might use some features of the java
langage only found on some java language versions and require the jvm to
12. a particular classpath unit might work with some jvms only - the
extreme case being in-jvm implementations that only work with a single
jvm (yes I think in-jvm libraries need to be covered by the xml
13 sometimes you may need to generate your classpath in separate bits
(for example an ant build.xml where some targets require additional jars
like junit - they'll need their path in pieces but the pieces must be
compatible with each other)
14 sometimes a classpath unit has a direct influence on some othe jvm
parameters like memory sizing
15 you need to handle classpath unit versionning- given the problem
scope managing version ranges is probably best.
16 lots of other considerations that are eluding me right now but will
come to light later. The main point is classpath building is _hard_,
this is largely hidden by the fact classpathes are by and large manually
written right now, but if we want to automate this we must remember it.
When writing a classpath builder you have to remember you may need to
add some rules later, so under-specifying is probably a bad idea.
Given all this the xml files I started working on looked like this :
<pathelem name="foo" version="a.b.c">
<config file="/usr/share/xml/foo/foo" ext="xml"/>
<config dir="/usr/share/foo-common" version="v.w.x"/>
<classes file="foo-contrib" ext="zip" version="d.e.f"/>
<classes libdir="/usr/share/foo/lib" version=""/>
<pathelem name="barB" version="d.e.f"/>
<pathelem name="barC" minver="d.e.f" maxver="x.y.z"/>
<jvm name="java-ibm" maxver="1.3.1"/>
<pathelem name="toto" version="x.y.y"/>
<pathelem name="bill" minver="e.r.t"/>
And this :
<!-- Java policy setup:
- paths to use in priority order
- virtual weights ?
The exact element hierarchy can be probably hammered on while writing
the actual implementation. As long as all the elements are present in
the files mass syntax changing can be handled by xslt later.
I hope I haven't disgusted you and you still want to work on the
problem. If you still have questions don't hesitate to ask. For now I'm
closing this post before writing a novel.
FYI, I checked in a patch to gcc that sets the default database for
gij. Once this is put in the gcc RPM, you won't need to set the .db
on the gij command line.
You can use "gcj-dbtool -p" in your spec file to get the name of the
Jakub, libgcj will build and install a default .db. However, I'm not
sure we really want to have this file owned by the gcc RPM. It is
going to be modified by other RPMs as they are installed... what is
the usual thing to do in this situation?
I noticed that installing the eclipse-* packages takes really long
(around 10 minutes on my laptop). Most of time is spent running gcj-
dbtool, doing lots of disk IO.
This seemed a bit unusual and after inspecting the gcj-dbtool sources, I
found out that in resizeMap(), a new PersistentByteMap is created for
each jar package that is added -- amounting to almost 150 several-MB
temporary files created. I don't think this was intentional.
The attached patch cuts my installation time for eclipse-platform from
7m17s to 1m35s. I've verified that eclipse.db is identical to the old
database, so hopefully the patch doesn't break anything.
With a little subversion.spec tweaking, I have the rawhide subversion
java bindings (svn-javahl.jar) and JNI library (libsvnjavahl-1.so)
building out of the box right now.
Nothing currently in FC depends on this library since the current spec
file disables it, but I think it makes sense to turn it on since the
Eclipse svn plugin uses it, as well various servlets people have
developed and are using.
It wants to install the jar file in /usr/lib/svn-javahl. Should we move
this to /usr/share/java? That seems like the right thing to do. I
suppose I can figure out the native build bits once I see how other
packages are managing it.
I've attached the changes for review...
I did another round of testing to see what additionally works or doesn't
in OOo2 with gcj from gcc4, and its big progress, which is most
excellent. I've enabled the new stuff which is working in OOo workspace
gcj3. There are a handful of remaining problems, various temporary
workaround patches and testcases where applicable at
1. ooo patched rhino fails to build with gcj
tar xvzf rhino15R4.tar.gz
patch -p3 < ../rhino1_5R4.patch
ant -Dbuild.compiler=gcj -f build.xml
[javac] int pos = viewToModel(new Point(popup.x, popup.y));
the scripting module also depends on this rhino module
submitted as rh#150772#. I bet this is trivial to fix.
2. complicated problem I don't understand in wizards component
submitted as rh#150650#
temp ooo side wizards.workaround.patch to get past registration
3. canvas module fails to compile
a missing "java.awt.Frame.createBufferStrategy" implementation ?
4. gcj's libjawt contains a reference to undefined
Thomas Fitzsimmons is taking care of it.
temp ooo side libjawt.workaround.patch to not checkdll bean for
gcj, this is a relatively trivial thing as well.
---- unimportant stuff ----
5. sandbox uses sun.applet.AppletAudioClip and other sun.foo classes,
not important, its really a deprecated module
6. sj2 uses some sandbox things so some parts cannot be built,
apparently this module is being cleaned up to remove some of this, again
ant and javac aren't currently using the natively-built Eclipse
We need to add something like the following to /usr/bin/ant in order to
pick up the .so files:
# diff -c /usr/bin/ant~ /usr/bin/ant
*** /usr/bin/ant~ 2005-03-05 13:13:05.000000000 -0800
--- /usr/bin/ant 2005-03-06 02:19:55.000000000 -0800
*** 230,235 ****
--- 230,236 ----
if $JAVACMD -version 2>&1 | grep -q "gcj"; then
if [ -f /usr/share/java/jdtcore.jar ]; then
+ ANT_OPTS="$ANT_OPTS -Dgnu.gcj.precompiled.db.path=/usr/lib/eclipse/eclipse.db"
(and something similar to java-gcj-compat's javac.in, see attached patch)
This will shave minutes off of the build times for some packages.
I forget what the plan is wrt the db. Maybe we'll have a global one.
In any case, this will do in the meanwhile.
(gbenson: could you please stick the above in apache-ant-javac-ecj.patch? This is
where we really need it - thanks!)
I'm the author of the BeeCrypt crypto library (already in Fedora, used
by RPM), and as previously announced at FOSDEM 2005 in the GNU Classpath
developer room, currently working on reviving a Java CSP which will use
BeeCrypt's native routines.
What I'm looking for is advice on the best approach to integrate
building a CSP jar file, deriving native interface headers from multiple
classes, followed by compiling a C shared library with the native code.
My tentative approach is using autoconf to figure out if either gcj/gcjh
or javac/javah is available, generate a build.xml file for Apache Ant. I
have this working for Sun's JDK. Support for gcj should be easier once
libgcj contains javax.crypto - is this planned for 4.0?
I see that tomcat5 is in rawhide now - thanks Gary!
I started it up, and saw the process running until I tried to view a
page, then the process died. Here are the contents
of /var/log/tomcat5/catalina.out. Any ideas?
JAVA VS. MICROSOFT .NET DEBATE RAGES
LAS VEGAS -- After describing Java as a stable technology with no great
surprises likely to come, Java experts during a conference panel session
fielded questions about the competitive power of Microsoft's rival .Net
IBM: ECLIPSE FACES CHALLENGES AHEAD
BURLINGAME, CALIF. - Eclipse will have to deal with its own success and
the challenges that success presents, said Lee Nackman, a CTO and vice
president at IBM Rational Software who was involved in founding the open
JAVA STAVING OFF .NET, SPRING FOUNDER SAYS
LAS VEGAS -- J2EE technology is in a very healthy state, staving off the
rival .Net platform and fostering innovation, said Rod Johnson, founder
of the open source Spring Framework for Java development, in a
presentation on Friday.
ECLIPSE CHIEF TALKS UP PROJECTS, AWAITS SUN AND MICROSOFT
The Eclipse Foundation for open source tools held its technical
conference, EclipseCon 2005, in Burlingame, Calif., the week of Feb. 28.
Stressing its momentum, the organization touted participation frrm
vendors such as BEA Systems, Borland Socqftware, Computer Associates
International, and Sybase. Mike Milinkovich, a former Oracle vice
president of technical services, became the first executive director of
the independent foundation when Eclipse was spun out of IBM last year.
InfoWorld Editor at Large Paul Krill discussed Eclipse goings-on and
impacts with Milinkovich.