Salikh Zakirov wrote: > Geir Magnusson Jr wrote:
>> I'd like to see us figure out the hythr problem, since 898 is a hack to >> just work around what seems to be an important issue. can we grind this >> one out? > > A couple of words in defense of HARMONY-898. > The classlib doesn't depend on a particular hythr implementation. > In fact, it depends on hythr *interface*, which must be implemented > somewhere in the system. At the same time, classlib provides its > own hythr implementation. > > DRLVM itself reimplements the subset of hythr interface, thus making > possible interoperation with classlib, but doesn't uses classlib's hythr > implementation. > > So, this is not the case of "classlib wants hythr1, and drlvm wants hythr2, > and hythr1 and hythr2 conflicts". > In fact, this is "classlib wants some hythr, and provides hythr1. DLRVM > provides hythr2, and conflicts with hythr1". > > Thus, IMHO, the issue is not as important as it may seem, because there is no > issue on "who provides hythr", but there is an issue of competing hythr > implementations, > one of which comes with with DRLVM and works with it, and the other probably > works with J9 (I have never checked it myself). > This is darn important. We have two implementations of the same thing, and based on build order, we get differing results. Clearly, one implementation is *wrong*. Either : 0) Classlib implements hythread in entirety, and VM uses that. 1) Classlib implements hythread and maybe asks the VM to provide implementations for some stubs (like we do w/ kernel classes for the classlib) 2) Classlib depends entirely on the VM to provide. If there's a difference of opinion on how it should be implemented, or what functionality should be in there, lets have this out and sooner than later... geir --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
