Review request: 8154190 & 8155513: Deprivilege java.compiler and jdk.charsets

JDK-8154190: Deprivilege java.compiler module Webrev: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8154190/webrev.00/ JDK-8155513: Deprivilege jdk.charsets module Webrev: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8155513/webrev.00/ Very simple change. These patches move

Re: (S) RFR: 8154710: [Solaris] Investigate use of in-memory low-resolution timestamps for Java and internal time API's

On 30/04/2016 9:28 AM, Daniel D. Daugherty wrote: On 4/28/16 5:09 PM, David Holmes wrote: bug: https://bugs.openjdk.java.net/browse/JDK-8154710 webrev: http://cr.openjdk.java.net/~dholmes/8154710/webrev/ src/os/solaris/vm/os_solaris.cpp L1356: static _get_nsec_fromepoch_func_t

Re: RFR: 8151542: URL resources for multi-release jar files have a #runtime fragment appended to them

Hopefully the last one ;-) This webrev removes the lowercase of protocol, and incorporates better (in my mind) seperation of choices for choosing the loader, similar to what Paul suggested. Everything else remains the same. Only URLClassPath changed from previous webrev.

Re: RFR: 8151542: URL resources for multi-release jar files have a #runtime fragment appended to them

> On Apr 29, 2016, at 4:47 PM, Xueming Shen wrote: > > On 4/29/16 3:30 PM, Steve Drach wrote: >> I updated the webrev with changes that Alan suggested >> >> still needs to be fixed to compare the URL protocol without regard to >> case > > ->

Re: RFR: 8151542: URL resources for multi-release jar files have a #runtime fragment appended to them

On 4/29/16 3:30 PM, Steve Drach wrote: I updated the webrev with changes that Alan suggested still needs to be fixed to compare the URL protocol without regard to case -> toLowerCase(Locale.ROOT). And Sherman suggested Shouldn't the realname just be the "super.getName()” ? The webrev is

Re: RFR (M) 8155739: [TESTBUG] VarHandles/Unsafe tests for weakCAS should allow spurious failures

> On 29 Apr 2016, at 15:12, Aleksey Shipilev > wrote: > > Hi, > > I would like to fix a simple testbug in our weakCompareAndSet VarHandles > and Unsafe intrinsics tests. weakCompareAndSet is spec-ed to allow > spurious failures, but current tests do not allow

Re: (S) RFR: 8154710: [Solaris] Investigate use of in-memory low-resolution timestamps for Java and internal time API's

On 4/28/16 5:09 PM, David Holmes wrote: bug: https://bugs.openjdk.java.net/browse/JDK-8154710 webrev: http://cr.openjdk.java.net/~dholmes/8154710/webrev/ src/os/solaris/vm/os_solaris.cpp L1356: static _get_nsec_fromepoch_func_t _get_nsec_fromepoch = NULL; nit: two spaced between

Re: RFR: 8151542: URL resources for multi-release jar files have a #runtime fragment appended to them

> On 29 Apr 2016, at 13:46, Alan Bateman wrote: > > > > On 29/04/2016 19:36, Steve Drach wrote: >> I put a new webrev out with the change suggested by Paul, using >> file.indexOf(“!/“) instead of file.endsWith(“!/“). >> >>

Re: (S) RFR: 8154710: [Solaris] Investigate use of in-memory low-resolution timestamps for Java and internal time API's

