> From: Moses DeJong [mailto:[EMAIL PROTECTED]]
>
> On Fri, 30 Oct 1998, Chris Toshok wrote:
>
> > The initializeSystemClass method being present is just a good indicator
> > of a version of the classes.zip file that we cannot run with.
> >
> > The problem with sun's shoddy release practices is that this method
> > seems to pop up in newer releases of the JDK from sun (and it's various
> > licensees). There really is *no* reason for this method -- it should be
> > handled in the static initializer. sorta strange that the method exists
> > at all.
> >
> > There are two sources of the jdk that are know to work:
> >
> > - JDK 1.1.5v7 for Linux glibc from Blackdown
>
> I downloaded that and it uses the same native methods.
>
Odd. I use that and it works for me just fine.
> > -
> > ftp://ftp.freebsd.org/pub/FreeBSD/packages/All/jdk1.1.6.V98-8-14.tar.gz
>
> This file did not exist. There was a file called jdk-1.1.6.tgz but
> it also used the undefined (in japhar) native methods.
>
> > are you sure you grabbed the 1.1.5v7 linux version?
> >
> > > My question is how does japhar handle setting of the
> System.in, System.out,
> > > and System.err if it is not going to do it the same way as
> the sun JDK?
> >
> > we do do it the same way as the JDK. it's just that different revisions
> > of the JDK (and different releases of the same revision - whee, isn't
> > java WONDERFUL!?) do it differently. and, since sun's license doesn't
> > let us release the classes.zip file along with japhar, we have this
> > mess.
>
> 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.
>
> (signature of the Methods in java.lang.System)
>
> private static native void setIn0(InputStream in);
> private static native void setOut0(PrintStream out);
> private static native void setErr0(PrintStream err);
>
> 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).
>
>
> (sig of the fields in System)
>
> public final static InputStream in;
> public final static PrintStream out;
> public final static PrintStream err;
It is possible to initialize a final field without resorting to native
stuff. Here is how we do it for this case in Classpath:
public static final InputStream in = new
FileInputStream(FileDescriptor.in);
public static final PrintStream out = new PrintStream(new
FileOutputStream(FileDescriptor.out));
public static final PrintStream err = new PrintStream(new
FileOutputStream(FileDescriptor.err));
setIn, setOut, and setErr of course have to be native methods, but that
doesn't mean they are always called at the very beginning. Perhaps for some
JDKs setIn(), setOut() and setErr() are not called at the beginning, and
that's why Japhar works with them. I don't know.
They are there as kludges, I think ... the fields were final but people
clamored to be able to change their values. They didn't want people
changing the fields directly. So they decided to provide a method and do
the change in native code. Very very bad practice, and they should be shot
for it. It means that JITs and optimizing interpreters have to make a
special case for System.in/out/err, when they probably try and inline final
fields and small final methods as much as they can for speed.
>
>
> >
> > don'tcha just love sun?
> >
> > xtoph
>
>
> 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!).
>
I forget ... were you running on Linux or something else? What is your
library path? Is there anything in it that could conflict? Are you certain
that setIn(), setOut() and setErr() are the ones that are messing Japhar up?
--John Keiser
