Ok, Tim. It seems like we are wasting our time on discussing this :) Let's back to this topic later. For now, let's commit this change to DRLVM specific classes, but place the TODO: comment in Classib's java.lang.Thread/ThreadLocal about things state.
Thanks, Aleksey. On Thu, Jun 26, 2008 at 11:01 AM, Tim Ellison <[EMAIL PROTECTED]> wrote: > Aleksey Shipilev wrote: >> >> On Wed, Jun 25, 2008 at 5:00 PM, Tim Ellison <[EMAIL PROTECTED]> >> wrote: >>> >>> Aleksey Shipilev wrote: >>>> >>>> Can't IBM VM extend its j.l.Thread correspondingly? >>>> Can't IBM VM copy current ThreadLocal implementation to _its_ kernel >>>> classes? >>> >>> Yes, but I'm guessing that you don't want to wait for the next release of >>> the IBM VME before accepting this patch. >> >> I'm afraid that the change would be lost if we adopt such >> "DRLVM-specific" solution. > > I disagree, there are already DRLVM-specific classes, and nothing is 'lost' > they are all in the same repository for everyone to see. > > VMs are always permitted to have their own specific implementation of a > class. > >> We are trying to get IBM VM to run on unmodified classlib code, right? > > No, we are trying to ensure that the DRLVM and IBM VM and other VMs continue > to work. If we are going to change the contract between the class library > and VMs then it should be a migration rather than 'break the world' change. > >> But if IBM VM is not flexible to afford the quick changes in core >> libraries, would it be better to wrap the not-yet-compatible code in >> classlib with some "porting glue" for legacy IBM VM version, but keep >> the code visible for other quick-to-change VMs? > > I'm open to concrete suggestions. > >>>> The thing is, I presume we have an example of backporting the good >>>> change from Android (?) back to Harmony. >>> >>> I'm not sure what you mean here. >> >> I'm a little speculating here. Judging on Bob's website I see that he >> is the developer of core libraries of Android, so I presume this >> change is already in Android code. Then if Android adopted and >> improved LUNI in classlib, we should backport the change back to LUNI >> in classlib :) > > I still don't see why this is relevant to the discussion. Anyone is welcome > to take the code and use it (under the license etc). > >>> Yes, it will get into the common classlib code. In the meantime there is >>> nothing to stop people getting the code from the DRLVM directory, like >>> they >>> do for Thread and all the other kernel classes. >> >> I'm afraid that no one VM developer would look in DRLVM's kernel >> classes while working on porting of Harmony classlib to its own VM. >> Leaving the things under the hood for IBM VM you also get the other >> VMs into the same situation: eventually moving ThreadLocal >> implementation to classlib will break their own VMs. I don't think >> that "other VM" developers should take this extra caution while >> porting. > > To turn it around, there are already VM implementers who have ported the > class library code to their VMs, and making this change will break them. > I'm suggesting a simple transition period ending up exactly as you suggest. > >> Summarizing all above: if the problem is IBM VM's inability to quickly >> react for changes - then the problem should be solved in IBM VM's >> specific way, not the DRLVM's one. > > It's not just the IBM VM, it's the VM interface. Let's keep things working > for everyone. > > Regards, > Tim > >
