New ideas

Tue Nov 27 16:08:00 GMT 2001

>>>>> "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