Moses DeJong wrote:
>
> I still do not get it. The problem is not with the name of the init
> method (japhar works if it is called initializeSystemClass or <init>)
> but it crashes when calling the native methods that japhar does not
> define.
Lemme explain. the initializeSystemClass we can deal with just fine.
it's written in java. the problem is that there are different
classes.zip files floating around and we don't work with some of them.
1.1.5 was what we started working with, and that's the one we've
maintained compatibility with.
The fact that setIn0/Out0Err0 are not present is what the
initializeSystemClass check is trying to *tell* you. We (the japhar
hackers) know that we don't have these native methods. We have deduced
that classes.zip files that expect these native methods also have the
initializeSystemClass method, so we warn you.
> What about these methods? If they are not defined then how is one
> suppossed to change the value of System.in and System.out when
> they are defined and final? This can not be done in java code
> (which is why the Sun JDK does it in native code).
no, they can be -- they are in the classes.zip file I have. Just
because the JDK does it doesn't mean there's no other way to do it.
> I am no sun lover but I that does not change the fact that japhar
> crashes with every jdk classes.zip that I have tried (I have tried
> about 10 differnet JDKs from different verdors and they all break!).
look. i just downloaded a version of jdk1.1.6 (with the bad
java.lang.System) and tried:
CLASSPATH=jdk1.1.6/lib/classes.zip javap java.lang.System
and got no output at all. classes.zip files are tied quite inextricably
to the VM that they are shipped with. Since we *can't* ship a
classes.zip (soon... classpath... mmmmm) we're stuck with trying to hunt
down classes.zip files that we're compatible with. I really don't
relish the thought of trying to support every classes.zip file from
1.1.5 up to 1.1.7, with all of sun's various tweaks that they heap on
licensees.
there was the argument some time ago of having our java.lang.System
native methods encompass the native methods of all revisions of the JDK
System class that we've seen, but I don't like that idea. There may be
other incompatibilities, lurking in the shadows, and I'd much rather
have *one* thing to deal with than ten.
so, some people are going to be broken. that's just the way it goes
when we don't have control over everything that we need to make japhar
work. if we fixed your problem, we'd break others.
this explain things a bit more?
xtoph
