Nathan Beyer wrote: > I have a stubbed out version of "sun.misc.Unsafe" that I've built based on > what the j.u.c implementations uses. Is it safe for me to check this into > the /standard/sandbox/juc-proposal project? All I really have at the moment > is an empty class that allows the project to compile.
Yes. I assume it looks like your other support class, w/ a different class and package name. > > Note, for the time being I'm sticking with the JSR166_PFD tag, so there may > be additions to this class in later commits. Great. geir > > -Nathan > >> -----Original Message----- >> From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] >> Sent: Sunday, July 16, 2006 7:39 PM >> To: harmony-dev@incubator.apache.org >> Subject: Re: [classlib][concurrent] java.util.concurrent module proposal >> >> >> >> Nathan Beyer wrote: >>>> -----Original Message----- >>>> From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] >>> <snip/> >>>> First problem is that you included CopyOnWriteArrayList.java, which is >>>> *not* a file we can take, as it's (c) Sun and under some unknown >> license. >>>> I've deleted it from SVN. >>>> >>> Sorry, I completely overlooked that. >> Please be careful - I know it's difficult, but that's why we're so >> careful about bringing in foreign code. >> >>>>> Design - >>>>> >>>>> Most of the code is straight from Doug Lea and the JSR group. The only >>>> piece >>>>> I've added are the service interfaces that the VM must implement and >>>> I've >>>>> uplifted the original code, where necessary to utilize these VM >> service >>>>> interfaces. >>>> I don't know what you mean by "uplift" - I'm guessing you mean how you >>>> modified to not use sun.com.Unsafe? >>>> >>>> I'd like to avoid modifying any of this code, and just using as is, >>>> meaning for now we implement "sun.com.Unsafe" and whatever else, and >>>> then lobby Doug to change to something neutral. >>>> >>>> We might be able to get away with using the jar that is found on his >>>> website (assuming we can get him to produce one w/o Sun code, which >>>> isn't the case now), which would further drive the requirement that we >>>> use the code unmodified. >>> I'm fine with doing this, but I thought there might be a copyright issue >>> with using the 'sun.misc.Unsafe' class name. Additionally, the interface >>> would have to be reverse engineered from the source that uses it. There >>> isn't a stub of it in the ViewCVS repository that can be seen. Also, the >>> .class file is NOT included in any of the JARs on the site. Are we cool >> with >>> doing this? >>> >>> Note, just implementing 'sun.misc.Unsafe' may not be enough, as it seems >>> that some pieces of the code make assumptions about internals of other >>> classes. For example, LockSupport [1] retrieves the Field 'parkBlocker' >> from >>> java.lang.Thread, which is not part of the public contract. >> Well, we just modify Thread then? >> >>> If we just want to stick to a pure compilation route, then I think we >> would >>> likely have to get Doug, et al to adopt some VM agnostic APIs before we >> take >>> this code. >> I don't understand why. If we implement sun.misc.Unsafe and make the >> mod to Thread, what do we need to do to the code? >> >> [SNIP] >> >>>>> * There are a LOT of changes, fixes and enhancements to the code at >> Doug >>>>> Lea's site; consider what code we should additional take. >>>> Doug suggested we take HEAD, which would include changes for Mustang, >>>> but should be 100% compatible w/ Java 5. (And it doesn't really matter >>>> if we try and it's not true, as we aren't modifying any of his code, >>>> presumably.) >>>> >>> I'd prefer to take HEAD myself and the code only uses JLS3, but there >> are >>> dependencies on Java 6 APIs. For example, the ConcurrentHashMap uses the >> new >>> AbstractMap.SimpleEntry class [1]. Also, there are a number of >> references to >>> the new Arrays.copyXXX methods as well. Additionally, we talked about >> this a >>> few times and I came away with that we should try to use the latest Java >> 5 >>> tag [2][3][4]. Just as a reminder: there hasn't been a new tag since the >>> JSR166_PFD tag (over 2 years old), so it's either that or HEAD + Harmony >>> building some Java 6 APIs. Note, I'm perfectly fine with doing that as >> we'll >>> need to do it eventually. >> either one - seems like the simple route for now is the 166 tag used in >> Tiger, and then we circle back once this is in. Goal is to get Java 5 >> j.u.c... >> >> Again, thanks for doing this. Don't let this minor process debate over >> provenance distract you from this mighty feat! >> >> geir >> >> >> --------------------------------------------------------------------- >> 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] > > > --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
