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 <[EMAIL PROTECTED]>
> 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
