Re: RFR(xs): 8165936: Potential Heap buffer overflow when seaching timezone info files

+1 On 9/14/2016 2:34 AM, Thomas Stüfe wrote: Hi all, thanks for the reviews. Here is version two: http://cr.openjdk.java.net/~stuefe/webrevs/8165936-Potential-Heap-buffer-overflow-when-seaching-timezone-info-files/webrev.01/webrev/

MethodHandle loop body parameters and Stream.reduce accumulator parameters are not in the same order

Hi everybody, i've just found that the parameters of the body (a MethodHandle) of MethodHandles.countedLoop (both overloads) and iteratedLoop are not in the same order as the accumulator in methods Stream.reduce, given that they conceptually represent the same thing, i think the first two

Re: RFR(s): 4285505: deprecate java.lang.Compiler

Hi Krys, why do you need a public API to send the profile to the JIT compiler ? Rémi - Mail original - > De: "Krystal Mok" > À: "Stuart Marks" > Cc: "core-libs-dev" > Envoyé: Mercredi 14 Septembre 2016

Re: RFR(xs): 8165936: Potential Heap buffer overflow when seaching timezone info files

+1 Naoto On 9/14/16 6:50 AM, Roger Riggs wrote: +1 On 9/14/2016 2:34 AM, Thomas Stüfe wrote: Hi all, thanks for the reviews. Here is version two: http://cr.openjdk.java.net/~stuefe/webrevs/8165936-Potential-Heap-buffer-overflow-when-seaching-timezone-info-files/webrev.01/webrev/

Re: RFR: 8042148: Ensure that the java launcher help is consistent with the manpage where they report common information

Well, comments about -Xcomp and -Xusealtsigs doesn’t seem to require a change, are we good on this webrev? Let me know if there is anything need to change, otherwise, I would need official +1 from reviewers. :) Cheers, Henry On September 8, 2016 at 10:39:13 PM, Alan Bateman

Re: RFR 9: 8155760 Implement Serialization Filtering

Hi Chris, Thanks for the review and comments... On 9/14/2016 5:46 AM, Chris Hegarty wrote: On 08/09/16 20:09, Roger Riggs wrote: Please review updates to the Serialization filtering API and implementation: - The ObjectInputFilter pattern based filters support matching on module names as

Re: JDK 9 RFR of JDK-8166054: Problem list JarURLConnectionUseCaches.java until JDK-8165988 is fixed

Hi Joe, Looks good to me! -- daniel On 14/09/16 18:07, joe darcy wrote: Hello, Until JDK-8165988 is fixed, the test sun/net/www/protocol/jar/JarURLConnectionUseCaches.java should be problem listed on windows. Please review the patch below. Thanks, -Joe --- a/test/ProblemList.txt

Re: RFR(JAXP): 8165784: Deprecate the internal Catalog API in JDK 9

Hi, I don't see there is much point in deprecating an API that is not exported. It doesn't show up in the javadoc and the compiler overrides with -addexports would already be needed. The internal uses should be updated but that should not be a reason to put off warning other consumers that a

Re: RFR(s): 4285505: deprecate java.lang.Compiler

Hi Kris, Based on your email earlier in this thread, it seemed like you didn't object to deprecating j.l.Compiler in Java 9. Since the other respondents were already in favor, I've already pushed the changeset. (Sorry.) As things stand, the changeset is in the jdk9/dev forest, but it's not in

JDK 9 RFR of JDK-8166054: Problem list JarURLConnectionUseCaches.java until JDK-8165988 is fixed

Hello, Until JDK-8165988 is fixed, the test sun/net/www/protocol/jar/JarURLConnectionUseCaches.java should be problem listed on windows. Please review the patch below. Thanks, -Joe --- a/test/ProblemList.txtWed Sep 14 07:37:15 2016 -0700 +++ b/test/ProblemList.txtWed Sep 14

Re: Review Request: JDK-8157464: StackWalker.getCallerClass() is not

Thanks, Mandy - sounds fine. webrev.03 all looks good to me. -Brent On 09/13/2016 05:04 PM, Mandy Chung wrote: Yes that’s one option. JVM_STACKWALK_FILL_CLASS_REFS_ONLY is not necessarily used to get caller class. For example, AccessControlContext is interested in protection domains. We

Re: JDK 9 RFR of JDK-8166054: Problem list JarURLConnectionUseCaches.java until JDK-8165988 is fixed

Sorry Joe, This passed just fine in jprt. I'll change it to othervm now. (I only noticed this problem on 8 last night) -Rob On 14/09/16 06:09, Daniel Fuchs wrote: > Hi Joe, > > Looks good to me! > > -- daniel > > On 14/09/16 18:07, joe darcy wrote: > >Hello, > > > >Until JDK-8165988

Re: RFR: 8042148: Ensure that the java launcher help is consistent with the manpage where they report common information

