> -----Original Message-----
> From: Bernd Kreimeier [mailto:[EMAIL PROTECTED]]
> Sent: Friday, August 14, 1998 7:34 AM
> To: Classpath
> Subject: RE: java.lang checkin ...
>
>
> John Keiser writes:
> > It is literally impossible for all of our classes to work
> with Sun's
> > JDK *unless* we make our implementation identical, mimicking
> private and
> > package-protected methods and behavior, even down to the point
> of making
> > sure declare private class fields in the same order as Sun's. I am
> > unwilling to do that, myself. It is limiting and it is
> probably skirting
> > the boundaries of law.
>
> Personally, I would like to add a (maybe pointless)
> comment that IMO there is no point in trying to catch
> up with Sun's API inflation, much less try to interoperate
> with it, be it inside or outside the JDK. Classes like Object,
> Class, String are sure essential. But I would go as far as
> stating that (most of) e.g. Runtime, System, are not
> necessarily in that essential (sub)set. Why not keep
> classes as standalone and separated as possible.
>
> There is the VM specification. Then there is a Java
> language specification - a Java which is translated
> to VM instructions/bytecodes - but this is not
> necessarily the only language to target the very
> same VM. VM and Java language as such require certain
> classes. Others have just been written into the Java
> specs. So what.
>
> I am not only talking about java.util, I am talking about
> Thread and java.net, too. I am talking about AWT. Not to
> mention javax.* or sun.*.
>
> I'd rather have a good VM and a matching good implementation
> of the really essential core classes, plus a decent JNI,
> and am on my own with everything else. If that means loosing
> conveniences for the time being, fine with me. If that means
> loosing a lot of Sun's ever changing APIs along the way, fine.
> Making the essentials interoperate with whatever frantic
> additions come next is just not worth it. IMO and all.
>
> There is a difference between a LGPL'ed Japhar and a
> trademarked Sun JDK - decent C source freely available
> is pretty portable, too. More portable than the JDK
> for the last 3 years, it seems.
>
> Replacement for classes.zip? Not necessarily. A skeleton
> Classpath for VM-dependend (essential) classes? That would
> be great. Minimal dependencies between all the classes'
> protected or native implementations (if any), essential
> or not? That would indeed be perfect.
>
>
> b.
>
Just so you know, the method I'm proposing right now won't even work with
Sun's VM. A number of other classes have to be stripped away. Probably
won't even work then; Sun provides too many native methods.
So:
1. Replacement for classes.zip: problematic and probably not worth the
effort, if indeed it is possible, which it appears not to be without
violating copyright laws.
2. Skeleton for Classpath for VM classes: allows binary compatibility, easy
porting, VM independence for most stuff.
3. Minimal dependencies: built in to Classpath no matter what method we use.
We're not trying hard to add dependencies here.
