RFR JDK-8081452: Move sun.nio.cs.AbstractCharsetProvider into jdk.charset/sun.nio.cs.ext

Please help review change to move the AbstractCharsetProvider from java.base/sun.nio.cs to jdk.charsets/sun.nio.cs.ext. This is needed for the modules. issue: https://bugs.openjdk.java.net/browse/JDK-8081452 webrev: http://cr.openjdk.java.net/~sherman/8081452 Thanks, -Sherman

Re: JEP 132: More-prompt finalization

Hi Peter, I guess I'm very concerned about the premise that finalization should scale to millions of objects and be performed highly concurrently. To me that's sending the wrong message about finalization. It also isn't the most effective use of cpu resources - most people would want to do us

Re: Why isn't Object.notify() a synchronized method?

On 29/05/2015 2:08 AM, Ulf Zibis wrote: Hi all, in the Javadoc of notify(), notifyAll() and wait(...) I read, that this methods should only be used with synchronisation on it's instance. So I'm wondering, why they don't have the synchronized modifier out of the box in Object class. Because, as

Re: RFR 8081027: Create a common test to check adequacy of initial size of static HashMap/ArrayList fields

Approved. On Thu, May 28, 2015 at 3:43 PM, Ivan Gerasimov wrote: Good naming is one of the most difficult part of coding IMO. > The chosen names were meant to be read literally: "optimal capacity of > ArrayList", etc. > I agree, 'assert' would tell more about these methods' intention, but I'm >

Re: RFR 8081027: Create a common test to check adequacy of initial size of static HashMap/ArrayList fields

Thank you Martin for looking at this! On 27.05.2015 17:30, Martin Buchholz wrote: Thanks. Your methods like ofArrayList declare that they throw ReflectiveOperationException, but also have a try/catch to prevent that from ever happening. Fixed! The assertions e.g. OptimalCapacity.ofArrayL

Re: RFR 9: JDK-8075678 : java.time javadoc error in DateTimeFormatter::parsedLeapSecond

Fine by me Stephen On 28 May 2015 at 21:14, Roger Riggs wrote: > Please review 3 editorial issues in the java.time package: > > Issues: > 8075678 : java.time > javadoc error in DateTimeFormatter::parsedLeapSecond > 8075676

Re: RFR 9: JDK-8075678 : java.time javadoc error in DateTimeFormatter::parsedLeapSecond

Changes seem reasonable Roger Best Lance On May 28, 2015, at 4:14 PM, Roger Riggs wrote: > Please review 3 editorial issues in the java.time package: > > Issues: > 8075678 : java.time javadoc > error in DateTimeFormatter::parsedLeapSecond > 807

RFR 9: JDK-8075678 : java.time javadoc error in DateTimeFormatter::parsedLeapSecond

Please review 3 editorial issues in the java.time package: Issues: 8075678 : java.time javadoc error in DateTimeFormatter::parsedLeapSecond 8075676 : java.time package javadoc typos 8068276

Re: RFR(M, v9): JDK-8059036 : Implement Diagnostic Commands for heap and finalizerinfo

> On 28 maj 2015, at 20:06, Mandy Chung wrote: > > > On 05/28/2015 07:35 AM, Peter Levart wrote: >> Hi Mandy, >> >> On 05/27/2015 03:32 PM, Mandy Chung wrote: >>> Taking it further - is it simpler to return String[] of all classnames >>> including the duplicated ones and have the VM do the co

Re: [8u-dev] Review request : JDK-8062904: TEST_BUG: Tests java/lang/invoke/LFCaching fail when run with -Xcomp option

Got it, thanks. Can we ignore errors caused by code cache overflow for now? Best regards, Vladimir Ivanov On 5/28/15 12:03 PM, Konstantin Shefov wrote: Vladimir, This fix is not for timeout issue, this fix is for "java.lang.VirtualMachineError: out of space in CodeCache for adapters". Timeou

Re: RFR(M,v9): JDK-8059036 : Implement Diagnostic Commands for heap and finalizerinfo

On 05/28/2015 07:35 AM, Peter Levart wrote: Hi Mandy, On 05/27/2015 03:32 PM, Mandy Chung wrote: Taking it further - is it simpler to return String[] of all classnames including the duplicated ones and have the VM do the count? Are you concerned with the size of the String[]? Yes, the hist

Re: JDK 9 RFR of JDK-8081359: Update bug reporting URL

looks OK Joe On May 28, 2015, at 1:38 AM, joe darcy wrote: > Hello, > > As the venerable URL > > http://bugreport.sun.com/bugreport/ > > has been retired and replaced with > >http://bugreport.java.com/bugreport/ > > Occurrences of the old URL in the source base should be updated. Plea

JEP 132: More-prompt finalization

