This is the mail archive of the java-discuss@sourceware.cygnus.com mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: CHANGELOG and documentation



Matt wrote:
> Can I make a few suggestions that might help make the status of gcj
> development more obvious to newcomers?

Looking for votes?.... :-)

---- IMPORTANT ANNOUNCEMENT --------------------------------------------

Matt was recently nominated for a Slashdot beanie award in the "Best
Newbie Helper" category.  The award comes with a nice prize, so please
go and vote for him...

http://slashdot.org/article.pl?sid=00/01/18/0848209&mode=thread

------------------------------------------------------------------------

> First, I keep seeing references to various nice features of later versions of
> gcj, however, as someone doing ongoing development using gcj it's hard for
> me to track what's changing from release to release. Would it be possible
> to post the CHANGELOG for both the 2.95.1 branch and the snapshot branch
> somewhere on the website?

Have you seen:

http://sourceware.cygnus.com/cgi-bin/cvsweb.cgi/libgcj/libjava/ChangeLog?cvsroot=java&only_with_tag=HEAD

This will let you generate a nice diff of the ChangeLog between HEAD
and libgcj-2_95_1-release.

Maybe we could put a link to this in an obvious place.

I created a NEWS file a long time ago, but we don't maintain it.
We probably should.

> Another question I have is about gij. I tried unsuccessfully to use this
> a couple of months ago, and I remember it being significant work to get
> to the point where I had a gij-enabled build and test environment. At the
> time gij didn't appear to work at all; it would simply crash. 

There was period of time where GCC exception handling was badly broken
in the presence of shared libraries.  We eventually worked around it
in libgcj, and GCC has since been fixed.

The interpreter is now enabled out of the box for x86 Linux.  It
should work just fine.  In fact, when testing libgcj changes I often
find it faster to build/run my test code with

$ gcj -C test.java && gij test

> Although I've asked before, I'm still quite unclear on what gij does and
> how it works.

The gij program is just a driver around libgcj and actually does very
little.  I think you must really be wondering about the bytecode
class loader and interpreter.  These are part of libgcj.

> Does it impose a performance hit? 

One of the primary goals of the interpreter Kresten implemented was to
not impose a performance hit on compiled code.  The compiler assumes
that each method call is to compiled code.  When we load class files,
we create vtables on the fly and populate them with pointers to
dynamically generated thunks.  These thunks extract function arguments
from the right places and invoke the bytecode interpreter.  There's
additional hackery for calls to compiled code from the interpreter.
From the end-user's point of view this should all be invisible.

> Does it allow dynamic class loading? 

libgcj will dynamically load and interpret class files.  As of this
week, it will also dynamically load and execute natively compiled code
from shared libraries.  Class.forName() will try to load a series of
shared objects in order to find the requested class.  If a class
`gnu.quux.whatever' is requested, libgcj will first look for
`gnu-quux-whatever.so', then `gnu-quux.so', and finally `gnu.so'.

It's important to note that all of these features are available to
just about any gcj compiled program.  They are properties of libgcj,
not gij.

> Still, it would be nice to have a more comprehensive list of missing
> features from gcj and libgcj.

Yes.

> 	* Inner classes - only when compiling from source. Compiling inner
> 	  classes from bytecode works. [Is that true?]

This is true - although Alex is making good progress on compiling
inner classes from source.

>	* Reflection (java.lang.reflect.*). [Can someone elaborate?]

Reflection works, including invocation, under both x86 and PPC Linux.
Feedback from others is encouraged.  Tom has added reflection tests to
Mauve, and Joerg Brunsmann recently posted his experiences.

> 	* Object serialization (java.io.ObjectInputStream and 
> 	  java.io.ObjectOutputStream classes). There are several free
> 	  implementations of this which could be incorporated.

We're pretty much waiting for Stallman to bless the Classpath
licensing change and then we can incorporate Geoff Berry's
implementation.

> 	* Remote Method Invocation (RMI). A full RMI implemention relies
>	  upon reflection, serialization, as well as a set of other libraries.
>	  See FAQ section 2.6 for details.

Tim Wilkinson says that he has an RMI implementation (not derived from
NinjaRMI) that he will license under the GPL+exception and assign to
the FSF.

This is all good advice. 

Thanks,

AG

-- 
Anthony Green                                                        Red Hat
                                                       Sunnyvale, California

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]