Re: Classpath and java.util.concurrent
Hi Tom, On Tue, 2006-01-24 at 11:15 -0700, Tom Tromey wrote: > One idea would be to check it in on a pristine branch (like cvs > import, but we probably don't want to use that in this case) and then > merge it over the generics branch and clean it up there. > > I would suggest putting the code in external/, e.g., external/jsr166. > > I think it would make sense to import it and get it on the branch > before hooking it into the build. That way, fixing it up to work in > Classpath won't have to be a solo effort. > > Comments? Seems like a nice plan. But please put down precisely how/where the "pristine branch" comes from and how you sanitize it to only include the public domain bits from the jsr166 group. Then we sent that description to FSF-legal and to Doug so we have a clear record where the original source comes from. And we should probably also send it to Doug so the jsr166 group knows how their users/downstream depend on their work (it is probably a similar process the backport project goes through http://www.mathcs.emory.edu/dcl/util/backport-util-concurrent/). It would also be good to then have a simple way/description of how to get a diff between this pristine branch and what what we will have in external/jsr166 so it is easy to forward any patches upstream again. Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://developer.classpath.org/mailman/listinfo/classpath
Re: Classpath and java.util.concurrent
Oh, really great! We can just mark the problems you describe with TODO or something like that for beginning. Audrius Tom Tromey wrote: Most of the reference implementation of java.util.concurrent is in the public domain. I took a quick look at it last night. I thought I'd post the results here and see what people think. The public domain bits are about 30 KLOC, mostly in java.util.concurrent. I had to delete a couple of Sun-derived classes, which we'd have to replace. This didn't look to be a big problem, mostly it was a class derived from ArrayList. It relies on a few 1.5 APIs that we don't have yet... no big deal. The code uses generics. It calls into a sun.* class for unsafe low-level operations. This we could refactor to a classpath-style VM class. There are a couple of other sun.* dependencies which can be handled similarly. The code from the upstream cvs repository already has all the 1.6 additions in the source. I think we probably should remove this. Managing imports here looks like a pain. We'd like the latest code, to pick up bug fixes, but IMO we want to avoid the 1.6 additions until 1.6 is really released. We also want to refactor parts of the code a little to avoid Sun-isms. One idea would be to check it in on a pristine branch (like cvs import, but we probably don't want to use that in this case) and then merge it over the generics branch and clean it up there. I would suggest putting the code in external/, e.g., external/jsr166. I think it would make sense to import it and get it on the branch before hooking it into the build. That way, fixing it up to work in Classpath won't have to be a solo effort. Comments? Tom ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath ___ Classpath mailing list Classpath@gnu.org http://developer.classpath.org/mailman/listinfo/classpath
Classpath and java.util.concurrent
Most of the reference implementation of java.util.concurrent is in the public domain. I took a quick look at it last night. I thought I'd post the results here and see what people think. The public domain bits are about 30 KLOC, mostly in java.util.concurrent. I had to delete a couple of Sun-derived classes, which we'd have to replace. This didn't look to be a big problem, mostly it was a class derived from ArrayList. It relies on a few 1.5 APIs that we don't have yet... no big deal. The code uses generics. It calls into a sun.* class for unsafe low-level operations. This we could refactor to a classpath-style VM class. There are a couple of other sun.* dependencies which can be handled similarly. The code from the upstream cvs repository already has all the 1.6 additions in the source. I think we probably should remove this. Managing imports here looks like a pain. We'd like the latest code, to pick up bug fixes, but IMO we want to avoid the 1.6 additions until 1.6 is really released. We also want to refactor parts of the code a little to avoid Sun-isms. One idea would be to check it in on a pristine branch (like cvs import, but we probably don't want to use that in this case) and then merge it over the generics branch and clean it up there. I would suggest putting the code in external/, e.g., external/jsr166. I think it would make sense to import it and get it on the branch before hooking it into the build. That way, fixing it up to work in Classpath won't have to be a solo effort. Comments? Tom ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
