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@xxxxxxx >http://lists.gnu.org/mailman/listinfo/classpath > > >
