Re: Code Review Request, 8152237 Support BigInteger.TWO

On 3/23/2016 12:10 PM, Wang Weijun wrote: Only 3 files touched. Are you going to make the s/BigInteger.valueOf(2)/BigInteger.TWO/ changes in other files with another bug fix? There are also uses in security components. I will make the update in another bug. Thanks, Xuelei Thanks Max

Re: Code Review Request, 8152237 Support BigInteger.TWO

Only 3 files touched. Are you going to make the s/BigInteger.valueOf(2)/BigInteger.TWO/ changes in other files with another bug fix? Thanks Max > On Mar 23, 2016, at 11:26 AM, Xuelei Fan wrote: > > Hi, > > Please review the update for the supporting of BigInteger.TWO:

Code Review Request, 8152237 Support BigInteger.TWO

Hi, Please review the update for the supporting of BigInteger.TWO: http://cr.openjdk.java.net/~xuelei/8152237/webrev/ BigInteger.valueOf(2) is a common BigInteger value used in binary and cryptography operation calculation. The BigInteger.TWO is not exported, and hence

Re: Review request: 8152503: tools/javac/completionDeps/DepsAndAnno.java fails after jigsaw m3

Looks fine Mandy; thanks, -Joe On 3/22/2016 6:46 PM, Mandy Chung wrote: Also problem list a new test tools/jdeps/moidules/GenModuleInfo.java diff --git a/test/tools/javac/completionDeps/DepsAndAnno.java b/test/tools/javac/completionDeps/DepsAndAnno.java ---

Review request: 8152503: tools/javac/completionDeps/DepsAndAnno.java fails after jigsaw m3

Also problem list a new test tools/jdeps/moidules/GenModuleInfo.java diff --git a/test/tools/javac/completionDeps/DepsAndAnno.java b/test/tools/javac/completionDeps/DepsAndAnno.java --- a/test/tools/javac/completionDeps/DepsAndAnno.java +++ b/test/tools/javac/completionDeps/DepsAndAnno.java @@

Re: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently

> On Mar 22, 2016, at 5:24 AM, Per Liden wrote: > One thing I like about this approach is that it's only the ReferenceHandler > thread that pops of elements from the pending list and enqueues them. That > simplifies things a lot. I like that too. And hopefully we really

Re: Commenting on bug JDK-8151981

On 03/18/2016 08:40 AM, Jan Bauer Nielsen wrote: > If there is anything we can do to help You investigate this problem, > please let us know? It's pretty much impossible to fix a bug if we don't have a reproducer. Andrew.

Re: RFR: regex changes

Thanks Roger! webrev has been updated accordingly. See comments below. http://cr.openjdk.java.net/~sherman/regexBackTrack.Lamnda.CanonEQ/webrev/ On 03/22/2016 12:48 PM, Roger Riggs wrote: Hi Sherman, A few more comments, Pattern.java: - 1782: typo: "deterministci" fixed. - 2176:

Re: Review request for 8151571: System/LoggerFinder tests fail after JDK-8149925

Hi Mandy, Nice to see this fixed. It looks good to me. Thanks! Regads, Peter On 03/22/2016 07:41 PM, Mandy Chung wrote: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8151571/webrev.00/ This restores the change in NativeBuffer to use the common Cleaner created by the system. JDK-8149925

Commenting on bug JDK-8151981

Hello I'm from the company experiencing issue [1] mentioned in bug JDK-8151981. If there is anything we can do to help You investigate this problem, please let us know? Kind regards, Jan Bauer Nielsen Software developer DBC as http://www.dbc.dk/english

Re: RFR: regex changes

Hi Sherman, A few more comments, Pattern.java: - 1782: typo: "deterministci" - 2176: commented out code? - 2667: indentation - 5660,5655: lambda syntax use of simply "ch" is preferred over "(ch)" for single parameter lambdas and for consistency within the file. PrintPattern.java

Re: JDK 9 RFR of 8151957: ObjectInputStream.java -incorrect HashMap initial size allocation, and useless variable set

On 2016-03-22 19:44, Brian Burkhalter wrote: On Mar 22, 2016, at 11:38 AM, Brian Burkhalter wrote: Please review at your convenience. Issue: https://bugs.openjdk.java.net/browse/JDK-8151957 Patch: http://cr.openjdk.java.net/~bpb/8151957/webrev.00/ Summary:

Re: JDK 9 RFR of 8151957: ObjectInputStream.java -incorrect HashMap initial size allocation, and useless variable set

Looks good. Like these new convienence methods. On Mar 22, 2016, at 2:38 PM, Brian Burkhalter wrote: > Please review at your convenience. > > Issue:https://bugs.openjdk.java.net/browse/JDK-8151957 > Patch:

