Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: neutral (asf.osuosl.org: 64.74.244.71 is neither permitted nor
 denied by domain of geir@pobox.com)
Message-ID: <44BDB662.6010804@pobox.com>
Date: Wed, 19 Jul 2006 00:34:42 -0400
From: Geir Magnusson Jr <geir@pobox.com>
Reply-To: geir@pobox.com
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib][concurrent] java.util.concurrent module proposal
References: <001201c6aaea$cb490fb0$0f01a8c0@LITTLEGUY>
In-Reply-To: <001201c6aaea$cb490fb0$0f01a8c0@LITTLEGUY>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


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