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.
Note, for the time being I'm sticking with the JSR166_PFD tag, so there may be additions to this class in later commits. -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]
