On Fri, 30 Oct 1998, Chris Toshok wrote:
> 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.
Ok, the error message made me think that the problem was related to
the name of the init method and not what it did.
> > 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.
Could you ship a patch file that converts a bad (that means Sun) dist
over to a good dist? I am currently using a modified System.java source
file that I recompiled and put into my own classes.zip. Do you think
a script that does is worth the time. Would it just be better to wait
for the Classpath project classes to get merged into the CVS?
> 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.
I did not mean to restart an old argument.
> 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.
Thats cool, I already fixed my problem. I just thought that other folks
might have been as confused as me so that might want to hear what I did
to work around it.
> this explain things a bit more?
>
> xtoph
>
later
Mo DeJong
dejong at cs.umn.edu
