Expecting Integer.valueOf(String) to accept Literal format ...

While discussing with colleagues, someone said: However, my main gripe is about not supporting in String representation of > an integer what is supported in its literal representation. > Thus, Integer x = 1_000_000; is valid, whereas > Integer.valueOf("1_000_000") is not. That sucks. It seems to

Re: Review request 8153665: URLClassLoader.definePackage() not throwing expected IAE

Updated the test to use CompileUtils that is simple and clean: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8153665/webrev.01/ Mandy

Re: RFR 8153123 : Streamline StackWalker code

On 04/07/2016 04:33 PM, Brent Christian wrote: I will send: http://cr.openjdk.java.net/~bchristi/8153123/webrev.02/ to hs-rt shortly. ...after adding the following :) diff -r f628b87a6067 makefiles/symbols/symbols-unix --- a/makefiles/symbols/symbols-unixFri Apr 08 13:14:23 2016 +0200 +

Re: Review request 8153665: URLClassLoader.definePackage() not throwing expected IAE

> On Apr 8, 2016, at 12:54 PM, Alan Bateman wrote: > > On 08/04/2016 19:48, Mandy Chung wrote: >> The spec of java.lang.Package and ClassLoader::definePackage have been >> changed in jdk-9+111 such that Package objects are defined per class loader >> and no longer inspect what packages are def

RFR JDK 9 (JAXP) 8151162: Public entries not searched when prefer='system'

Hi, Please review a fix for the issue that caused public entries not being searched when prefer='system'. When prefer='system', the Catalog standard only required that public entries were not searched if there is a system identifier. I added tests to reflect a combination of the settings of

Re: RFR: 8148568: LoggerFinder.getLogger and LoggerFinder.getLocalizedLogger should take a Module argument instead of a Class.

> On Apr 8, 2016, at 7:52 AM, Daniel Fuchs wrote: > > Hi, > > Please find below a patch that slightly modifies > the JEP 264 initial implementation to take advantage > of the module system. > > The change modifies the LoggerFinder abstract service > to take the Module of the caller class as pa

Re: Review request 8153665: URLClassLoader.definePackage() not throwing expected IAE

On 08/04/2016 19:48, Mandy Chung wrote: The spec of java.lang.Package and ClassLoader::definePackage have been changed in jdk-9+111 such that Package objects are defined per class loader and no longer inspect what packages are defined in the class loader hierarchy. The spec of URLClassLoader::

Re: RFR: JDK-8152115 (proxy) Examine performance of dynamic proxy creation

> On Apr 8, 2016, at 3:41 AM, Peter Levart wrote: > > Hi, > > With Mandy we have prepared the following patch to restore performance of > java.lanf.reflect.Proxy class caching that has regressed with introduction of > additional checks that have to be performed due to modules: > > http://cr.

Re: RFR: 8153213: Jar manifest attribute "Multi-Release" accepts any value

The new webrev is http://cr.openjdk.java.net/~sdrach/8153213/webrev/index.html and the issue is https://bugs.openjdk.java.net/browse/JDK-8153213 Now the value “true” followed by eith

Re: RFR 8151198: VarHandle factory-specific exceptions

On 04/08/2016 09:39 PM, Hans Boehm wrote: > I didn't previously have the impression that get/setOpaque was analogous > to just C/C++ volatile. C volatile officially has nothing to do with > threads and does not prevent undefined behavior for data races. It does > not in general guarantee single-c

Review request 8153665: URLClassLoader.definePackage() not throwing expected IAE

