Re: RFR: 8150680 JarFile.Release enum needs reconsideration with respect to it's values

> On 23 Jun 2016, at 04:04, Steve Drach wrote: > >> 144 private boolean notVersioned; // legacy constructor called >> >> Do you need this? > > Unfortunately yes. It’s used in entries() and stream(). If it’s set, they > have the JDK 8 semantics. If not set, entries/stream only

Re: RFR 9 7131356 : (props) "No Java runtime present, requesting install" when creating VM from JNI [macosx]

On 6/22/16 3:58 PM, Naoto Sato wrote: Hi Brent, 1. It seems that the display language in the new code seems to have some problems. I see (in es-419.txt): --- locale[Default|Display|Format].getLanguage () is user.language: it is --- And in fact, display strings are no longer in Spanish in the n

Re: RFR: 8150680 JarFile.Release enum needs reconsideration with respect to it's values

> 144 private boolean notVersioned; // legacy constructor called > > Do you need this? Unfortunately yes. It’s used in entries() and stream(). If it’s set, they have the JDK 8 semantics. If not set, entries/stream only see the appropriate versioned entries. This will go away w

RFR 8159751: ObjectStreamClass: hide 'final' flag for anonymous classes

Hi, making a change to serialization's computation of UID in order to avoid taking ACC_FINAL into account for anonymous inner classes. Will also change the Serialization Specification. https://bugs.openjdk.java.net/browse/JDK-8159751 The patch is small, inline below. Not sure about the best t

Re: RFR: 8150173: JAXBContext.newInstance causes PrivilegedActionException when createContext's declared in absract class extended by discovered JAXB implementation

> On Jun 22, 2016, at 8:09 AM, Daniel Fuchs wrote: > > Hi Georgiy, > > I added the (reworked) promised testcases. > I believe I have captured the intent of what you suggested. > > http://cr.openjdk.java.net/~dfuchs/webrev_8150173/webrev.02/ Looks okay to me. I’ll let Georgiy to review the te

Re: RFR 9 7131356 : (props) "No Java runtime present, requesting install" when creating VM from JNI [macosx]

Hi Brent, 1. It seems that the display language in the new code seems to have some problems. I see (in es-419.txt): --- locale[Default|Display|Format].getLanguage () is user.language: it is --- And in fact, display strings are no longer in Spanish in the new version (as the language is "is")

Re: RFR 9 7131356 : (props) "No Java runtime present, requesting install" when creating VM from JNI [macosx]

On 22/06/16 15:10, Alex Strange wrote: On Jun 20, 2016, at 3:44 PM, Brent Christian wrote: I'd prefer something that can build on SDK 10.9 and 10.10, etc. There might be a way to #ifdef it out (not sure), but it's not worth it. I came to the same conclusion. :) Thanks! -Brent

Re: RFR 9 7131356 : (props) "No Java runtime present, requesting install" when creating VM from JNI [macosx]

On 6/21/16 3:27 PM, Naoto Sato wrote: Actually, j.u.Locale class' "country" code is defined as ISO-3166 alpha-2 *or* UN M.49 numeric-3 area code, so if the OSX's underlying setting is "es-419" for the preferred language, "user.country" should be "419". OK, thanks - looks like another latent loc

Re: [9] RFR: 8022291: Mac OS: Unexpected JavaLaunchHelper message displaying

Looks fine. On 22.06.16 1:58, David DeHaven wrote: JBS: https://bugs.openjdk.java.net/browse/JDK-8022291 Webrev: http://cr.openjdk.java.net/~ddehaven/8022291/jdk.0/index.html This actually turned out to be pretty easy to fix, I eliminated the JavaLaunchHelper class and in place of it stuffe

RFR - 8143640: Showing incorrect result while passing specific argument in the Java launcher tool

Hi folks, Looking for a review for this simple change: http://cr.openjdk.java.net/~robm/8143640/webrev.01/ Basically the windows command parser was inserting extra slashes under certain circumstances. cmdtoargs.c standalone test passes, as do the regression tests. -Rob

Re: RFR: 8150173: JAXBContext.newInstance causes PrivilegedActionException when createContext's declared in absract class extended by discovered JAXB implementation