Hi, Did you know that the following simple loop: public class FinalizableBottleneck { static boolean no; @Override protected void finalize() throws Throwable { // empty finalize() method does not make the object finalizable // (it is not even registered on the finali

RFR (XS: JDK-8080991 Compilation error with recent clang ....

Hi, I have already reviewed it, contributed by Staffan Larsen. This is an fyi, I will push this changeset if no one has any objections. https://bugs.openjdk.java.net/browse/JDK-8080991 http://cr.openjdk.java.net/~ksrini/8080991/webrev/ Thanks Kumar

Re: RFR: 8081392: getNodeValue should return NULL value for Element nodes

Hi Aleksej, Thanks for the quick action! The changes are good to me. Best, Joe On 5/28/2015 8:33 AM, Aleksej Efimov wrote: Hi, Please, review JDK9 fix [1] for a bug [2] in 'getNodeValue' JAXP function: According to w3c [3] getNodeValue should return 'null' value for Element nodes. This b

Re: RFR JDK-8038310: Re-examine integration of extended Charsets

On 05/28/2015 09:05 AM, Mandy Chung wrote: On 05/28/2015 08:53 AM, Xueming Shen wrote: http://cr.openjdk.java.net/~sherman/8069588_8038310/webrev This change looks okay. This code optimizes for space and assumes one single installed provider which I am not sure if it buys us much - List.toA

Re: Why isn't Object.notify() a synchronized method?

Since most of the time you have to hold the lock anyway for other reasons, I think this would generally be an unwelcome change since I expect the cost of recursive lock acquisition is nonzero. On 05/28/2015 11:08 AM, Ulf Zibis wrote: Hi all, in the Javadoc of notify(), notifyAll() and wait(..

Re: Why isn't Object.notify() a synchronized method?

On 05/28/2015 07:08 PM, Ulf Zibis wrote: > Hi all, > > in the Javadoc of notify(), notifyAll() and wait(...) I read, that this > methods should only be used with synchronisation on it's instance. > So I'm wondering, why they don't have the synchronized modifier out of > the box in Object class. W

Re: Why isn't Object.notify() a synchronized method?

What would synchronized on that method help with? Typically you do something while holding the lock and then notify while still holding the lock. sent from my phone On May 28, 2015 12:09 PM, "Ulf Zibis" wrote: > Hi all, > > in the Javadoc of notify(), notifyAll() and wait(...) I read, that this

Re: RFR JDK-8038310: Re-examine integration of extended Charsets

On 28/05/2015 16:53, Xueming Shen wrote: Alan, Thanks for the comments. Webrev has been updated accordingly. http://cr.openjdk.java.net/~sherman/8069588_8038310/webrev Looks good. -Alan.

Why isn't Object.notify() a synchronized method?

Hi all, in the Javadoc of notify(), notifyAll() and wait(...) I read, that this methods should only be used with synchronisation on it's instance. So I'm wondering, why they don't have the synchronized modifier out of the box in Object class. Also I think, the following note should be moved f

Re: RFR JDK-8038310: Re-examine integration of extended Charsets

On 05/28/2015 08:53 AM, Xueming Shen wrote: http://cr.openjdk.java.net/~sherman/8069588_8038310/webrev This change looks okay. This code optimizes for space and assumes one single installed provider which I am not sure if it buys us much - List.toArray might be another alternative rather th

Re: RFR JDK-8038310: Re-examine integration of extended Charsets

On 5/28/15 12:46 AM, Alan Bateman wrote: On 27/05/2015 20:09, Xueming Shen wrote: Hi, Please help review the change of changing the hard-wired extended charsets loading mechanism to ServiceLoader.loadInstalled(), for the module system. With the fix for JDK-8069588 in JDK 9 all charsets neede

RFR: 8081392: getNodeValue should return NULL value for Element nodes

Hi, Please, review JDK9 fix [1] for a bug [2] in 'getNodeValue' JAXP function: According to w3c [3] getNodeValue should return 'null' value for Element nodes. This behavior was changed by JDK-8032908 [4] fix - in current implementation the node content is returned. To address this issue the

Re: RFR: 8077242: Add default method CharSequence.getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)

On 05/28/2015 04:44 PM, Jason Mehrens wrote: Peter, Have we considered just embracing CharBuffer.wrap(CharSequence, int, int) work as way to support the old substring behavior? If you dig through the code, that creates a java.nio.StringCharBuffer which is a view of the wrapped string. We c

RE: RFR: 8077242: Add default method CharSequence.getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)

Peter, Have we considered just embracing CharBuffer.wrap(CharSequence, int, int) work as way to support the old substring behavior? If you dig through the code, that creates a java.nio.StringCharBuffer which is a view of the wrapped string. We could then optimize all of the friend classes to s

Re: Review Request for 8081347: Add @modules to jdk_core tests

Hi Mandy, The webrev and the diff below seem fine. Best Lance On May 28, 2015, at 1:07 AM, Mandy Chung wrote: > An update to this patch: > > Joe pointed out that javax/sql/testng has a TEST.properties file. I now move > the @modules from test/javax/sql/testng individual tests to the modules

Re: RFR(M,v9): JDK-8059036 : Implement Diagnostic Commands for heap and finalizerinfo

Hi Mandy, On 05/27/2015 03:32 PM, Mandy Chung wrote: On May 27, 2015, at 12:34 AM, Peter Levart wrote: Hi Dmitry, The jdk part looks OK (no great changes on this side from last webrev). Is there a particular reason why the return type of printFinalizayionQueue() method is Object[] and not M

RFR 9: 8077350 : JEP 102 Process API Updates Implementation

Thanks to everyone who has reviewed the Process API updates and contributed comments and improvements. Unless there are any showstoppers, I'd like to commit the work completed so far and treat any issues that come up as incremental changes. Please comment on these changes or if I missed giving

Re: JDK 9 RFR of JDK-8081245: MHIllegalAccess.java failing across platforms

Hi Joe, +1 to add to the problem list. Looks fine. Roger On 5/28/2015 1:47 AM, joe darcy wrote: Hello, The latest HotSpot integration into JDK 9 dev introduced a test failure in java/lang/invoke/8022701/MHIllegalAccess.java.MHIllegalAccess.java Please review the change below to problem l

Re: setOut() and redirectOutput() together

That's right. System.setOut(OutputStream) only assigns some OutputStream object to the System.out field, so any Java code using System.out to retrieve the OutputStream will use the newly set OuputStream. ProcessBuilder.Redirect.INHERIT on the other hand, tells ProcessBuilder where to redirect

Re: RFR: 8077242: Add default method CharSequence.getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)

On 05/10/2015 01:40 AM, Ivan Gerasimov wrote: Thanks Martin for quick reply! On 10.05.2015 1:17, Martin Buchholz wrote: Martin can you recollect if there were any concerns? It's absolutely true that I dropped the ball on this in jdk8, discouraged by David's message here: http://mail.o

Re: String.contains(CharSequence) calls toString on argument

Hi, thank you for taking time to read my proposal. Is this a matter of some OpenJDK coding conventions? I myself never use ternary operator and always use if with braces. My experience is that it improves code readability. If I have to apply one of proposed changes I would choose first or third.

Re: setOut() and redirectOutput() together

Your code makes the native app inherit native stdout/err process descriptors, you need to pipe the output from your native app to Java and then redirect the output to wherever you wish (byte array for example). In other words, Redirect.PIPE + pipe code. Dawid On Thu, May 28, 2015 at 12:43 PM, We

setOut() and redirectOutput() together

I am writing something like this ByteArrayOutputStream bout = new ByteArrayOutputStream(); System.setOut(out); System.out.println("Hello"); ProcessBuilder pb1 = new ProcessBuilder("./native-app"); pb1.redirectOutput(ProcessBuilder.Redirect.INHERIT); pb1.start(); Now "H

Re: String.contains(CharSequence) calls toString on argument

Hi, I more would like: 2199 return (s instanceof String) 2200 ? indexOf((String) s) >= 0; 2201 : indexOf(value, 0, value.length, s, 0, s.length(), 0) >= 0; or: 2199 return (s instanceof String 2200 ? indexOf((String) s) 2201

Re: String.contains(CharSequence) calls toString on argument

Hello all, encouraged by your responses I did a simple implementation and performed some JMH experiments. Details below. Webrev [1] contains my changes. I deliberately wanted to do minimal code changes. The gist of it is implementing indexOf that works on CharSequence instead of String's internal

Re: [8u-dev] Review request : JDK-8062904: TEST_BUG: Tests java/lang/invoke/LFCaching fail when run with -Xcomp option

Vladimir, This fix is not for timeout issue, this fix is for "java.lang.VirtualMachineError: out of space in CodeCache for adapters". Timeout issue is other bug and should be filed separately. I do not know why SQE added RULES with timeout to this bug. By the way, if -Xcomp is set on JDK 8u,

Re: RFR JDK-8038310: Re-examine integration of extended Charsets

On 27/05/2015 20:09, Xueming Shen wrote: Hi, Please help review the change of changing the hard-wired extended charsets loading mechanism to ServiceLoader.loadInstalled(), for the module system. With the fix for JDK-8069588 in JDK 9 all charsets needed to startup in supported environments are

Re: RFR JDK-8028480: (zipfs) NoSuchFileException on creating a file in ZipFileSystem with CREATE and WRITE

On 27/05/2015 17:01, Xueming Shen wrote: I'm aware of converting the options to internal flags in unix fs, but thought that is for the convenience... We are not saving the options for any future/internal use, simply checking its value on the spot. Just wonder really need to make the defensive