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

Hi, Please review the deprecation of the internal Catalog API. JBS: https://bugs.openjdk.java.net/browse/JDK-8165784 webrev: http://cr.openjdk.java.net/~joehw/jdk9/8165784/webrev/ Thanks, Joe

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

Line 137: The declaration of "min" cannot follow statements (not all platforms support C99). It has to move up around line 131. Naoto On 9/13/16 5:28 PM, Naoto Sato wrote: Hi Thomas, Another cosmetic comment: please use 4 space indentation inside those "if" clauses. Otherwise, +1. Naoto On

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

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

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

Hi Thomas, Another cosmetic comment: please use 4 space indentation inside those "if" clauses. Otherwise, +1. Naoto On 9/13/16 7:49 AM, Thomas Stüfe wrote: Hi Christoph, thanks for your review! Yes, I can remove the blank. Kind Regards, Thomas On Tue, Sep 13, 2016 at 2:35 PM, Langer,

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

Hi OpenJDK developers, Replying on behalf of Azul Systems: java.lang.Compiler is an integral part of the current Java SE spec, and is currently being used by multiple independent Java SE implementations of that spec in a spec-conforming way (Azul Zing, Azul Vega, and IBM J9 being concrete

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

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 a specialized impl class to walk the stack fetching Class only whereas getCallerClass will stop walking

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

Hi, Mandy Is a new JVM_STACKWALK_GET_CALLER_CLASS bit needed in jvm.h? AFAICT, JVM_STACKWALK_FILL_CLASS_REFS_ONLY is already only set for the getCallerClass() case. Could the new get_caller_class() instead check if JVM_STACKWALK_FILL_CLASS_REFS_ONLY is set? (Yes, this would be a third

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

Hi Daniel, StackWalker::getCallerClass is a convenient method to find the caller class and is specified to skip the hidden frames (that’s the caller we are interested in). Since StackWalker only asks VM to fill in classes, the library can’t tell if it’s an anonymous class or not. Your

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

Hi Daniel, Thanks for the review and comments... Webrev updated in place. On 9/13/2016 6:14 AM, Daniel Fuchs wrote: Hi Roger, On 12/09/16 21:42, Roger Riggs wrote: Please review an update to enable serialization filtering for exported RMI objects. Webrev:

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

Hi Mandy, This looks good to me. But I wonder about these 5 lines - isn't this introducing a change of behavior if the caller is an anonymous class? 149 InstanceKlass* ik = method->method_holder(); 150 if (ik->is_anonymous()) { 151 // use the host class as the caller

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

Webrev: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8157464/webrev.01 This revises the proposal posted some time ago [1]. StackWalker::getCallerClass is a convenient method to find the caller class. It will return the invoker of the MethodHandle and java.lang.reflect.Method for the method

Re: RFR 9: 8155760 Implement Serialization Filtering

Hi Daniel, Thanks for the suggestion, fixed. Roger On 9/13/2016 4:57 AM, Daniel Fuchs wrote: Hi Roger, Looks good! One nit: In ObjectInputFilter.java, links to Status. should probably use @link instead of @linkplain - e.g {@linkplain Status#REJECTED REJECTED} or {@linkplain

Re: RFR: 8163798: Create a JarFile versionedStream method

> On Sep 12, 2016, at 5:14 PM, Steve Drach wrote: > > http://cr.openjdk.java.net/~sdrach/8163798/webrev.06/ > +1 Mandy

Re: RFR: 8163798: Create a JarFile versionedStream method

> On 12 Sep 2016, at 17:14, Steve Drach wrote: > > I guess I’m going to keep doing this until I get it right ;-) Here’s another > webrev that doesn’t use an exception for a common case, and addresses most of > Mandy concerns. > >

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

Looks good to me. Thank you for fixing this bug! Masayoshi On 9/13/2016 11:49 PM, Thomas Stüfe wrote: Hi Christoph, thanks for your review! Yes, I can remove the blank. Kind Regards, Thomas On Tue, Sep 13, 2016 at 2:35 PM, Langer, Christoph

Re: RFR 8164705: Remove pathname canonicalization from FilePermission

Not really. Will continue with it. I’m not sure whether Alan is done with it either. Brian On Sep 12, 2016, at 8:34 PM, Weijun Wang wrote: > Have you finished the deeper pass? :-) > > Thanks > Max > > On 9/2/2016 8:18, Brian Burkhalter wrote: >> At the API level and

Re: RFR: 6543126: Level.known can leak memory

Thanks Mandy! On 13/09/16 15:56, Mandy Chung wrote: The new webrev.05 looks good. On Sep 13, 2016, at 5:45 AM, Daniel Fuchs wrote: Hi Mandy, Here is a new webrev with your feedback integrated. Finally I managed to get rid of the InternalError in MethodHandle by

Re: RFR: 6543126: Level.known can leak memory

The new webrev.05 looks good. > On Sep 13, 2016, at 5:45 AM, Daniel Fuchs wrote: > > Hi Mandy, > > Here is a new webrev with your feedback integrated. > > Finally I managed to get rid of the InternalError in MethodHandle > by using: > PrivilegedAction pa =

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

Hi Christoph, thanks for your review! Yes, I can remove the blank. Kind Regards, Thomas On Tue, Sep 13, 2016 at 2:35 PM, Langer, Christoph wrote: > Hi Thomas, > > your change looks good. I'm also forwarding this to i18n-dev as issues in > TimeZone implementation are

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

Hi Roger, thanks for the review! You are right, I will use dirent64 in offsetof. Kind Regards, Thomas On Tue, Sep 13, 2016 at 4:03 PM, Roger Riggs wrote: > Hi Thomas, > > One minor point, it seems a bit asymmetric (@line 150) to cast to dirent64 > but use dirent in the

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

Hi Thomas, One minor point, it seems a bit asymmetric (@line 150) to cast to dirent64 but use dirent in the offsetof calculation. Otherwise, looks fine. Roger On 9/13/2016 8:35 AM, Langer, Christoph wrote: Hi Thomas, your change looks good. I'm also forwarding this to i18n-dev as issues

Re: [PATCH] JDK-8134373: explore potential uses of convenience factories within the JDK

Hi Jonathan, On 2016-09-13 02:13, Jonathan Bluett-Duncan wrote: Hi Patrick, Thank you very much for the offer to hold my patch for me! No problem. Is it common practice to send patches to others using PGP? No, this is my personal setting. Kind regards, Jonathan On 12 September 2016

Re: RFR: 6543126: Level.known can leak memory

Hi Mandy, Here is a new webrev with your feedback integrated. Finally I managed to get rid of the InternalError in MethodHandle by using: PrivilegedAction pa = () -> customLevel.getClass().getClassLoader(); instead of PrivilegedAction pa =

Re: [8u] RFR(XXS): 8165231: java.nio.Bits.unaligned() doesn't return true on ppc

Sounds good Volker. Good catch. regards, Sean. On 13/09/2016 13:09, Volker Simonis wrote: Hi Sean, thanks a lot for the fast response. I've updated the bug entry as requested and will push the change - maybe with the following potential improvement: @Hiroshi: also maybe not that performance

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

Hi Thomas, your change looks good. I'm also forwarding this to i18n-dev as issues in TimeZone implementation are mostly handled there. One remark: Can you take the opportunity to also remove the blank between the cast and malloc in line 150: "(struct dirent64 *) malloc..."? Unfortunately I'm

Re: [8u] RFR(XXS): 8165231: java.nio.Bits.unaligned() doesn't return true on ppc

Hi Sean, thanks a lot for the fast response. I've updated the bug entry as requested and will push the change - maybe with the following potential improvement: @Hiroshi: also maybe not that performance relevant, I think we should we also fix sun/security/provider/ByteArrayAccess.java which

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

Dear all, please take a look at this small change: Bug: https://bugs.openjdk.java.net/browse/JDK-8165936 Webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8165936-Potential-Heap-buffer-overflow-when-seaching-timezone-info-files/webrev.00/webrev/ readdir_r is used to iterate over the content of

Re: [8u] RFR(XXS): 8165231: java.nio.Bits.unaligned() doesn't return true on ppc

Hi Volker, The fix looks fine to me. Please add the '9-na' label to the bug report. Also add a suitable noreg- label. It would also be useful to link the issue to JDK-8158260 Approved for jdk8u-dev. regards, Sean. On 13/09/2016 09:37, Volker Simonis wrote: Hi Alan, Sean, can we please

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

Hi Roger, 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/ Issue: https://bugs.openjdk.java.net/browse/JDK-8165261 Thanks, Roger In

Re: RFR 9: 8155760 Implement Serialization Filtering

Hi Roger, Looks good! One nit: In ObjectInputFilter.java, links to Status. should probably use @link instead of @linkplain - e.g {@linkplain Status#REJECTED REJECTED} or {@linkplain Status#REJECTED Status.REJECTED} should probably be @link to make the constants appear in code font. No

[8u] RFR(XXS): 8165231: java.nio.Bits.unaligned() doesn't return true on ppc

Hi Alan, Sean, can we please get a review for this rather trivial change? > jira: https://bugs.openjdk.java.net/browse/JDK-8165231 > webrev: http://cr.openjdk.java.net/~gromero/8165231/ As outlined in Hiroshi's initial mail, we can not simply downport the solution used in jdk9 for querying the