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. 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. > 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). > ...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. Thanks, Peter
