Mark Benvenuto wrote:
> We will need to go through the differences. Probably, go package by
> package and hand off the tasks to maintainers and volunteers. The classes
> will have to be evaluated on many levels such as cleaness, effciency, and
> speed.
As far as speed and efficiency is concerned, after a brief look through some of
the java.util classes I think there isn't really going to be much in it.
Classpath makes some optimizations in places that libgcj doesn't, and
vice-versa. The same is probably true for bugs. Thanks to the API being well
specified (and thus the implementations being fairly similar in most places) we
have the luxury of being able to evaluate performance and correctness on a
side-by-side, method-by-method basis. This will be easier than trying to come up
with benchmarks that try test the performance of an entire class and trying to
make decisions based on that. Of course in the java.util case we would tend to
lean towards the classpath code since it implements 1.2 stuff, but directly
comparing the code will still be a worthwhile excercise.
One issue I'd like to raise is that of coding style. A nice feature of libgcj is
that the code is written fairly consistently, where as classpath varies widely
between classes and packages that were written by different authors. Although
there is no official GNU coding standard for Java, libgcj is written according
to what we think such a standard would look like if it existed.
Should classpath's (and libgcj's?) code should be reformatted to adhere to a
common style? This could, of course, be easily done using code-formatting tools,
and in most cases the changes would be relatively minor. I do think that it
would be a significant advantage to achieve some level of consistency before any
serious merging work begins. What are the opinions of the classpath developers
on this?
Also, I notice that many parts of classpath are documented with javadoc-style
comments while other parts (and libgcj) leave them out or just have minimal
comments. The Java APIs are already extensively documented from a variety of
sources, so it can be argued that such API documentation is redundant.
Personally I think that large comments make the code a bit harder to read and
maintain, but I guess that modern editors can be configured to hide javadoc
comments so that perhaps isn't a real issue. It is also good to have a free (as
in speech) documentation set. Anyway, this is another style difference between
the libgcj and some of the classpath code.
> there for the most part as far as I can tell. Some java.text and
> java.util is there also. java.security is almost non existent along with
> java.sql, java.rmi, java.applet, and java.beans. libgcj's java.awt is in
> a partially implemented state.
I think java.util is a prime candidate for merging/integration in the near
future. There isn't much native code to deal with, and gcj would benefit greatly
from the addition of Collections.
> Also, if to get started on merging the projects some guidelines should be
> setup. Where to get libgcj, what compiler to get if you want to test
> integration of things, etc. I am also curious can their compiler compile
> Classpath?
gcj cannot yet compile classpath from source code, because it cannot handle
inner or anonymous classes. Work on these and other "JDK-1.1" features is in
progress. In the mean time, gcj should be able to compile most of classpath with
the aid of an intermediate bytecode compiler (ie Jikes).
This means that either:
1. We need to change classpath code that use anonymous classes (eg some of the
Collections Iterators) in order to integrate it with gcj.
2. We need to wait until gcj supports the required 1.1 features at the source
level.
3. We need to modify the libgcj build process to use an intermediate bytecode
compiler.
Probibly 3 is the most attractive option, at least as an interim solution.
BTW - Will I need to sign another copyright assignment form in order to
contribute to classpath? I have already done an FSF one for gcc stuff, and a
Cygnus one for libgcj.
regards
[ bryce ]
