harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan Lydick" <dlyd...@earthlink.net>
Subject Re: [arch] VM/Classlibrary interface
Date Fri, 03 Jun 2005 15:40:13 GMT

Peter,

Some good thinking here.  In your _next_ e-mail
you wrote,

> How clean are the separations between packages/groups of packages in
> ClassPath?
> i.e. how possible would it be to use say java.sql.* with another
> implementation of java.lang?

I think we are thinking along similar lines.
This is why I suggest doing 'java.lang' and
descendents.  Of all the packages in the
entire corpus of Java, this family of packages
is absolutely vital to the health and personality
of the machine.


In _this_ e-mail, you wrote,

> [Original Message]
> From: Peter Edworthy <peter@edworthy.org>
> To: <harmony-dev@incubator.apache.org>
 > Date: 6/3/05 5:18:47 AM
> Subject: Re: [arch] VM/Classlibrary interface
>
> Hello,
> 
> >> And you can circumvent the language protection (package private...)
> >> if you work hard enough too, I believe...
> >>
> >> Keeping out of "java.lang" seems wise if we can arrange it...
> I agree, but ClassPath has its interface classes in Java.lang and while we
> can and probably should implement these as an adapter level to our
> internal system abstraction I can see why the JVM providing
> 
> # java.lang.Class
> # java.lang.Runtime
> # java.lang.Thread
> # java.lang.reflect.Constructor
> # java.lang.reflect.Method
> # java.lang.reflect.Field

You might add to this list others the methods
that use native implementations because you
will have to implement them anyway, and probably
as native methods because, depending on the
JVM design, there may not be any other place
they can be implemented.  Here is the Sun
JDK 1.5.0 native method list for java.lang.*:


    java.lang.reflect.Array
    java.lang.reflect.Proxy

    java.lang.Class
    java.lang.ClassLoader
    java.lang.Compiler
    java.lang.Double
    java.lang.Float
    java.lang.Object
    java.lang.Package
    java.lang.ProcessEnvironment
    java.lang.ProcessImpl
    java.lang.Runtime
    java.lang.SecurityManager
    java.lang.Shutdown
    java.lang.StrictMath
    java.lang.String
    java.lang.System
    java.lang.Thread
    java.lang.Throwable

This list might vary from one implementation
to another and from one release to another,
but you get the idea.  There appear to be
a few differences from JDK 1.4.2 here.

> 
...snip...
> 


Dan Lydick




Mime
View raw message