build problems (was: Re: [jchevm] porting harmony classlib to JCHEVM)

[Tim Ellison <t....@gmail.com>]

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 <t....@gmail.com> 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 (t.p.ellison@gmail.com)
>> IBM Java technology centre, UK.
>>
> 
> 
> --
> Weldon Washburn
> Intel Middleware Products Division
> 

-- 

Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.