Hi all,
I propose a patch to java.util.IdentityHashMap to speed-up toArray
methods of it's keySet, values and entrySet views:
http://dl.dropbox.com/u/101777488/jdk8-tl/IdentityHashMap/webrev.01/index.html
I toyed with the possibility to replace HashMap-s, that are used in
java.lang.Class
On Dec 11, 2012, at 1:24 PM, Alan Bateman alan.bate...@oracle.com wrote:
Joe sent me an update with changes to address issues discussed so far, I've
put the webrev here:
http://cr.openjdk.java.net/~alanb/8004371/webrev.02/
Joe - the classes you sent me were in different packages, also
On 12/12/2012 09:31, Paul Sandoz wrote:
http://cr.openjdk.java.net/~alanb/8004371/webrev.02/src/share/classes/jdk/internal/util/xml/PropertiesDefaultHandler.java.html
Why are the element qualified names compared ignoring case?
I'll leave this to Joe, but I agree that it doesn't look right.
On 11/12/2012 23:53, Stuart Marks wrote:
Hi all,
Please review the following gigantic webrev [1] to clean up @build
tags in RMI tests. Details underlying this change are in the bug
report [2].
Briefly, if test classes listed in @build tags are in the wrong order,
this trips over a jtreg
Changeset: 12fba0974a9d
Author:weijun
Date: 2012-12-12 18:39 +0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/12fba0974a9d
8004904: Makefile for ntlm
Reviewed-by: erikj, chegar
! make/com/sun/security/Makefile
+ make/com/sun/security/ntlm/Makefile
Looks fine to me.
-Chris.
On 11/12/2012 19:55, Alan Bateman wrote:
Those tracking the work to get us to a modular JDK will know that the
java.beans package is highly problematic.
For the core modules then j.u.l.LogManager and j.u.jar.Pack200 have
support for PropertyChangeListener and that
Hi all,
Ok, no problem. So here's a patch that summarizes what I did in the
previous patch, but only for reflective fields (Field[], Method[],
Constructor[]) not including annotations:
http://dl.dropbox.com/u/101777488/jdk8-tl/JEP-149.c/webrev/index.html
The annotations part is unchanged
Changeset: 81640e75c7a7
Author:alanb
Date: 2012-12-12 13:03 +
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/81640e75c7a7
8004874: Reduce dependency on java.beans to only
add/removePropertyChangeListener
Reviewed-by: ksrini, mchung, dholmes
!
Hi,
Please find below a refreshed webrev which adds a bit of cleanup
suggested by Paul.
Instead of casting the result of newInstance() at several places,
we pass the expected base type to newInstance so that the cast
occurs only once.
On 12/12/2012 11:59 AM, Joel Borggrén-Franck wrote:
Hi all,
First, thanks all of you that are involved in this!
I agree with David here, lets split this up (for now) and do reflective objects
in the context of jep-149 and annotations separately.
As you may know there are even more annotation
Bug description:
https://jbs.oracle.com/bugs/browse/JDK-8004928
Here is the suggested fix:
http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-8004928/webrev.01
Summary:
*test/java/io/Serializable/resolveProxyClass/NonPublicInterface.java*
Hi Chris,
I guess I figured if the parse failed the cal.set wouldn't happen.
Still, no harm in moving the 1970 into the loop on the off chance
something else goes wrong.
I've updated the test too. Thanks for spotting that.
-Rob
On 10/12/12 16:59, Chris Hegarty wrote:
Shouldn't
On 12/12/2012 04:34 PM, Peter Levart wrote:
On 12/12/2012 11:59 AM, Joel Borggrén-Franck wrote:
Hi all,
First, thanks all of you that are involved in this!
I agree with David here, lets split this up (for now) and do
reflective objects in the context of jep-149 and annotations separately.
Changeset: 68374c6e65c1
Author:robm
Date: 2012-12-12 15:57 +
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/68374c6e65c1
8004337: java/sql tests aren't run in test/Makefile
Reviewed-by: lancea, alanb
! test/Makefile
On 12/12/2012 04:51 PM, Zhong Yu wrote:
If a class loader is declared fully concurrent, yet
getClassLoadingLock() is invoked, what's the harm of returning a
dedicated lock anyway, exactly like what's done before?
To encourage people to not use locking in the first place ;-)
No, seriously, to
Yes, please.
Thanks,
Jim
On 12/11/2012 07:02 PM, Stuart Marks wrote:
Looks good!
Do you need someone to push this for you?
s'marks
On 12/11/12 3:04 PM, Jim Gish wrote:
A bit more cleanup as suggested:
Thank you Rob, I'm ok with this change.
-Chris.
On 12/12/2012 15:44, Rob McKenna wrote:
...the url would be helpful:
http://cr.openjdk.java.net/~robm/8000525/webrev.02/
-Rob
On 12/12/12 15:43, Rob McKenna wrote:
Hi Chris,
I guess I figured if the parse failed the cal.set wouldn't happen.
On Wed, Dec 12, 2012 at 10:05 AM, Peter Levart peter.lev...@gmail.com wrote:
On 12/12/2012 04:51 PM, Zhong Yu wrote:
If a class loader is declared fully concurrent, yet
getClassLoadingLock() is invoked, what's the harm of returning a
dedicated lock anyway, exactly like what's done before?
For this item:
test/java/util/logging/LoggingDeadlock4.java
Test case was simplified to avoid AWT class loading. Negative
test
result was tested on early JDK7 build.
if I remember correctly, the whole point of that test was to
check for a logging deadlock relative to
On 12/12/2012 16:36, Daniel D. Daugherty wrote:
For this item:
test/java/util/logging/LoggingDeadlock4.java
Test case was simplified to avoid AWT class loading.
Negative test
result was tested on early JDK7 build.
if I remember correctly, the whole point of that test
On 12/12/12 9:47 AM, Alan Bateman wrote:
On 12/12/2012 16:36, Daniel D. Daugherty wrote:
For this item:
test/java/util/logging/LoggingDeadlock4.java
Test case was simplified to avoid AWT class loading.
Negative test
result was tested on early JDK7 build.
if I remember
On 12/12/12 2:43 AM, Alan Bateman wrote:
On 11/12/2012 23:53, Stuart Marks wrote:
Please review the following gigantic webrev [1] to clean up @build tags in
RMI tests. Details underlying this change are in the bug report [2].
Briefly, if test classes listed in @build tags are in the wrong
On 12/12/2012 15:41, Alexey Utkin wrote:
Bug description:
https://jbs.oracle.com/bugs/browse/JDK-8004928
Here is the suggested fix:
http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-8004928/webrev.01
This mostly looks good to me, just a few comments:
For
On 12/12/12 7:41 AM, Alexey Utkin wrote:
Bug description:
https://jbs.oracle.com/bugs/browse/JDK-8004928
Here is the suggested fix:
http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-8004928/webrev.01
Looks good in general with some minor comments below.
Summary:
Hi David,
You didn't apply the original Apache completely. Was the omission of the
change in toString() method intentional?
I see that you've sent your test to Patrick. Have you run regression
test for this patch?
Thanks,
Joe
On 12/9/2012 10:25 PM, David Buck wrote:
Hi!
I would like to
Hi Max,
Looks like the $(CD) $$dir; is unnecessary here. Thanks for the catch.
Just wondering why it is failing on solaris-i586 only. I don't use
ALT_OUTPUTDIR, but never seen this failure on my environment.
Can you please file a bug for this?
Naoto
On 12/11/12 11:33 PM, Weijun Wang wrote:
The vote for Mandy Chung [1] is now closed.
Yes: 6
Veto: 0
Abstain: 0
According to the Bylaws definition of Lazy Consensus, this is sufficient
to approve the nomination.
-Alan
[1]
http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-November/012494.html
The vote for Stuart Marks [1] is now closed.
Yes: 6
Veto: 0
Abstain: 0
According to the Bylaws definition of Lazy Consensus, this is sufficient
to approve the nomination.
-Alan
[1]
http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-November/012492.html
The vote for Mike Duigou [1] is now closed.
Yes: 6
Veto: 0
Abstain: 0
According to the Bylaws definition of Lazy Consensus, this is sufficient
to approve the nomination.
-Alan
[1]
http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-November/012491.html
Changeset: 170e486632d9
Author:jlahoda
Date: 2012-12-12 20:26 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/170e486632d9
8004504: ListBuffer could reuse List.nil() as the sentinel element
Summary: ListBuffer.last now points to the last elements with client data, or
On 13/12/2012 1:51 AM, Zhong Yu wrote:
If a class loader is declared fully concurrent, yet
getClassLoadingLock() is invoked, what's the harm of returning a
dedicated lock anyway, exactly like what's done before?
The whole point is to get rid of the lockMap and these lock objects.
I could
Changeset: 5a2ab2c3f106
Author:weijun
Date: 2012-12-13 08:11 +0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5a2ab2c3f106
8004235: Disable native JGSS provider on Mac
Reviewed-by: erikj, valeriep
! make/sun/security/Makefile
! makefiles/CompileNativeLibraries.gmk
!
Hi Joe!
Thank you for looking at this.
You didn't apply the original Apache completely. Was the omission of the
change in toString() method intentional?
Yes, the improvement in toString() was not related to the issue and
seems to have been included in the apache version of this fix on a
Peter,
Many thanks for preparing that patch. As we're leaving annotations
behind lets continue any further discussion of this patch in a new email
thread specific to JEP-149.
I'll run this patch through some basic testing and performance benchmarks.
The JEP will also need updating so I'll
34 matches
Mail list logo
