Paul,
see http://blogs.sun.com/jjg/entry/building_javac_for_jdk7
If you want more details.
Rémi
On 12/20/2010 11:43 PM, Kelly O'Hair wrote:
Not sure about a policy, but yes typically we require the previous JDK
release to be
the "boot" jdk. However, the policy, if you want to call it that, has
Changeset: d2a0e795c1c2
Author:weijun
Date: 2010-12-21 17:35 +0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d2a0e795c1c2
6996367: improve HandshakeHash
Reviewed-by: xuelei
! src/share/classes/sun/security/ssl/ClientHandshaker.java
! src/share/classes/sun/security/ssl/Handsha
On 12/21/10 02:24 AM, David Holmes wrote:
Functionality looks okay to me.
I think those spec/doc clarifications may need to go through CCC though.
I agree with David, a CCC request should be filed for the spec changes.
We should agree the spec changes on this mailing list before proposing the
Am 21.12.2010 02:48, schrieb Mike Duigou:
I've updated the webrev with Ulf's feedback.
http://cr.openjdk.java.net/~mduigou/6728865.2/webrev/
I think your explanation belongs to both variables, contains and iterate.
Furthermore the iterated collection is the one with the major importance and ac
Am 21.12.2010 14:44, schrieb Ulf Zibis:
// As performance of Set's contains() is less than O(N/2),
// iteration is given to the remaining collection.
// For collections who's contains() are of the same complexity then
// best performance is achieved by iterating
If you were right, we never would have had generic code in 1.5 libraries. :-)
-Ulf
Am 20.12.2010 23:20, schrieb Paul Benedict:
I once heard/read that Sun had a policy where JDK N had to built with
the JDK N-1 compiler. I suppose that's not true anymore?
On Dec 21 2010, at 02:43 , Chris Hegarty wrote:
> On 12/21/10 02:24 AM, David Holmes wrote:
>> Functionality looks okay to me.
>>
>> I think those spec/doc clarifications may need to go through CCC though.
>
> I agree with David, a CCC request should be filed for the spec changes. We
> should
I think that is still not quite right. The spec for Collection says that
a Collection that does not support adding null values may or may not
support looking them up. So in both places where you say "does not
permit null values" I think you should probably say "does not permit
looking up null v
Thanks. That's an important clarification to include. Here's the revised text:
*
* Care must also be exercised when using collections that do not permit
* calling the {...@code contains} method with a {...@code null} value. If
either
* collection does not permit {...@code con
I am out of the office until 29/12/2010.
Please contact Amar Devegowda (adeve...@in.ibm.com) for any queries on
Class Libraries.
For anything else, please contact my manager Arvind Ramakrishnan
(arvi...@in.ibm.com)
Note: This is an automated response to your message "core-libs-dev Digest,
Vol
Changeset: d36ad8686f6d
Author:kevinw
Date: 2010-12-21 11:32 +
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d36ad8686f6d
6968933: Clip loop() deadlock in DirectAudioDevice$DirectClip.run
Reviewed-by: amenkov
! src/share/classes/com/sun/media/sound/DirectAudioDevice.java
On 16 December 2010 16:24, Neil Richards wrote:
> On 16 December 2010 13:01, Alan Bateman wrote:
>> On the test case, it needs the GPL header. There are templates in the
>> repository and you'll also see tests contributed by RedHat and Google if
>> that helps.
>
> Ah, sorry. I'll work on getting
Changeset: 7c33098600b2
Author:jjh
Date: 2010-12-21 16:29 -0800
URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/7c33098600b2
7008378: javac bootstrap launcher fails on cygwin when called via an absolute
path
Summary: Use cygpath if it is cygwin
Reviewed-by: ksrini
! make/Mak
Please find attached a changeset to address the problem reported in
bug 6927486, "Deadlock in legacy Hashtable writeObject()".
The problem reported is similar to one found in java.util.Vector, for
which a fix is also currently under review
(http://mail.openjdk.java.net/pipermail/core-libs-dev/2010
14 matches
Mail list logo
