Geir Magnusson Jr wrote: > Archie Cobbs wrote: <snip> >> Compare Classlib's Thread.java: >> >> trunk/modules/kernel/src/main/java/java/lang/Thread.java >> >> with these files from Classpath: >> >> http://cvs.savannah.gnu.org/viewcvs/classpath/java/lang/Thread.java?rev=1.17&root=classpath&view=markup >> >> http://cvs.savannah.gnu.org/viewcvs/classpath/vm/reference/java/lang/VMThread.java?rev=1.9&root=classpath&view=markup >> >> >> Note every method in Classlib's Thread.java is: "return null". On the >> other >> hand, Classpath's API is much more complete and fully developed, >> race conditions have been analyzed and handled, SecurityManager >> implications >> have been taken into account, etc. To get Classlib to the same level, >> you'd have to duplicate a whole bunch of (at times very tricky and >> subtle) >> work -- not only implementing the API, but figuring out what the right >> API >> is -- that's already been figured out over several years in Classpath. > > Ok, I'm not sure what you are referring to. I know that our VM API is > production tested on a certified, complete stack. I'm not sure where > Classpath has been used in anger yet. > >> >> In short there is lots of unimplemented stuff remaining in Classlib's >> existing API. From a simple argument of expediency, not to mention the >> benefits for debugging previously mentioned, adopting the "already baked" >> Classpath API makes lots of sense. > > We might be missing information from IBM on this. Tim?
Not sure what information you are expecting. Caveat: I've deliberately not studied the Classpath VM interface code, so my understanding is limited. As Archie points out, the Harmony classlib code has a 'higher-level' VM interface than Classpath. Taking his Thread example, in classlib the VM implementor shows up with a full Thread implementation, and AIUI in Classpath they are required to implement a VMThread type and can reuse common code in Classpath's Thread. That's fine, and if Weldon or anyone else wants to create a version of Thread that is implemented in terms of the same VMThread interface then I say 'go for it'. (If Classpath were to dual license their code that would be even better!) A while ago there was a discussion about the pro's and con's of splitting Thread into common and VM-specific sections at all, even before trying to agree on what goes where. We can go through that again if people like. IMHO, saying 'show up with a working Thread' kinda sidesteps that discussion, and people can implement it as they see fit. I have no problem with growing the classlib KERNEL stubs to have code that VMs may choose to reuse. For example, you can imagine providing a Java-based impl of TLS that some VMs would just want to use (or the String.intern() as another example); but without imposing it on all VMs that may choose to implement TLS|whatever as they see fit. So to close the loop -- I'm happy to share info, just not sure what you want. If you want to know how IBM's VME implemented Thread then I can take you down to a certain level at which point it becomes so VM-specific that I'm not convinced it would help anyone. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
