> From: Petter Reinholdtsen [mailto:[EMAIL PROTECTED]]
>
> > I don't quite see a reason to make the changes myself, especially
> > since this variable is private.
>
> My motivation is that I want Japhar to work both with SUN JDK
> classes.zip and Classpath classes.zip, if possible without
> recompiling.
>
> As we will probably be unable to get SUN to change the source of JDK,
> we will have to change Classpath. :-)
Hmm, let's tackle that problem now.
You can use native state for Class, Thread, Field, Constructor and Method.
The only interoperability problems I can think of are libnative, Throwable,
and String.
libnative can be dealt with easily with a switch, or even auto-discovery of
whether it is Classpath or JDK classes.zip you're working with.
Throwable's only dependency is "message", and you really should just call
getMessage() for that--an extra method call here doesn't matter since it is
not a critical path item. Exceptions themselves are by definition
exceptional, and it is even rarer for an exception to reach the top-level
handler. In fact, that's what I'd like you to do, please, so that I can
change the fieldname back to message and retain the integrity of the private
fields.
This leaves only String. If we change fieldnames right now, it'll work
fine. But if we find some cool new (better) way to represent strings that
speeds them up even more, str, len and offset might not cut it. I think
String is one place we'll have to find some other way of working. I guess
the only thing to do there if you want runtime compatibility is to use
if(classpath_enabled) instead of #ifdef FOR_CLASSPATH.
--John Keiser