Henry, Thanks for taking care of this, if the VM team is happy with it. I am good, consider me as reviewer. Thanks Kumar Well, comments about -Xcomp and -Xusealtsigs doesn’t seem to require a change, are we good on this webrev? Let me know if there is anything need to change, otherwise, I

Re: RFR(JAXP): 8165784: Deprecate the internal Catalog API in JDK 9

On 14/09/16 20:09, Joe Wang wrote: Hi Daniel, Roger, Thanks for the review! The webrev is updated as we discussed. The deprecation message is in the main interface classes but stresses that the entire application under the resolver package and the util class (XMLCatalogResolver.java) are

Re: RFR: 8153654: Update jdeps to be multi-release jar aware

> On Sep 13, 2016, at 5:52 PM, Steve Drach wrote: > > The latest web revs. Answers to questions in-line below: > > http://cr.openjdk.java.net/~sdrach/8153654/webrev.10/ > > http://cr.openjdk.java.net/~sdrach/8153654/webrev.jdk/ This looks pretty good. My main comment

Re: RFR(JAXP): 8165784: Deprecate the internal Catalog API in JDK 9

Hi Daniel, Roger, Thanks for the review! The webrev is updated as we discussed. The deprecation message is in the main interface classes but stresses that the entire application under the resolver package and the util class (XMLCatalogResolver.java) are deprecated and subject to removal in a

Re: RFR(JAXP): 8165784: Deprecate the internal Catalog API in JDK 9

Thanks again, Daniel! Joe On 9/14/16, 12:25 PM, Daniel Fuchs wrote: On 14/09/16 20:09, Joe Wang wrote: Hi Daniel, Roger, Thanks for the review! The webrev is updated as we discussed. The deprecation message is in the main interface classes but stresses that the entire application under the

Re: RFR 9: 8165261: RMI API to export an object with a serialization filter

Hi Roger, On 13/09/16 20:10, Roger Riggs wrote: Hi Daniel, Thanks for the review and comments... Webrev updated in place. Looks good to me! best regards, -- daniel

RFR: JDK-8134373: explore potential uses of convenience factories within the JDK

Hi Jonathan, Here are your changes in a webrev: http://cr.openjdk.java.net/~reinhapa/reviews/8134373/webrev.00 -Patrick > Am 13.09.2016 um 14:45 schrieb Patrick Reinhart : > > Hi Jonathan, > > On 2016-09-13

Re: RFR(xs): 8165936: Potential Heap buffer overflow when seaching timezone info files

Hi all, thanks for the reviews. Here is version two: http://cr.openjdk.java.net/~stuefe/webrevs/8165936-Potential-Heap-buffer-overflow-when-seaching-timezone-info-files/webrev.01/webrev/ Only cosmetic changes: - made code pre-c99 compatible - consistently use dirent64 - fix indentation in ifs -

Re: RFR 9: 8155760 Implement Serialization Filtering

On 08/09/16 20:09, Roger Riggs wrote: Please review updates to the Serialization filtering API and implementation: - The ObjectInputFilter pattern based filters support matching on module names as well as package and class names. - Rename of system property and java.security property for

Re: RFR 9: 8165261: RMI API to export an object with a serialization filter

On 12/09/16 21:42, Roger Riggs wrote: Please review an update to enable serialization filtering for exported RMI objects. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-rmi-filter-8165261/ This looks good to me Roger. -Chris.

Re: RFR(JAXP): 8165784: Deprecate the internal Catalog API in JDK 9

Hi Joe, As much as I would like to support removing obsolete classes, I wonder if the forRemoval=true is a bit premature. I see that for instance, com.sun.org.apache.xml.internal.resolver.Catalog seems to be still used at many places in our code base. It would be more convincing if we could

Re: Review Request: JDK-8157464: StackWalker.getCallerClass() is not

Hi Mandy, webrev.03 looks good to me! best regards, -- daniel On 14/09/16 01:04, Mandy Chung wrote: Yes that’s one option. JVM_STACKWALK_FILL_CLASS_REFS_ONLY is not necessarily used to get caller class. For example, AccessControlContext is interested in protection domains. We could build

Re: RFR(JAXP): 8165784: Deprecate the internal Catalog API in JDK 9

Hi Joe, I will review it in more details but here is an early feedback: 66 * href="http://download.java.net/java/jdk9/docs/api/javax/xml/catalog/package-summary.html;> 67 * new public API. The following should work (it did in the past, might be worth checking that it still does): *

Re: RFR: 8153654: Update jdeps to be multi-release jar aware

The most recent webrev is http://cr.openjdk.java.net/~sdrach/8153654/webrev.11/ Comments inline >> The latest web revs. Answers to questions in-line below: >> >> http://cr.openjdk.java.net/~sdrach/8153654/webrev.10/ >> >>