On Jun 3, 2005, at 7:18 AM, Peter Edworthy wrote:
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
makes sense, as these are completely dependant on information only
available to the JVM. ClassPath could implement these objects and then
have them call across to, say, jvm.implementation.* objects but
this adds
an extra level of indirection with no increase in flexibility of the
implementation.
Oops. I see that I wasn't clear. I didn't meant that the VM
shouldn't implement things from java.lang - it makes perfect sense
that we do so. What I was trying to say [sloppily] was that we
shouldn't extend java.lang w/ new classes or interfaces. Sorry.
The other java.lang.VM* objects I agree should really not be in
Java.lang.* but having references to these use an explicit ClassLoader
mitigates this into a cosmetic issue.
Yes
It seems to me that control of 'java.lang' and 'java.lang.*' would
be the simplest way to deal with issues of control of the
implementation
so that it is a Harmony implementation, not one from Sun, IBM, FSF,
Sourceforge.* or anyone else. From the Sun JDK 1.5.0 src.zip, there
are 49 distinct 'sun.*' imports in the 'java.lang' package, none of
which are found in this archive:
I wasn't aware that we were trying to restrict the possible
ClassLibs that
could be used. In an ideal world we would want to make switching
between
ClassPath and Jikes's implementations easy, encouraging the user to
use
the most efficient implementation. (see next email for suggestions
of mix
and match implementations).
yes, and it would be cool if we could concoct an adapter for Sun's
implementation as well for fun :)
Making the interfaces between VM and class library standard should be
something we do now, starting with GNU Classpath's interface, and
figuring out what else we might need based on experiences of others
<cough>IBM/Intel/BEA</cough> doing the same thing.
...snip...
By writing _only_ java.lang and java.lang.*,
we can truly speak of a separate implementation.
Adding only _parts_ of libraries like GNU ClassPath
would mean that users would implement Harmony library
policies, not Sun's, FSF's, or anybody elses.
This implemetation of java.lang and java.lang.*
is only 165 classes in 53K lines of code, not
including native code. Doable by this group
without a doubt.
Even better than that the ClassPath project has already done this.
As I
understand it, we are discussing methods of interfacing with the
ClassPath
project in such a way that;
other implementations can be plugged in with minimal coding,
changes to the Java API do not require changes to the JVM, only the
ClassLibs.
Well, two comments :
1) we clearly want to interface w/ GNU Classpath, but we want to
generalize thought whatever we can learn from others.
2) I don't know for sure, but guess that as time goes on and the Java
API evolves, it might require additions to the JVM/Classlib API
geir
Thanks,
Peter
--
Geir Magnusson Jr +1-203-665-6437
[EMAIL PROTECTED]
