I'd like to bring this back. API signatures of that we use in Harmony (tag=JSR166_PFD), differ from what is in the RI, this causes JAPI diffs [1,2]
We may consider several options to fix that: 1. replace affected files by newer versions. That would mean that we will use minimal version sufficient to fix JAPI diffs 2. replace the whole j.u.c. with newer version: a) get some snapshot after all the Java5 changes are in and before Java6-related changes started to appear OR b) get snapshot at just before the first dependency on Java6 API appeared 3. take up-to-date version of all the files and manually replace those files that use Java6 API with their older versions Each of the options implies a risk that we will take some broken state, but what we have not in SVN has the same risk too Other considerations/options? Thanks, Mikhail [1] http://www.kaffe.org/~stuart/japi/htmlout/h-harmony-jdk15.html#pkg_java_util_concurrent [2] http://www.kaffe.org/~stuart/japi/htmlout/h-jdk15-harmony.html#pkg_java_util_concurrent 2006/8/21, Nathan Beyer <[EMAIL PROTECTED]>:
Now that we're getting some good submissions to make the java.util.concurrent code to work with DRLVM, I'd like make a proposal for getting the code in the Class Library and a part of our regular builds, tests and snapshots. From a technical/code integration standpoint, the go ahead assumption is that Harmony will have VMs implement a subset of the 'sun.misc.Unsafe' class, such that the concurrent code, most of which is in the public domain, from the Concurrency Interest Site [1] can be used as-is, as least to the greatest extent possible. Are there any major dissents to this? Now, the issue that's of most contention, at least from our past conversations, is the code management. First and foremost, we must consider the realities of the situation. 1. The concurrency interest group, the JSR-166 expert group, Doug Lea and others are NOT producing distributable builds, so we can not integrate the code like we do other components, like Xerces, Xalan, MX4J, etc. I don't want to speak for anyone here, so I'll qualify this by saying that I haven't been told this explicitly, so this is just my inference from discussions and documentation. If this is not the case, then someone please speak up. There is an experimental JAR on the site [1], but it's meant specifically to run with the Sun RI and it contains code outside of the java.util.concurrent package space. Additionally, the TCK tests from the site [1], which we'd like to use are not packaged in any way. 2. The code on the site [1] is only accessible through a ViewCVS Web interface. As such, it's not exactly easy to interact with in terms of created an automated checkout of the source to integrate into a build. One of my thoughts was using the svn:externals feature to download source dynamically, but there are additional issues that make that especially difficult; these issues follow. Besides that, I'm not sure that svn:externals works with arbitrary URLs that aren't SVN repositories. 3. There is at least one source file that MUST NOT be used from the site [1] because it's not open to the public domain, the CopyOnWriteArrayList [2]. This will require at least one class to be developed as part of the Harmony Class Library. 4. It's currently NOT feasible for Harmony to use the HEAD version of the code, as it has been updated to utilize several Java 6 APIs, which Harmony does not current provide, not even in stub form. Additionally, there is only one viable CVS tag (JSR166_PFD), but this tag is two years old and some of the code in it does not compile on current JLS3 compilers. This has been discussed on the mailing list previously; please search the archives if you're curious. As such, any checkouts out code that compiles would have to be done either using a date-based checkout (not really possible with ViewCVS) or a specific revision number for each file would have to be determined. Tactical Proposal (next 6 to 12 to ?? months) - My proposals for integration of the concurrency code is to retrieve the latest possible codebase from the site [1], which is open to the public domain and check it into our repository. * This code would include the TCK tests. * From a build standpoint, this code would be handled just like any other module. * As a general rule, this code would NOT be subject to normal code patches. The suggested process would be to submit patches and fixes to the concurrency interest group [1] and if/when the patches are accepted and committed, the code can synchronized to get the updates. Upon occasion (every few months), code updates can be take from the site [1], if deemed necessary and appropriate. * A minor issue is where the stub for the sun.misc.Unsafe class would be placed (for compiles); my suggestion would be to just make it part of the luni-kernel-stubs, but we can look at a concurrent-kernel-stubs JAR. Strategic Proposal - Once we have code working, at least in a snapshot state, we can attempt to do a number of this to ease the process and discrepancies. * Once a CopyOnWriteArrayList implementation is completed, we can submit it back to the concurrency group for inclusion. * Design and propose an alternate "Unsafe" service interface that can be submitted to the concurrency interest group for use by all VMs and Class Libraries. Unless there are any substantial objections, with practical and workable alternative solutions, I plan on moving forward with this approach next weekend. Thanks, -Nathan Beyer [1] http://gee.cs.oswego.edu/dl/concurrency-interest/ [2] http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concu rrent/CopyOnWriteArrayList.java?rev=HEAD&content-type=text/vnd.viewcvs-marku p