Hi Georgiy, I added the (reworked) promised testcases. I believe I have captured the intent of what you suggested. http://cr.openjdk.java.net/~dfuchs/webrev_8150173/webrev.02/ best regards, -- daniel http://cr.openjdk.java.net/~dfuchs/webrev_8150173/webrev.02/ On 22/06/16 11:55, Georgiy Rakov

Re: RFR: 8150173: JAXBContext.newInstance causes PrivilegedActionException when createContext's declared in absract class extended by discovered JAXB implementation

> On Jun 22, 2016, at 12:06 AM, Daniel Fuchs wrote: > > Hi Mandy, > > On 21/06/16 20:51, Mandy Chung wrote: >>> 8150173: JAXBContext.newInstance causes PrivilegedActionException >>>when createContext's declared in absract class extended >>>by discovered JAXB implementation >>> h

Re: RFR: 8150173: JAXBContext.newInstance causes PrivilegedActionException when createContext's declared in absract class extended by discovered JAXB implementation

Thanks Georgiy, You're right - more tests can't harm :-) I'll add the two scenarios you described (Test9 from your other mail and the test case described below). My current test only has the Test7 that was described in JBS. Thanks for that BTW - the isolated test case made it so much easier to

Re: Create java.util.stream.Stream from Iterator / Enumeration

> On 15 Jun 2016, at 09:35, Patrick Reinhart wrote: > >> Almost: >> - you can use Enumeration.asIterator() rather than creating your own. > > Right, for JDK 9 that will the right way. In the meantime under JDK 8 > I will have to write my own ;-) > >> - I don’t think you can assume the Iterator

Re: RFR: 8150173: JAXBContext.newInstance causes PrivilegedActionException when createContext's declared in absract class extended by discovered JAXB implementation

This is about backward compatibility, but anyway would it be good to add to tests static method case (also please see the attached file): public static class FactoryBase { public static JAXBContext createContext(Class[] classesToBeBound, Map properties) throws JAXBException {

Re: RFR: 8150173: JAXBContext.newInstance causes PrivilegedActionException when createContext's declared in absract class extended by discovered JAXB implementation

On 21.06.2016 22:51, Mandy Chung wrote: On Jun 21, 2016, at 10:39 AM, Daniel Fuchs wrote: Hi, Please find below a somewhat trivial patch for 8150173: JAXBContext.newInstance causes PrivilegedActionException when createContext's declared in absract class extended by discovere

Re: RFR 8154737: Rename VarHandle.compareAndExchangeVolatile to VarHandle.compareAndExchange

On 06/22/2016 12:34 PM, Paul Sandoz wrote: > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8154737-vh-cae-volatile-rename/webrev/ +1 -Aleksey

Re: RFR(L): 8143211: provide bytecode intrinsics for loop and try/finally executors

> On 16 Jun 2016, at 15:17, Michael Haupt wrote: > > Dear all, > > please review this change. > RFE: https://bugs.openjdk.java.net/browse/JDK-8143211 > Webrev: http://cr.openjdk.java.net/~mhaupt/8143211/webrev.00/ > InvokerBytecodeGenerator — I agree with Vladimir on the loop state held by I

Re: RFR: 8150680 JarFile.Release enum needs reconsideration with respect to it's values

> On 21 Jun 2016, at 20:23, Steve Drach wrote: > > Hi Paul, > > I believe this webrev addresses your concerns: > > http://cr.openjdk.java.net/~sdrach/8150680/webrev.03/index.html > 141 private final int base_version; // BASE_VERSION.major() Why is this an instance field? make s

RFR 8154737: Rename VarHandle.compareAndExchangeVolatile to VarHandle.compareAndExchange

Hi, Please review: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8154737-vh-cae-volatile-rename/webrev/ This patch renames VarHandle.compareAndExchangeVolatile to VarHandle.compareAndExchange so the naming

Re: RFR: 8150173: JAXBContext.newInstance causes PrivilegedActionException when createContext's declared in absract class extended by discovered JAXB implementation

Hi Mandy, On 21/06/16 20:51, Mandy Chung wrote: 8150173: JAXBContext.newInstance causes PrivilegedActionException when createContext's declared in absract class extended by discovered JAXB implementation https://bugs.openjdk.java.net/browse/JDK-8150173 Patch: http://cr.openjdk.j