Re: New ideas

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Dan" == Dan Walter <d2walter@oakland.edu> writes:

Dan> It would be nice if there was a flag in jcf-dump that would cause
Dan> it to write the stack and local variable states before each
Dan> instruction using the verify.c code.

I think that would be a fair amount of work, since it would mean
pulling a bunch of tree manipulation code into jcf-dump.  It might be
easier to modify gcj itself so that you could give an extra flag to
`gcj --syntax-only' to dump the info.

Dan> I saw the reason why we cannot just use the sun class libraries.
Dan> It seems that maybe only the classes in the java.lang package are
Dan> heavily integrated with the Java VM.  I think that it may be
Dan> possible to use the gcj java.lang package with the rest of the
Dan> sun class library.  It appears that the native functions that are
Dan> in other packages like AWT may be in separate libraries that
Dan> could be linked into gcj projects

Does your license from Sun allow you to do this?  As I recall (I
haven't read the license recently), there is a clause prohibiting you
from replacing or extending any part of java.*.

Dan> Because of the high integration between the java.lang package and
Dan> the Java VM, I think it may be better if the GNU Classpath did
Dan> not contain a java.lang package and assumed anyone implementing a
Dan> Java VM would create their own.  This may make having multiple
Dan> GNU Java VM projects using Classpath easier.

Big chunks of java.lang are VM-independent.  So Classpath already does
what you suggest, but in a more minimal way.  There are just a few
classes that really need VM support.  libgcj doesn't fully use the
Classpath approach at present.  Someday it will be very close though.

Tom