The spec of java.lang.Package and ClassLoader::definePackage have been changed in jdk-9+111 such that Package objects are defined per class loader and no longer inspect what packages are defined in the class loader hierarchy. The spec of URLClassLoader::definePackage(String name, Manifest man,

Re: RFR: 8153213: Jar manifest attribute "Multi-Release" accepts any value

Okay, I’ll prepare a new webrev. I think all we need to check for after “true” is \r or \n. If the manifest just ends without at least one of those, it’s not a legal manifest. > On Apr 8, 2016, at 11:25 AM, Claes Redestad wrote: > > On 04/08/2016 07:54 PM, Steve Drach wrote: >> I’ve put

Re: JDK 9 RFR of JDK-8153722: Mark java/nio/channels/Selector/SelectAndClose.java as intermittently failing

Looks fine Amy; thanks, -Joe On 4/8/2016 11:12 AM, Brian Burkhalter wrote: [Looping in nio-dev …] +1 (but you still need Reviewer approval). Brian On Apr 8, 2016, at 3:40 AM, Amy Lu wrote: java/nio/channels/Selector/SelectAndClose.java This test is known to fail intermittently (JDK-81528

Re: RFR: 8153213: Jar manifest attribute "Multi-Release" accepts any value

On 04/08/2016 07:54 PM, Steve Drach wrote: I’ve put up a new webrev that addresses the issue of having spaces before (and after) the value “true” in the Multi-Release attribute. Is some or all of that really necessary? since the we can specify domain of values. I think it is. The spec state

Re: JDK 9 RFR of JDK-8153722: Mark java/nio/channels/Selector/SelectAndClose.java as intermittently failing

[Looping in nio-dev …] +1 (but you still need Reviewer approval). Brian On Apr 8, 2016, at 3:40 AM, Amy Lu wrote: > java/nio/channels/Selector/SelectAndClose.java > > This test is known to fail intermittently (JDK-8152814). This patch is to > mark the test accordingly with keyword 'intermitt

Re: RFR: 8153213: Jar manifest attribute "Multi-Release" accepts any value

I’ve put up a new webrev that addresses the issue of having spaces before (and after) the value “true” in the Multi-Release attribute. >>> >>> Is some or all of that really necessary? since the we can specify domain of >>> values. >> >> I think it is. The spec states that one c

Re: RFR: 8153213: Jar manifest attribute "Multi-Release" accepts any value

> On 8 Apr 2016, at 18:54, Steve Drach wrote: > >>> I’ve put up a new webrev that addresses the issue of having spaces before >>> (and after) the value “true” in the Multi-Release attribute. >>> >> >> Is some or all of that really necessary? since the we can specify domain of >> values. > >

Re: RFR: 8153213: Jar manifest attribute "Multi-Release" accepts any value

>> I’ve put up a new webrev that addresses the issue of having spaces before >> (and after) the value “true” in the Multi-Release attribute. >> > > Is some or all of that really necessary? since the we can specify domain of > values. I think it is. The spec states that one can have an arbitra

Re: RFR 8151198: VarHandle factory-specific exceptions

> On 8 Apr 2016, at 17:59, Martin Buchholz wrote: > > On Fri, Apr 8, 2016 at 7:40 AM, Aleksey Shipilev > wrote: >> On 04/08/2016 03:51 PM, Paul Sandoz wrote: >>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8151198-VH-factory-exceptions/webrev/ >>>

Re: PING: RFR: JDK-4347142: Need method to set Password protection to Zip entries

Hi Yuji, Sherman et al. PKWARE's "Strong Encryption Specification" [1] indeed warns about patents, but how/why does this affect Winzip's AE-1 and AE-2 [2]? I don't mind if decryption support is added for the "Traditional Encryption". However, I believe it would be wrong to introduce encrypti

Re: RFR 8151198: VarHandle factory-specific exceptions

On Fri, Apr 8, 2016 at 7:40 AM, Aleksey Shipilev wrote: > On 04/08/2016 03:51 PM, Paul Sandoz wrote: >> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8151198-VH-factory-exceptions/webrev/ >> > > I agree with update

Re: RFR [9] 8153737: Unsupported Module

> On Apr 8, 2016, at 8:35 AM, Chris Hegarty wrote: > > > I moved the tests from a directory named 'jdk.unsupported' to > unsupported', as other tests, in test/tools/jdeps/module, use > test/tools/jdeps as a test library, and the directory/test lib > name is conflicting with the module name. jtr

Re: RFR [9] 8153737: Unsupported Module

On 08/04/16 03:52, Mandy Chung wrote: On Apr 7, 2016, at 10:14 AM, Chris Hegarty wrote: Enough technical debt has been paid down that we can now create the new JDK-specific module as proposed by JEP 260 [1], named jdk.unsupported. This module will initially contain, and export, the sun.misc p

Re: RFR [9] 8153737: Unsupported Module

On 07/04/16 19:57, Alan Bateman wrote: On 07/04/2016 18:14, Chris Hegarty wrote: Enough technical debt has been paid down that we can now create the new JDK-specific module as proposed by JEP 260 [1], named jdk.unsupported. This module will initially contain, and export, the sun.misc package, an

Re: RFR: 8151901: test/tools/pack200/Pack200Test fails on verifying native unpacked JAR

Thanks for the review, but your patches appears to have caused regressions, I will need to look at it this further, when I get some more cycles. Thanks Kumar Good. Please change the comment: s/null, no tuple change, force recomputation/null, drop ICs attribute, force CP recomputation/ Reor

RFR: 8148568: LoggerFinder.getLogger and LoggerFinder.getLocalizedLogger should take a Module argument instead of a Class.

Hi, Please find below a patch that slightly modifies the JEP 264 initial implementation to take advantage of the module system. The change modifies the LoggerFinder abstract service to take the Module of the caller class as parameter instead of the caller class itself. The caller class was used

Re: RFR [9] 8153737: Unsupported Module

On 08/04/2016 15:31, Peter Levart wrote: Will jdk.unsupported be "required public" by java.se? No because jdk.* are JDK-specific and should never be required by standard modules. Will you have to explicitly -addmodule jdk.unsupported for class-path programs too? It exports an API and the

Re: JDK 9 proposal: allocating ByteBuffers on heterogeneous memory

Hi Paul, One point I meant to call out in the last message but did not... Consistent with current ByteBuffers, we don't foresee public constructors on any ByteBuffer implementation classes themselves. Public constructors are only proposed for the class that implements the Memory interface with

Re: RFR 8151198: VarHandle factory-specific exceptions

On 04/08/2016 03:51 PM, Paul Sandoz wrote: > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8151198-VH-factory-exceptions/webrev/ > I agree with updates. But have more comments on C/C++ @apiNote-s. Would you like t

Re: RFR [9] 8153737: Unsupported Module

On 08/04/16 15:31, Peter Levart wrote: On 04/08/2016 12:24 PM, Paul Sandoz wrote: On 7 Apr 2016, at 19:14, Chris Hegarty wrote: Enough technical debt has been paid down that we can now create the new JDK-specific module as proposed by JEP 260 [1], named jdk.unsupported. This module will init

Re: RFR 8151705 VarHandle.AccessMode enum names should conform to code style

On 04/07/2016 04:39 PM, Paul Sandoz wrote: > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8151705-VH-AccessMode-names/webrev/ Looks good. The performance is OK. -Aleksey

Re: RFR [9] 8153737: Unsupported Module

On 04/08/2016 12:24 PM, Paul Sandoz wrote: On 7 Apr 2016, at 19:14, Chris Hegarty wrote: Enough technical debt has been paid down that we can now create the new JDK-specific module as proposed by JEP 260 [1], named jdk.unsupported. This module will initially contain, and export, the sun.misc

Re: RFR 8151706: Update VarHandle implementation to use @Stable arrays

On 04/08/2016 12:56 PM, Paul Sandoz wrote: > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8151706-VH-form-table-stable/webrev/ > > > Now that @Stable arrays are supported by C1 (thanks Vladimir!) we > can switch fr

Re: RFR 8151705 VarHandle.AccessMode enum names should conform to code style

Hi Paul, note this is a lower-case review. Thumbs up, with one remarks (no new webrev required IMO). * VarHandle.java: static initialiser of AccessMode, comment: // Initial capacity of # values will is sufficient to avoid resizes -> remove "will" Best, Michael > Am 07.04.2016 um 15:39 sch

Re: RFR 8151706: Update VarHandle implementation to use @Stable arrays

Hi Paul, note this is a lower-case review. Having looked at 8151705, thumbs up for this one as well - they go hand in hand and looking at one of them only doesn't feel right. :-) Best, Michael > Am 08.04.2016 um 11:56 schrieb Paul Sandoz : > > Hi, > > Please review: > > > http://cr.openj

Re: RFR 8152645 VarHandle lookup access control tests

Hi Paul, note this is a lower-case review. Thumbs up. I like how the test lucidly documents the access rules, and would applaud an extended test that additionally covers module boundaries. Just as a suggestion, how about using the fact that enum values are technically instances of subclasses o

RFR 8151198: VarHandle factory-specific exceptions

Hi Please review: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8151198-VH-factory-exceptions/webrev/ The patch tweaks the specification: 1) noting that factory methods may document additional undeclared ex

Re: PING: RFR: JDK-4347142: Need method to set Password protection to Zip entries

Hi Sherman and all, Thank you for all comments about this proposal! Thank Tomoyuki and Stephen for sharing your needs. Thank Bernd for sharing your information. However, I am afraid that AE1 and AE2 may have a risk of patent issue, while "Traditional PKWare encryption" is explicitly free from th

RFR: JDK-8152115 (proxy) Examine performance of dynamic proxy creation

Hi, With Mandy we have prepared the following patch to restore performance of java.lanf.reflect.Proxy class caching that has regressed with introduction of additional checks that have to be performed due to modules: http://cr.openjdk.java.net/~plevart/jdk9-dev/Proxy.caching/webrev.05/ Jigsaw

JDK 9 RFR of JDK-8153722: Mark java/nio/channels/Selector/SelectAndClose.java as intermittently failing

java/nio/channels/Selector/SelectAndClose.java This test is known to fail intermittently (JDK-8152814). This patch is to mark the test accordingly with keyword 'intermittent'. bug: https://bugs.openjdk.java.net/browse/JDK-8153722 webrev: http://cr.openjdk.java.net/~amlu/8153722/webrev.00/ Tha

Re: RFR [9] 8153737: Unsupported Module

> On 7 Apr 2016, at 19:14, Chris Hegarty wrote: > > Enough technical debt has been paid down that we can now create the new > JDK-specific module as proposed by JEP 260 [1], named jdk.unsupported. > This module will initially contain, and export, the sun.misc package, > and will eventually expor

RFR 8151706: Update VarHandle implementation to use @Stable arrays

Hi, Please review: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8151706-VH-form-table-stable/webrev/ Now that @Stable arrays are supported by C1 (thanks Vladimir!) we can switch from the explicit use of Mem

Re: JDK 9 proposal: allocating ByteBuffers on heterogeneous memory

Hi Steve, > On 8 Apr 2016, at 00:03, Dohrmann, Steve wrote: > > Hi Paul, > > We would like to have an an API for Intel's 3D XPoint memory sooner than the > JDK 10 timeframe and proposed this API because it seems simple enough to > consider for JDK 9. As you suggest, we will participate in th

Re: RFR: 8153213: Jar manifest attribute "Multi-Release" accepts any value

Hi Steve, > On 8 Apr 2016, at 03:57, Steve Drach wrote: > > I’ve put up a new webrev that addresses the issue of having spaces before > (and after) the value “true” in the Multi-Release attribute. > Is some or all of that really necessary? since the we can specify domain of values. For exam