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]
