SHUDO Kazuyuki wrote:
> Michael Emmel <[EMAIL PROTECTED]> wrote:
>
> > By splitting the JVM from the class libraries via a portable interface we gain
>a lot !
> > I think if development was split between multiple JVM's and a open robust class
>library
> > we could get competative support from comercial and Open Source vendors.
>
> Even Sun seems to make their class libraries
> (i.e. classes.zip) more portable by reducing native
> methods.
>
> One of evidences of that is in source code of the object
> serializer. In early JDKs, serialization routines for
> array of primitive types were native methods. But now
> those routines are entirely written in Java. I guess
> that the purpose of the rewrite was improvement of
> portability of the class library.
>
> If we decide to develop a JVM or a
> Java-to-another-language translator, we must implement
> native methods in a class library that we adopt. It is a
> very hard work.
That's part of the problem the class libraries extend the JVM via native code.
Thus the JVM in itself is not enough to run java.
In my opinion any native libraries should used should expose an well defined
java interface to the the native libraries along with a JNI style C interface.
I'm not the worlds best C programmer but Sun's JVM is not written in a portable manner
IMHO.
I think its important to move to a design which allows each part of the JDK to be
tested
as
and individual unit.
Each major subsystem should be individually certifiable.
Thus you should be able to certify a JVM the Porting layer api for the classes and you
class
library itself.
I think its funny that Sun has come up with this cool OO design and yet not be able to
certify each
module as meeting the specs.
Tons of C code is written every year with well defined dependencies and porting
requirements.
Mozilla has pretty decent api and there are many others.
X11 does a prety decent job in there sample server. Since Sun seems to be commited to
WORA meaning
Solaris and Windows its hard to move the JDK spec forward to give detailed subsystem
level
requirments.
I think that its crazy for Sun to think that by publishing a high level api theres any
chance
that clean romm implementation would be fully compatible on such a complex piece of
software.
Todays JVM implement JIT's and other dynamice compliation stratgies theres no reason
that the
JVM cannot optimze out C function lookup tables at runtime. The JVM should be capable
of
inlining C function calls and bypassing the function pointers once the tables are
intialized.
Optimizations should not and need not be limited to native code produced from byte
code.
Mike
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
