Andrey Chernyshev wrote:
> On 5/18/06, Oliver Deakin <[EMAIL PROTECTED]> wrote:
>> Andrey Chernyshev wrote:
>> >> We would not want to couple the classlib to a particular VM
>> however. So
>> >> far I have been thinking
>> >> about the HDK from a classlib perspective, without considering
the VM
>> >> used. I imagined that any
>> >> developer who used a classlib HDK would just grab a VM snapshot
>> (or the
>> >> IBM VME) and overlay
>> >> that onto the classlib HDK in the same way we overlay the VME onto
>> >> deploy now.
>> >
>> > Well, may be I'm missing some simple points here, but...
>> > Is there any specific reason not to bundle a "Harmony VM" (let's
>> > forget about DRLVM for now) into the HDK? Is this just a matter of
>> > choice between SableVM, drlvm, e.t.c.?
>> > I just thought it could be convenient for developers (as well as
for
>> > Harmony users) to take a complete workable JRE without an
additional
>> > need to combine something together.
>>
>> I agree it would be useful to have a complete jre available, but I
>> wasn't sure
>> how we would pick the VM to use when we potentially have 3/4 VMs
>> (if DRLVM is accepted, and once the classlib adapter is completed)
>> capable of
>> running with Harmony classlib.
>
> As for the DRLVM, it doesn't actually require any specific adapter for
> Harmony class libraries except a small patch for MsgHelp and
> URLClassLoader patch which is already included with JIRA-438.
>
> One additional patch would be required to make it workable with the
> most recent classlib version (at the time we preparing DRLVM, we were
> just using classlib version taken at March 13). This isn't big as well
> - just rename MsgHelp and former com.ibm.oti.vm.VM.java to the right
> locations, and then update a bunch of building files to accommodate
> the recent API contributions and migrate to 1.5 compiler. I can add
> this to JIRA as well, but, I just thought it may make sense to see if
> the DRLVM is accepted first.
>
>>
>> Perhaps we could just produce a jre for each VM once they are up and
>> working?
>
> Yes, I think this could be the choice, if we don't select some
> "default" one.
>
>> I just thought that if we had separate classlib and a VM jre's which
>> both contained
>> a predefined and matching directory structure, then the step of
>> unpacking them
>> into the same directory to get them working is fairly
straightforward.
>
> That should work as well, at least for class libs. Actually I was
> thinking of HDK containing the pre-compiled binaries for all modules,
> not just the ones from the class libraries. VM developers would
> probably want to be able to work on a single module as well, for ex.
> JIT or GC. They wouldn't want to compile, for example, log4cxx or APR
> each time they want to build VM, these binaries are also worth to be
> the part of HDK.
>
> Either it would result into a separate HDK's containing VM and
> classlib modules, or we just can combine everything within a single
> HDK (which seems to me just simpler).
I personally prefer the idea of separate HDKs for VMs and classlib,
although
I dont feel strongly about it - it just makes the most sense to me.
If someone wants to work exclusively on, say, classlib, they probably
won't
want to have to download extra hdk libraries for all of the VMs.
In the case where someone works on both the Classlib and a VM (or
more than one VM) if the HDKs have a uniform structure then they
need only download the Classlib HDK and the VM HDK of their
choice and unpack them in the same place.
Eventually I imagine us having HDK, JDK and JRE bundles for
the Classlib and each VM, and the developer/user can just pick and
mix as they wish from that selection.
Regards,
Oliver
>
> Thanks,
> Andrey.
>
>
>>
>> Regards,
>> Oliver
>>
>> >
>> > Thank you,
>> > Andrey Chernyshev
>> > Intel Middleware Products Division
>> >
>> > On 5/18/06, Oliver Deakin <[EMAIL PROTECTED]> wrote:
>> >>
>> >>
>> >> Mark Hindess wrote:
>> >> > On 18 May 2006 at 14:36, "Alexey Petrenko"
>> >> <[EMAIL PROTECTED]>
>> >> > wrote:
>> >> >
>> >> >> 2006/5/18, Mark Hindess <[EMAIL PROTECTED]>:
>> >> >>
>> >> >>> I was assuming that the HDK for the classlib would not contain
>> >> >>> any VM specific artifacts. If it did, which VM artifacts
would
>> >> >>> it contain SableVM, drlvm, etc. or all of them? (Of
course, the
>> >> >>> classlib hdk will contain the VM stubs that the classlib build
>> uses
>> >> >>> today.)
>> >> >>>
>> >> >> But we need to run the classlib on some machine.
>> >> >>
>> >> >
>> >> > Of course.
>> >> >
>> >>
>> >> We would not want to couple the classlib to a particular VM
>> however. So
>> >> far I have been thinking
>> >> about the HDK from a classlib perspective, without considering
the VM
>> >> used. I imagined that any
>> >> developer who used a classlib HDK would just grab a VM snapshot
>> (or the
>> >> IBM VME) and overlay
>> >> that onto the classlib HDK in the same way we overlay the VME onto
>> >> deploy now.
>> >>
>> >> I suggested in the "Supporting working on a single module?" thread
>> >> (sorry, no link - it's not in the
>> >> archives yet) that a Harmony VM could produce releases in a jre or
>> jdk
>> >> layout. This
>> >> would allow a Classlib developer to grab an HDK and overlay the VM
>> jre
>> >> bundle onto it,
>> >> but at the same time an actual Harmony runtime user could grab a
>> >> classlib jdk/jre snapshot and
>> >> combine it with the same VM.
>> >>
>> >> Regards,
>> >> Oliver
>> >>
>> >> --
>> >> Oliver Deakin
>> >> IBM United Kingdom Limited
>> >>
>> >>
>> >>
---------------------------------------------------------------------
>> >> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> >> To unsubscribe, e-mail:
[EMAIL PROTECTED]
>> >> For additional commands, e-mail:
>> [EMAIL PROTECTED]
>> >>
>> >>
>> >
>> >
---------------------------------------------------------------------
>> > Terms of use : http://incubator.apache.org/harmony/mailing.html
>> > To unsubscribe, e-mail:
[EMAIL PROTECTED]
>> > For additional commands, e-mail:
[EMAIL PROTECTED]
>> >
>> >
>>
>> --
>> Oliver Deakin
>> IBM United Kingdom Limited
>>
>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail:
[EMAIL PROTECTED]
>>
>>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
Oliver Deakin
IBM United Kingdom Limited
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