Re: JDK 9 RFR of 8151957: ObjectInputStream.java -incorrect HashMap initial size allocation, and useless variable set

On Mar 22, 2016, at 11:38 AM, Brian Burkhalter wrote: > Please review at your convenience. > > Issue:https://bugs.openjdk.java.net/browse/JDK-8151957 > Patch:http://cr.openjdk.java.net/~bpb/8151957/webrev.00/ > > Summary: > Modify the

Review request for 8151571: System/LoggerFinder tests fail after JDK-8149925

http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8151571/webrev.00/ This restores the change in NativeBuffer to use the common Cleaner created by the system. JDK-8149925 causes InnocuousThread be created early during startup before the system class loader is initialized. Since the common

JDK 9 RFR of 8151957: ObjectInputStream.java -incorrect HashMap initial size allocation, and useless variable set

Please review at your convenience. Issue: https://bugs.openjdk.java.net/browse/JDK-8151957 Patch: http://cr.openjdk.java.net/~bpb/8151957/webrev.00/ Summary: Modify the initialization of primClasses primitive type name-to-class object table to use the new Map.of() convenience method with nine

Re: 8152436: Add a test to verify that the root logger correctly reports the caller's information

Understood. When I tested a subclassed logger all of the JDKs work correctly. I didn't check but it just seems like something that could regress if there is no test. Regards, Jason From: Daniel Fuchs Sent: Tuesday, March 22,

Re: 8152436: Add a test to verify that the root logger correctly reports the caller's information

On 22/03/16 17:11, Jason Mehrens wrote: Hi Daniel, I think we just need to add a test where a subclass logger logs the message with the root logger as the parent. Should be no need to register that logger with the LogManager. Not sure if it is worth checking that custom filters installed on

RFR: 8152436: Add a test to verify that the root logger correctly reports the caller's information

Hi, Please find below a new test that verifies that JDK-8152389 does not occur in JDK 9. bug: 8152436: Add a test to verify that the root logger correctly reports the caller's information https://bugs.openjdk.java.net/browse/JDK-8152436 Issue being verified by the test:

Re: JAXP default implementation and JDK-8152063

Hi David, On 22/03/16 13:53, David M. Lloyd wrote: Am I understanding it correctly that you're pointing the system property to a "proxy" as stated in JDK-8152063, not an actual implementation? So it's sort of a provider-locating mechanism outside of jaxp, that locates the actual

Re: RFR: JDK-8152352 Compiling warnings in zip_util.c blocks devkit to build with --with-zlib=system

Looks fine. Roger On 5/21/2016 5:06 PM, Xueming Shen wrote: Hi, Please help review the change to remove two compiling warnings in zip_util.c issue: https://bugs.openjdk.java.net/browse/JDK-8152352 webrev: http://cr.openjdk.java.net/~sherman/8152352/webrev/ thanks, Sherman

Re: JAXP default implementation and JDK-8152063

On 03/21/2016 07:42 PM, huizhe wang wrote: On 3/21/2016 12:55 PM, David M. Lloyd wrote: On 03/21/2016 01:38 PM, Alan Bateman wrote: On 21/03/2016 14:39, David M. Lloyd wrote: This message is in reference to the aforementioned issue [1] that I've requested my colleague Andrew Hughes to open on

RFR 8150829: Enhanced drop-args, identity and default constant, varargs adjustment

Hi All, Please review the following- https://bugs.openjdk.java.net/browse/JDK-8150829 http://cr.openjdk.java.net/~srastogi/8150829/webrev.04 Thanks, Shilpi

Re: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently

Hi Peter, On 2016-03-21 16:30, Peter Levart wrote: Hi Per, May I point you to my proposed change in Reference(Handler) for JDK 9, being discussed in the thread about JDK-8149925. It will hopefully remove the special-casing of sun.misc.Cleaner, change the way how pending references are being

Re: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently

On 2016-03-21 18:32, Kim Barrett wrote: On Mar 21, 2016, at 8:20 AM, Per Liden wrote: Hi Peter & David, (Resurrecting an old thread here...) On 2014-01-22 03:19, David Holmes wrote: Hi Peter, On 22/01/2014 12:00 AM, Peter Levart wrote: Hi, David, Kalyan, Summing up

Re: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently

Hi Peter, On 2016-03-21 16:13, Peter Levart wrote: Hi Per, David, As things stand, there is a very good chance that sun.misc.Cleaner will go away in JDK9, so all this speculation about the source of OOME(s) can be put to rest. But for JDK 8u, I agree that this should be sorted out. My feeling