Re: RFR: 8081388: JNI exception pending in jdk/src/windows/bin/java_md.c

On 1/09/2016 5:51 AM, Henry Jen wrote: Hi, Please review a trivial fix for 8081388, in a nutshell, - Return NULL from NewPlatformStringArray if an exception occurred - All other places call this function already handled return value NULL - Launcher handles exception in JavaMain, report error an

Re: RFR: JDK-8161360,,Deprecated vfork() should not be used on Solaris

On 01/09/2016 02:55, Martin Buchholz wrote: Does an attempt to use vfork on Solaris result in something reasonable like UnsupportedOperationException? Yes: $ jshell | Welcome to JShell -- Version 9-internal | For an introduction type: /help intro jshell> System.setProperty("jdk.lang.Proce

Re: RFR: JDK-8161360, , Deprecated vfork() should not be used on Solaris

Martin, Valid launch mechanisms for Solaris set in ProcessImpl.java as: SOLARIS(LaunchMechanism.POSIX_SPAWN, LaunchMechanism.FORK), So it's not possible to set VFORK as LaunchMechanism for Solaris. and this fix doesn't change anything from customer perspective. -Dmitry On 2016-09-01 04:55,

Re: RFR: JDK-8161360,,Deprecated vfork() should not be used on Solaris

Alan, Changes looks good for me. -Dmitry On 2016-08-31 14:55, Alan Burlison wrote: > vfork(2) is deprecated on Solaris and using it generates compiler > warnings. When compiled with warnings-as-errors, this results in > compilation failures. > > Bug:https://bugs.openjdk.java.net/browse/JDK-

Re: RFR: JDK-8161360,,Deprecated vfork() should not be used on Solaris

On 01/09/2016 14:31, Dmitry Samersoff wrote: Changes looks good for me. Thanks. Could someone possibly sponsor this for me? I don't have commit rights yet... -- Alan Burlison --

Re: RFR 8164705: Remove pathname canonicalization from FilePermission

Webrev updated at http://cr.openjdk.java.net/~weijun/8164705/webrev.01 Most suggestions from Alan accepted, including: 1. Using SharedSecrets.getJavaIOFilePermissionAccess() style instead of public functions. 2. jdk.io.permissionsUseCanonicalPath=. 3. samepath.sh rewritten in ReadFileOnP

Re: Last Ant Test Failure with JDK9 - JAXP Secure Processing and XSLT Extensions

On 2016-08-31, Joe Wang wrote: > On 8/30/16, 9:34 AM, Stefan Bodewig wrote: >> On 2016-08-29, Joe Wang wrote: >>> If you are using the built-in extension functions, try turning on the >>> following feature: >>> private static final String ENABLE_EXTENSION_FUNCTIONS = >>> "http://www.oracle.

Re: RFR: 8081388: JNI exception pending in jdk/src/windows/bin/java_md.c

That’s what I think too, this is just to silent parfait. I don’t know for sure that we always get NULL with exception pending though. Cheers, Henry On September 1, 2016 at 12:34:02 AM, David Holmes (david.hol...@oracle.com) wrote: > On 1/09/2016 5:51 AM, Henry Jen wrote: > > Hi, > > > > Please r

[jdk9] (XS) RFR: 8165243: Base64.Encoder.wrap(os).write(byte[], int, int) with incorrect arguments should not produce output

Hello! An encoding output stream 'es' can be obtained as encoder.wrap(os). Normally, es.write(buf, off, len) throws IndexOutOfBoundException, if the referenced portion lies outside of the buffer. In this case, nothing is written to the underlying output stream 'os'. However, if (off + len) ove

Re: [jdk9] (XS) RFR: 8165243: Base64.Encoder.wrap(os).write(byte[], int, int) with incorrect arguments should not produce output

Looks fine Ivan. Thanks, Roger On 9/1/2016 12:40 PM, Ivan Gerasimov wrote: Hello! An encoding output stream 'es' can be obtained as encoder.wrap(os). Normally, es.write(buf, off, len) throws IndexOutOfBoundException, if the referenced portion lies outside of the buffer. In this case, nothin

Re: [jdk9] (XS) RFR: 8165243: Base64.Encoder.wrap(os).write(byte[], int, int) with incorrect arguments should not produce output

On 01/09/2016 17:40, Ivan Gerasimov wrote: Hello! An encoding output stream 'es' can be obtained as encoder.wrap(os). Normally, es.write(buf, off, len) throws IndexOutOfBoundException, if the referenced portion lies outside of the buffer. In this case, nothing is written to the underlying out

RFR: JDK-8165161 Solaris: /usr/ccs /opt/sfw and /opt/csw are dead, references should be expunged

I posted this originally on build-dev, it was suggested I should also post it to core-libs-dev for review of some of the changes. /usr/ccs /opt/sfw and /opt/csw are all obsolete and should be removed from the Solaris-related build infrastructure. Bug:https://bugs.openjdk.java.net/browse/J

RFR: JDK-8161230 ClassLoader: add resource methods returning java.util.stream.Stream

Hi Alan, Hi Paul, Here is the first revision of the implementation based on our earlier conversation. http://cr.openjdk.java.net/~reinhapa/reviews/8161230/webrev.00 - Patrick

Re: RFR (JAXP) 8161454: Fails to Load external Java method from inside of a XSL stylesheet if SecurityManager is present

On 31/08/16 21:47, Joe Wang wrote: Thanks Aleksej! Hi Joe, Your last revision looks good. best, -- daniel -Joe On 8/31/16, 11:26 AM, Aleks Efimov wrote: Hi Joe, The changes looks nice (I'm not a reviewer) Best Regards, Aleksej On 31/08/16 19:47, Joe Wang wrote: Hi, Please review

Re: RFR (JAXP) 8161454: Fails to Load external Java method from inside of a XSL stylesheet if SecurityManager is present

Thanks Daniel! -Joe On 9/1/16, 3:37 PM, Daniel Fuchs wrote: On 31/08/16 21:47, Joe Wang wrote: Thanks Aleksej! Hi Joe, Your last revision looks good. best, -- daniel -Joe On 8/31/16, 11:26 AM, Aleks Efimov wrote: Hi Joe, The changes looks nice (I'm not a reviewer) Best Regards, Al

Re: RFR 8164705: Remove pathname canonicalization from FilePermission

At the API level and conceptually this all appears reasonable. I am going to need to take a deeper pass over it all however to comprehend the implementation at any kind of detailed level. The changes mentioned in response to Alan’s comments all appear good. Thanks, Brian On Sep 1, 2016, at 7:

RE: RFR 9: JEP 290: Filter Incoming Serialization Data

  Hi Roger, Many collections classes don't read arrays in directly, instead they read in  the size as a primitive integer and create the array before reading in each  object. Clearly the filter can only prevent deserialization of dangerous objects. My personal opinion is collections classes should 

RFR(m): 8159404: immutable collections should throw UOE unconditionally

Hi all, Please review this change to make the immutable collections (List.of, Set.of, Map.of) throw UnsupportedOperationException unconditionally. That is, they should throw UOE even if a mutator method is called with arguments that make it a no-op. Calling a mutator method on an immutable col

Re: RFR: 8081388: JNI exception pending in jdk/src/windows/bin/java_md.c

On 2/09/2016 2:03 AM, Henry Jen wrote: That’s what I think too, this is just to silent parfait. We are doing similar things in VM code, but the NULL check suffices. If that is not the case here then I think a Parfait bug needs to be filed. I don’t know for sure that we always get NULL with

Re: RFR(m): 8159404: immutable collections should throw UOE unconditionally

Looks good to me! Another idea for another day: I would like the immutable collections to be more optimal than they currently are, even if we have to write more code. It bugs me is that all of these collections have a modCount, despite never being modified! (Even for mutable lists, I'm not sure t

Re: RFR(m): 8159404: immutable collections should throw UOE unconditionally

> On 1 Sep 2016, at 20:41, Martin Buchholz wrote: > > Looks good to me! > +1 Paul.

Re: RFR: JDK-8161230 ClassLoader: add resource methods returning java.util.stream.Stream

Hello! The documentation says: + * The search order is described in the documentation for {@link+ * #getResource(String)}. I think it means that the order of the stream is well-defined. In this case should not we add ORDERED spliterator characteristic? With best regards, Tagir Valeev.

Re: RFR: JDK-8161230 ClassLoader: add resource methods returning java.util.stream.Stream

Hi Patrick, src/java.base/share/classes/java/lang/ClassLoader.java The constant RESOURCE_CHARACTERISTICS in the line 215 should be defined near the #streamOf()-method. The distance between the line 1412 where the #streamOf()-method is defined and the line 215 is just too huge. Your patch seems t