what build problems do you have? Regards, Tim
Weldon Washburn wrote: > Tim, > Good points below. I have a first cut at a kernel_path/Thread.java > that glues Harmony Class Library to GNU Classpath compatible VM > (jchevm). I will post it as soon as I get it to compile. Then we > will have some code for a debate on what parts (if any) can be sucked > into the baseline kernel/Thread.java. I am currently having problems > getting the Class Library build system working. > - Weldon > > On 2/15/06, Tim Ellison <[EMAIL PROTECTED]> wrote: >> 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. >> > > > -- > Weldon Washburn > Intel Middleware Products Division > -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
