harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mikhail Loenko" <mloe...@gmail.com>
Subject Re: [classlib][concurrent] Integrating into builds and snapshot
Date Thu, 24 May 2007 03:45:35 GMT
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
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?


[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 <nbeyer@kc.rr.com>:
> 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

View raw message