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 05:31:16 GMT
For those interested, I've returned the j.u.c proposal code to its'
unmodified state and I've added a class stub for 'sun.misc.Unsafe' [1]. I've
attempted to javadoc it based on how the j.u.c code uses it, but this is
just a guess. Let the list know if there are any thoughts or comments on
what you see.

Note: the CopyOnWriteArraySet won't compile as it depends on the
CopyOnWriteArrayList class, which we don't have due to licensing. You can
get by this if you compile against a Java 5 JDK. I'll add a stub for this
class eventually. Additionally, the ConcurrentHashMap class has one small
syntax flaw that prevents it from properly compiling. Even though this code
is tagged as the final draft of JSR-166, it's obviously not the exact final
code that made it into the various Java 5 RIs. The syntax error is the same
one we discussed in another thread about the Map.putAll() method and the
Iterator<? extends Map.Entry<? extends K, ? extends V>> declaration.

-Nathan

[1]
http://svn.apache.org/viewvc/incubator/harmony/standard/sandbox/juc-proposal
/concurrent/src/main/java/sun/misc/Unsafe.java

> -----Original Message-----
> From: Geir Magnusson Jr [mailto:geir@pobox.com]
> Sent: Tuesday, July 18, 2006 11:35 PM
> To: harmony-dev@incubator.apache.org
> Subject: Re: [classlib][concurrent] java.util.concurrent module proposal
> 
> 
> 
> Nathan Beyer wrote:
> > 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.
> 
> Yes.  I assume it looks like your other support class, w/ a different
> class and package name.
> 
> >
> > Note, for the time being I'm sticking with the JSR166_PFD tag, so there
> may
> > be additions to this class in later commits.
> 
> Great.
> 
> geir
> 
> >
> > -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
> >
> >
> >
> 
> ---------------------------------------------------------------------
> 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