harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nathan Beyer" <nbe...@kc.rr.com>
Subject RE: [classlib][concurrent] java.util.concurrent module proposal
Date Wed, 19 Jul 2006 04:21:23 GMT
I have a stubbed out version of "sun.misc.Unsafe" that I've built based on
what the j.u.c implementations uses. Is it safe for me to check this into
the /standard/sandbox/juc-proposal project? All I really have at the moment
is an empty class that allows the project to compile.

Note, for the time being I'm sticking with the JSR166_PFD tag, so there may
be additions to this class in later commits.

-Nathan

> -----Original Message-----
> From: Geir Magnusson Jr [mailto:geir@pobox.com]
> Sent: Sunday, July 16, 2006 7:39 PM
> To: harmony-dev@incubator.apache.org
> Subject: Re: [classlib][concurrent] java.util.concurrent module proposal
> 
> 
> 
> Nathan Beyer wrote:
> >> -----Original Message-----
> >> From: Geir Magnusson Jr [mailto:geir@pobox.com]
> > <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: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org


---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message