(adding back hotspot-dev - still heed a hs/runtime reviewer) Hi Roger, On 30/04/2016 12:19 AM, Roger Riggs wrote: Hi, This change seems fine to me; though barely observable only in a microcosm. Thanks for the review. (I was going to make the same comment as Daniel, logging now uses higher

Re: RFR: 8151542: URL resources for multi-release jar files have a #runtime fragment appended to them

I updated the webrev with changes that Alan suggested still needs to be fixed to compare the URL protocol without regard to case And Sherman suggested Shouldn't the realname just be the "super.getName()” ? The webrev is at

RFR (M) 8155739: [TESTBUG] VarHandles/Unsafe tests for weakCAS should allow spurious failures

Hi, I would like to fix a simple testbug in our weakCompareAndSet VarHandles and Unsafe intrinsics tests. weakCompareAndSet is spec-ed to allow spurious failures, but current tests do not allow that. This blocks development and testing on non-x86 platforms. Bug:

Re: RFR 8147984: WindowsTerminal should support function keys

Hi Jan, I finally got a chance to take a look at this. The change looks fine. It would be nice to have a reference to where the escape sequences are documented. There are links to the Windows VK_ codes there, which is great. But there's no reference for the escape sequences that each keypress

Re: RFR: 8151542: URL resources for multi-release jar files have a #runtime fragment appended to them

>> I just didn’t see it as any higher than P4. What would you like it to be? >> >> > We've stumbled on an issue where the spec and implementation are in conflict. > The right thing to do it to fix it while we have a handle on it. I bumped the priority to P2.

Re: RFR(XXS): 8149519: Investigate implementation of java.specification.version

On 29/04/2016 21:03, Martin Buchholz wrote: Today, I tried google-searching for "LinkedList se 9" which sent me to http://download.java.net/jdk9/docs/api/java/util/LinkedList.html?is-external=true which gives me 404. That's an improvement on the stale +104 docs, and should prod Google's

Re: RFR: 8151542: URL resources for multi-release jar files have a #runtime fragment appended to them

On 29/04/2016 22:12, Steve Drach wrote: I just didn’t see it as any higher than P4. What would you like it to be? We've stumbled on an issue where the spec and implementation are in conflict. The right thing to do it to fix it while we have a handle on it. -Alan

Re: RFR: 8151542: URL resources for multi-release jar files have a #runtime fragment appended to them

>> I put a new webrev out with the change suggested by Paul, using >> file.indexOf(“!/“) instead of file.endsWith(“!/“). >> >> http://cr.openjdk.java.net/~sdrach/8151542/webrev.02/index.html >> This >> still needs to be fixed

Re: RFR: 8151542: URL resources for multi-release jar files have a #runtime fragment appended to them

On 29/04/2016 19:36, Steve Drach wrote: I put a new webrev out with the change suggested by Paul, using file.indexOf(“!/“) instead of file.endsWith(“!/“). http://cr.openjdk.java.net/~sdrach/8151542/webrev.02/index.html This

Re: RFR: 8151542: URL resources for multi-release jar files have a #runtime fragment appended to them

JarFile.getRealName() invokes e.realEntry().getName() to get the "realname", which may create a new JarFileEntry() if the names are different. Shouldn't the realname just be the "super.getName()" ? sherman On 04/29/2016 11:36 AM, Steve Drach wrote: I put a new webrev out with the change

Re: RFR(XXS): 8149519: Investigate implementation of java.specification.version

Today, I tried google-searching for "LinkedList se 9" which sent me to http://download.java.net/jdk9/docs/api/java/util/LinkedList.html?is-external=true which gives me 404. That's an improvement on the stale +104 docs, and should prod Google's engine into learning about better docs, but it may

Re: RFR: 8151542: URL resources for multi-release jar files have a #runtime fragment appended to them

On Apr 28, 2016, at 11:26 AM, Steve Drach wrote: > > Keeping with the path precedent, is it acceptable to change “getReifiedName” > to “getRealName”? For me, in this setting, "true" and "real" are equally good. (Perhaps they differ metaphysically, but that's too many

Re: RFR: 8139982 Re-examine java.management dependency on java.util.logging.LoggingMXBean

Hi Daniel, > On Apr 29, 2016, at 8:08 AM, Daniel Fuchs wrote: > > Hi, > > Please find below a patch [2] that eliminates a static > dependency of java.lang.management on java.util.logging.LoggingMXBean. > > When JDK-6876135 was fixed, it introduced the

Re: RFR: 8151542: URL resources for multi-release jar files have a #runtime fragment appended to them

I put a new webrev out with the change suggested by Paul, using file.indexOf(“!/“) instead of file.endsWith(“!/“). http://cr.openjdk.java.net/~sdrach/8151542/webrev.02/index.html > So you are planning to eventually change the

Re: RFR: 8151542: URL resources for multi-release jar files have a #runtime fragment appended to them

On 29/04/2016 16:55, Steve Drach wrote: I’ve updated the webrev to change all instances of the word “reified” to “real” as in getRealName(). Issue: https://bugs.openjdk.java.net/browse/JDK-8151542 Webrev: http://cr.openjdk.java.net/~sdrach/8151542/webrev.01/

Re: RFR: 8151542: URL resources for multi-release jar files have a #runtime fragment appended to them

> On 29 Apr 2016, at 07:32, Alan Bateman wrote: > > > > On 28/04/2016 22:18, Steve Drach wrote: >> I’ve updated the webrev to change all instances of the word “reified” to >> “real” as in getRealName(). >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8151542

Re: Integer/Long reverse bits optimization

Hi, thank you:) I have OCA signed and processed. I have changed Integer.reverseBytes, and added two small checks to BitTwiddle tests for Integer and Long, patch is attached. Jaroslav 2016-04-29 14:33 GMT+02:00 Claes Redestad : > Hi, > > > On 2016-04-29 13:36,

Re: RFR: 8151542: URL resources for multi-release jar files have a #runtime fragment appended to them

>> I’ve updated the webrev to change all instances of the word “reified” to >> “real” as in getRealName(). >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8151542 >> >> >> Webrev: http://cr.openjdk.java.net/~sdrach/8151542/webrev.01/ >>

Re: RFR(m): 8140281 deprecate Optional.get()

Hi Peter, > ...even more Stream-y (with JDK 9 changes to Optional): > > otherMods >.stream() >.flatMap(mod -> finder.find(mod).stream()) >.forEach(mref -> ...); > > > Yes, it takes some time for people to get used to new tools before they use > them optimally. This is a normal

RFR: 8139982 Re-examine java.management dependency on java.util.logging.LoggingMXBean

Hi, Please find below a patch [2] that eliminates a static dependency of java.lang.management on java.util.logging.LoggingMXBean. When JDK-6876135 was fixed, it introduced the PlatformLoggingMXBean interface, and recommended using PlatformLoggingMXBean over LoggingMXBean. However, it left a

Re: RFR: 8151542: URL resources for multi-release jar files have a #runtime fragment appended to them

On 28/04/2016 22:18, Steve Drach wrote: I’ve updated the webrev to change all instances of the word “reified” to “real” as in getRealName(). Issue: https://bugs.openjdk.java.net/browse/JDK-8151542 Webrev: http://cr.openjdk.java.net/~sdrach/8151542/webrev.01/

Re: RFR: 8155600 - Performance optimization of Arrays.asList().iterator()

Hi all, Just nitpicking, i wonder if it's not better to use the Doug Lea's convention in next() i.e. rename i to cursor to shadow the field cursor public E next() { int cursor = this.cursor; if (cursor >= a.length) { throw new

Re: (S) RFR: 8154710: [Solaris] Investigate use of in-memory low-resolution timestamps for Java and internal time API's

Hi, This change seems fine to me; though barely observable only in a microcosm. (I was going to make the same comment as Daniel, logging now uses higher resolution timestamps). Roger On 4/29/2016 9:46 AM, charlie hunt wrote: On Apr 29, 2016, at 8:35 AM, Daniel Fuchs

Re: (S) RFR: 8154710: [Solaris] Investigate use of in-memory low-resolution timestamps for Java and internal time API's

> On Apr 29, 2016, at 8:35 AM, Daniel Fuchs wrote: > > Hi Aleksey, > > On 29/04/16 12:12, Aleksey Shipilev wrote: >> On 04/29/2016 01:05 PM, David Holmes wrote: >>> On 29/04/2016 7:50 PM, Aleksey Shipilev wrote: On 04/29/2016 02:09 AM, David Holmes wrote: >

Re: RFR: 8155600 - Performance optimization of Arrays.asList().iterator()

On 04/29/2016 04:38 PM, Claes Redestad wrote: > On 2016-04-29 15:31, Tagir F. Valeev wrote: >> Hello! >> >> Thank you for comments. Update: >> http://cr.openjdk.java.net/~tvaleev/webrev/8155600/r3/ > > Looks good. Okay, good! I'll sponsor. Thanks, -Aleksey

Re: RFR: 8155600 - Performance optimization of Arrays.asList().iterator()

On 2016-04-29 15:31, Tagir F. Valeev wrote: Hello! Thank you for comments. Update: http://cr.openjdk.java.net/~tvaleev/webrev/8155600/r3/ Looks good. Thanks! /Claes

Re: (S) RFR: 8154710: [Solaris] Investigate use of in-memory low-resolution timestamps for Java and internal time API's

Hi Aleksey, On 29/04/16 12:12, Aleksey Shipilev wrote: On 04/29/2016 01:05 PM, David Holmes wrote: On 29/04/2016 7:50 PM, Aleksey Shipilev wrote: On 04/29/2016 02:09 AM, David Holmes wrote: This change is small in nature but somewhat broad in scope. It "affects" the implementation of

Re: RFR: 8155600 - Performance optimization of Arrays.asList().iterator()

Hello! Thank you for comments. Update: http://cr.openjdk.java.net/~tvaleev/webrev/8155600/r3/ AS> Test: AS> *) Formatting: "i=0", "i *) Formatting: "} catch (NSEE ex)" should be on the same line; Done. AS> *) What does the "for (int i=0;

Re: (S) RFR: 8154710: [Solaris] Investigate use of in-memory low-resolution timestamps for Java and internal time API's

> On Apr 29, 2016, at 5:12 AM, Aleksey Shipilev > wrote: > >> On 04/29/2016 01:05 PM, David Holmes wrote: >>> On 29/04/2016 7:50 PM, Aleksey Shipilev wrote: On 04/29/2016 02:09 AM, David Holmes wrote: This change is small in nature but somewhat broad in

Re: RFR: 8155600 - Performance optimization of Arrays.asList().iterator()

On 04/29/2016 03:40 PM, Tagir F. Valeev wrote: > http://cr.openjdk.java.net/~tvaleev/webrev/8155600/r2/ JDK part looks good to me. Test: *) Formatting: "i=0", "i

Re: Integer/Long reverse bits optimization

Hi, On 2016-04-29 13:36, Jaroslav Kameník wrote: Hello! I have a small patch to Integer and Long classes, which is speeding up bit reversion significantly. Last two/three steps of bit reversion are doing byte reversion, so there is possibility to use intrinsified method reverseBytes. Java

Re: RFR: 8155600 - Performance optimization of Arrays.asList().iterator()

Thank you for reviews! Here's updated webrev: http://cr.openjdk.java.net/~tvaleev/webrev/8155600/r2/ AS> *) Does EA break if you make ArrayItr inner class to gain the access to AS> E[] a? No, I checked, it still allocates. AS> *) next(): Missing braces in throw new NSEE() block; Fixed AS>

Re: RFR 8154755: Add a VarHandle weakCompareAndSet with volatile semantics

Looks good. Best regards, Vladimir Ivanov On 4/21/16 7:21 PM, Paul Sandoz wrote: Hi, Please review: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8154755-weak-cas-volatile/webrev/ This webrev adds a new VarHandle access mode method, weakCompareAndSetVolatile [*]. (I also fixed some doc

Integer/Long reverse bits optimization

Hello! I have a small patch to Integer and Long classes, which is speeding up bit reversion significantly. Last two/three steps of bit reversion are doing byte reversion, so there is possibility to use intrinsified method reverseBytes. Java implementation of reverseBytes is similar to those

Re: RFR(m): 8140281 deprecate Optional.get()

On 04/29/2016 11:23 AM, Andrej Golovnin wrote: The lines 406-415 can be rewritten as: otherMods .stream() .map(finder::find) // After this step you can filter out all // empty Optionals. // But I don't

Re: RFR (XS) 8155090: String concatenation fails with a custom SecurityManager that uses concatenation

On 04/29/2016 10:09 AM, Chris Hegarty wrote: >> On 28 Apr 2016, at 21:54, Claes Redestad > > wrote: >>> The cleanest (yet subtle) solution here is to make sure the default SCF >>> settings are good to run with, which allows transient

Re: (S) RFR: 8154710: [Solaris] Investigate use of in-memory low-resolution timestamps for Java and internal time API's

On 04/29/2016 01:05 PM, David Holmes wrote: > On 29/04/2016 7:50 PM, Aleksey Shipilev wrote: >> On 04/29/2016 02:09 AM, David Holmes wrote: >>> This change is small in nature but somewhat broad in scope. It "affects" >>> the implementation of System.currentTimeMillis() in the Java space, and >>>

Re: (S) RFR: 8154710: [Solaris] Investigate use of in-memory low-resolution timestamps for Java and internal time API's

On 29/04/2016 7:50 PM, Aleksey Shipilev wrote: On 04/29/2016 02:09 AM, David Holmes wrote: bug: https://bugs.openjdk.java.net/browse/JDK-8154710 webrev: http://cr.openjdk.java.net/~dholmes/8154710/webrev/ Looks good. Is hrtime_t always integral, so you can "(hrtime_t)now /

Re: Review request 8153912: StackFrame::getFileName and StackFrame::getLineNumber not needed

Hi Mandy, This looks good to me. Regarding final methods, I believe it might be prudent to make toStackTraceElement() final - and possibly also all the getters that call it. It would be imprudent to try to override any of these methods in a subclass without looking at the implementation in the

Re: (S) RFR: 8154710: [Solaris] Investigate use of in-memory low-resolution timestamps for Java and internal time API's

On 04/29/2016 02:09 AM, David Holmes wrote: > bug: https://bugs.openjdk.java.net/browse/JDK-8154710 > webrev: http://cr.openjdk.java.net/~dholmes/8154710/webrev/ Looks good. Is hrtime_t always integral, so you can "(hrtime_t)now / NANOSECS_PER_MILLISEC" it? > This change is small in nature but

Re: RFR(m): 8140281 deprecate Optional.get()

On 29/04/2016 10:23, Andrej Golovnin wrote: : "There are many Java 8 developers using streams() and optionals with an imperative programming mindset still." And here is an example from JDK. Take look at the code

Re: RFR(m): 8140281 deprecate Optional.get()

Hi Stuart, > I also think it's reasonable, independently of any deprecation/renaming, for > IDE vendors to > add rule checkers that attempt to detect unsafe uses of Optional. I'm a bit > skeptical of whether it's possible for there to be automatic fixes, but > detection would be a good step

Re: RFR(XXS): 8149519: Investigate implementation of java.specification.version

On 27/04/2016 12:26, Martin Buchholz wrote: I think the jdk9 docs have moved (again, g - I complain about this sort of thing every release) and so a google search for "package class se 9" only finds the old one +104 at http://download.java.net/jdk9/docs/api/java/lang/Package.html Why can't

Re: RFR 8155088, Fix module dependencies in java/sql/* and javax/* tests

On 2016/4/29 15:25, Alan Bateman wrote: On 29/04/2016 03:16, Felix Yang wrote: Hi there, please review the changes to explicitly declare module dependencies for "java/sql/*" and "javax/*" tests; Bug: https://bugs.openjdk.java.net/browse/JDK-8155088 Webrev:

Re: RFR 8155088, Fix module dependencies in java/sql/* and javax/* tests

On 29/04/2016 03:16, Felix Yang wrote: Hi there, please review the changes to explicitly declare module dependencies for "java/sql/*" and "javax/*" tests; Bug: https://bugs.openjdk.java.net/browse/JDK-8155088 Webrev: http://cr.openjdk.java.net/~xiaofeya/8155088/webrev.00/ Felix - would

Re: RFR (XS) 8155090: String concatenation fails with a custom SecurityManager that uses concatenation

> On 28 Apr 2016, at 21:54, Claes Redestad wrote: > > Hi Aleksey, > > On 2016-04-28 22:10, Aleksey Shipilev wrote: >> Hi, >> >> Please review the fix for a shady bootstrapping issue, when a custom >> SecurityManager is using string concatenation: >>