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.
P.S.: thanks for posting the pointer to JDK 1.2 Thread
information. It is a perfect example for what I am
heading at: what's the point in having java.lang.Thread
specified if they have to deprecate most of the API in
the next minor revision. ISO my proverbial....
