RFR: 8043306 - Provide a replacement for the API that allowed to listen for LogManager configuration changes

Hi, Please find below a proposed patch for 8043306 - Provide a replacement for the API that allowed to listen for LogManager configuration changes https://bugs.openjdk.java.net/browse/JDK-8043306 Proposed Patch: http://cr.openjdk.java.net/~dfuchs/webrev_8043306/webrev.00/ JDK-8029805

RFR (S) 8057936: java.net.URLClassLoader.findClass uses exceptions in control flow

Hi, please review this simple patch to avoid raising PrivilegedActionExceptions when failing to find a class in URLClassLoader. bug: https://bugs.openjdk.java.net/browse/JDK-8057936 webrev: http://cr.openjdk.java.net/~redestad/8057936/webrev.2/ /Claes

Re: RFR (S) 8057936: java.net.URLClassLoader.findClass uses exceptions in control flow

On 09/10/2014 02:11 PM, Claes Redestad wrote: > please review this simple patch to avoid raising PrivilegedActionExceptions > when failing to find a class in URLClassLoader. > > bug: https://bugs.openjdk.java.net/browse/JDK-8057936 > webrev: http://cr.openjdk.java.net/~redestad/8057936/webrev.2/

Re: RFR (S) 8057936: java.net.URLClassLoader.findClass uses exceptions in control flow

On 10/09/2014 11:11, Claes Redestad wrote: Hi, please review this simple patch to avoid raising PrivilegedActionExceptions when failing to find a class in URLClassLoader. bug: https://bugs.openjdk.java.net/browse/JDK-8057936 webrev: http://cr.openjdk.java.net/~redestad/8057936/webrev.2/ I t

Re: RFR (S) 8057936: java.net.URLClassLoader.findClass uses exceptions in control flow

If a lambda were used instead of an anonymous class, it would save us one line of code :-) Sincerely yours, Ivan On 10.09.2014 14:11, Claes Redestad wrote: Hi, please review this simple patch to avoid raising PrivilegedActionExceptions when failing to find a class in URLClassLoader. bug

Re: RFR (S) 8057936: java.net.URLClassLoader.findClass uses exceptions in control flow

I think lambda would not help much since target type is ambiguous (PrivilegedAction vs PrivilegedExceptionAction)? -Aleksey. On 09/10/2014 02:55 PM, Ivan Gerasimov wrote: > > If a lambda were used instead of an anonymous class, it would save us > one line of code :-) > > Sincerely yours, > Ivan

Re: RFR (S) 8057936: java.net.URLClassLoader.findClass uses exceptions in control flow

On 10.09.2014 14:58, Aleksey Shipilev wrote: I think lambda would not help much since target type is ambiguous (PrivilegedAction vs PrivilegedExceptionAction)? It could be explicitly cast as (PrivilegedAction) () -> {...} Would still be on the same line :-) Ivan -Aleksey. On 09/10/2014 0

Re: RFR (S) 8057936: java.net.URLClassLoader.findClass uses exceptions in control flow

On 10/09/2014 11:55, Ivan Gerasimov wrote: If a lambda were used instead of an anonymous class, it would save us one line of code :-) I don't know if a lambda would help here but I think changing would require a lot of testing to make sure that there aren't any side effects. We've had a cou

Re: RFR (S) 8057936: java.net.URLClassLoader.findClass uses exceptions in control flow

or how about just returning a null Class from the privileged block instead of the new result type only in the case where URLClassPath.getResource() returns null? That's the main "normal" case where the resource doesn't exist, I think. If defineClass() throws an IOException, then that is more li

Re: RFR: 8043306 - Provide a replacement for the API that allowed to listen for LogManager configuration changes

On 10/09/2014 10:49, Daniel Fuchs wrote: Hi, Please find below a proposed patch for 8043306 - Provide a replacement for the API that allowed to listen for LogManager configuration changes https://bugs.openjdk.java.net/browse/JDK-8043306 Proposed Patch: http://cr.openjdk.java.net/~dfu

Re: RFR: 8043306 - Provide a replacement for the API that allowed to listen for LogManager configuration changes

On 9/10/14 1:25 PM, Alan Bateman wrote: On 10/09/2014 10:49, Daniel Fuchs wrote: Hi, Please find below a proposed patch for 8043306 - Provide a replacement for the API that allowed to listen for LogManager configuration changes https://bugs.openjdk.java.net/browse/JDK-8043306 Propos

Re: [9] RFR (L): 8057042: LambdaFormEditor: derive new LFs from a base LF

On 09/03/2014 03:25 PM, Vladimir Ivanov wrote: Peter, Thanks for the feedback. > In LambdaFormEditor, where Transform[] is promoted into ConcurrentHashMap: 339 ConcurrentHashMap m = new ConcurrentHashMap<>(MAX_CACHE_ARRAY_SIZE * 2); 340 for (Transfo

Re: RFR: 8043306 - Provide a replacement for the API that allowed to listen for LogManager configuration changes

New webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8043306/webrev.01 -- daniel On 9/10/14 1:42 PM, Daniel Fuchs wrote: On 9/10/14 1:25 PM, Alan Bateman wrote: On 10/09/2014 10:49, Daniel Fuchs wrote: Hi, Please find below a proposed patch for 8043306 - Provide a replacement for the API

Re: RFR (S) 8057936: java.net.URLClassLoader.findClass uses exceptions in control flow

Yes, this saves creating the type and wrapper object altogether, while testing suggest it's only the getResource() == null cases wecommonly seehurting startup in our tests. I'd say let's go with your patch. New webrev: http://cr.openjdk.java.net/~redestad/8057936/webrev.4/ Benchmark referred t

Re: [9] RFR 8055251: Re-examine Integer.parseInt and Long.parseLong methods

On 09/05/2014 03:49 PM, Alan Bateman wrote: On 05/09/2014 14:03, Claes Redestad wrote: Hi, I'm requesting reviews and a sponsor for these changes to the recently added parse methods (8041972), suggested during discussions on net-dev: bug: https://bugs.openjdk.java.net/browse/JDK-8055251 webrev

Re: RFR: 8043306 - Provide a replacement for the API that allowed to listen for LogManager configuration changes

On Sep 10, 2014, at 1:42 PM, Daniel Fuchs wrote: > On 9/10/14 1:25 PM, Alan Bateman wrote: >> On 10/09/2014 10:49, Daniel Fuchs wrote: >>> Hi, >>> >>> Please find below a proposed patch for >>> >>> 8043306 - Provide a replacement for the API that allowed to listen >>> for LogManager c

Re: RFR (S) 8057936: java.net.URLClassLoader.findClass uses exceptions in control flow

Hi Claes, On 10/09/2014 8:11 PM, Claes Redestad wrote: Hi, please review this simple patch to avoid raising PrivilegedActionExceptions when failing to find a class in URLClassLoader. bug: https://bugs.openjdk.java.net/browse/JDK-8057936 webrev: http://cr.openjdk.java.net/~redestad/8057936/

Re: RFR (S) 8057936: java.net.URLClassLoader.findClass uses exceptions in control flow

On 09/10/2014 03:53 PM, Claes Redestad wrote: > Yes, this saves creating the type and wrapper object altogether, > while testing suggest it's only the getResource() == null cases we > commonly see hurting startup in our tests. I'd say let's go with your > patch. > New webrev: http://cr.openjdk.jav

Re: RFR (S) 8057936: java.net.URLClassLoader.findClass uses exceptions in control flow

On 10/09/2014 10:30 PM, David Holmes wrote: Hi Claes, On 10/09/2014 8:11 PM, Claes Redestad wrote: Hi, please review this simple patch to avoid raising PrivilegedActionExceptions when failing to find a class in URLClassLoader. bug: https://bugs.openjdk.java.net/browse/JDK-8057936 webrev:

Re: [9] RFR 8055251: Re-examine Integer.parseInt and Long.parseLong methods

On 09/10/2014 01:55 PM, Claes Redestad wrote: On 09/05/2014 03:49 PM, Alan Bateman wrote: On 05/09/2014 14:03, Claes Redestad wrote: Hi, I'm requesting reviews and a sponsor for these changes to the recently added parse methods (8041972), suggested during discussions on net-dev: bug: https:/

Re: RFR: 8043306 - Provide a replacement for the API that allowed to listen for LogManager configuration changes

On 9/10/14 2:25 PM, Paul Sandoz wrote: FWIW i think you could do: removeIf(e -> listener == e); Ah ah. Interesting! Idiomatically callback methods are often prefixed with on: onConfigurationLoaded. Thanks! Exactly what I was looking for :-) I'll wait for more comments before updati

Re: [9] RFR (L): 8057042: LambdaFormEditor: derive new LFs from a base LF

Peter, I think line 341 is wrong. It should be: if (k == null) break; shouldn't it? Good catch! Fixed. I think it can even be removed or replaced with something like: assert k != null; ...since null entry in array is not possible in this situation - promotion to CHM happens onl

RE: RFR: 8043306 - Provide a replacement for the API that allowed to listen for LogManager configuration changes

Daniel I think you should be able to remove the 'other instanceof ConfigurationListener' branch in the ConfigurationListener.equals method. Should work the same with or without that branch. Jason > Date: Wed, 10 Sep 2014 11:49:51 +0200 > From: dan

Re: RFR: 8043306 - Provide a replacement for the API that allowed to listen for LogManager configuration changes

On 9/10/14 4:28 PM, Jason Mehrens wrote: Daniel I think you should be able to remove the 'other instanceof ConfigurationListener' branch in the ConfigurationListener.equals method. Should work the same with or without that branch. Oh yes. I put it there just to avoid it being flagged by Ne

Re: RFR(S): 8055032: Improve numerical parsing in java.net and sun.net

Hi, the parseInt/parseLong API was changed[1] in accordance with the discussion in this thread. That big shuffling around of modules also happened, so I've updated this patch: http://cr.openjdk.java.net/~redestad/8055032/webrev.1/ /Claes [1] https://bugs.openjdk.java.net/browse/JDK-8055251

Re: RFR (S) 8057936: java.net.URLClassLoader.findClass uses exceptions in control flow

On 09/10/2014 04:38 PM, mark.reinh...@oracle.com wrote: New webrev: http://cr.openjdk.java.net/~redestad/8057936/webrev.4/ Looks fine, but when an exception declaration is on its own line then the opening brace of the method should be on its own line too, as in the original: protected Clas

Re: RFR (S) 8057936: java.net.URLClassLoader.findClass uses exceptions in control flow

On 10/09/14 16:04, Claes Redestad wrote: On 09/10/2014 04:38 PM, mark.reinh...@oracle.com wrote: New webrev: http://cr.openjdk.java.net/~redestad/8057936/webrev.4/ Looks fine, but when an exception declaration is on its own line then the opening brace of the method should be on its own line too

Re: RFR (S) 8057936: java.net.URLClassLoader.findClass uses exceptions in control flow

On 10/09/2014 16:04, Claes Redestad wrote: Original had weird 5 space indentation though: http://cr.openjdk.java.net/~redestad/8057936/webrev.6/ Will need a sponsor for this, if it looks good to everyone. Michael's suggestion was good, it much simpler now. -Alan.

Re: [9] RFR (L): 8057042: LambdaFormEditor: derive new LFs from a base LF

On 09/03/2014 03:29 PM, Vladimir Ivanov wrote: Peter, Yes, it's a known problem [1]. There are other caches (in MethodTypeForm, for example), which shouldn't retain their elements. Hi Vladimir, I was tempted to see what it would take to use weakly referenced LambdaForms from cache entries (

Re: RFR (S) 8057936: java.net.URLClassLoader.findClass uses exceptions in control flow

On 9/10/2014 8:04 AM, Claes Redestad wrote: http://cr.openjdk.java.net/~redestad/8057936/webrev.6/ Looks good. A simple change gives 4-12% gains from your microbenchmark - pretty good. Mandy

Re: Replace uses of StringBuffer with StringBuilder[JAXP]

Hi Otavio, I'm glad to know you're interested in contributing to the JAXP project. The JAXP standalone itself has reached end-of-life. We're now concentrating on JAXP in OpenJDK. The repo is here: http://hg.openjdk.java.net/jdk9/dev/jaxp If you are interested in contributing to OpenJDK/jaxp,

Re: Replace uses of StringBuffer with StringBuilder[JAXP]

Hi Wang. Thank you for this information. I have the OCA On Sep 10, 2014 2:11 PM, "huizhe wang" wrote: > Hi Otavio, > > I'm glad to know you're interested in contributing to the JAXP project. > The JAXP standalone itself has reached end-of-life. We're now concentrating > on JAXP in OpenJDK. The re

Re: About JDK-8042694

David, Thanks for the response. In my case, the class loading that fails is for loading the hook's class itself. The hook is not doing anything fancy as far as I can see. For a database trying to make a best effort at saving data, shutdown ability seems like a highly desirable feature to me. ​bes

XMLScanner-supplementary-characters

Hi Huizhe, I have a strange contribution to share. Webrev: http://cr.openjdk.java.net/~martin/webrevs/openjdk9/XMLScanner-supplementary-characters/ But I don't have a bug or a test case that I can share and I don't understand the code, except that it's a fix for supporting supplementary characte

Re: XMLScanner-supplementary-characters

Thanks Martin! Looks like the initial version of the jaxp port (from Xerces 2.7.1) missed the patch for reasons I don't know. I created a bug based on the very original bug report: https://bugs.openjdk.java.net/browse/JDK-8058175 Would you want to push the change into jdk9's jaxp repo? Thank

Re: Replace uses of StringBuffer with StringBuilder[JAXP]

Hi Otavio, Please let me know once you've submitted it. Best, Joe On 9/10/2014 10:40 AM, Otávio Gonçalves de Santana wrote: Hi Wang. Thank you for this information. I have the OCA On Sep 10, 2014 2:11 PM, "huizhe wang" > wrote: Hi Otavio, I'm glad to

Re: XMLScanner-supplementary-characters

On Wed, Sep 10, 2014 at 3:11 PM, huizhe wang wrote: > Thanks Martin! > > Looks like the initial version of the jaxp port (from Xerces 2.7.1) missed > the patch for reasons I don't know. I created a bug based on the very > original bug report: > https://bugs.openjdk.java.net/browse/JDK-8058175 > >

Re: XMLScanner-supplementary-characters

On 9/10/2014 3:20 PM, Martin Buchholz wrote: On Wed, Sep 10, 2014 at 3:11 PM, huizhe wang > wrote: Thanks Martin! Looks like the initial version of the jaxp port (from Xerces 2.7.1) missed the patch for reasons I don't know. I created a bug bas

Re: XMLScanner-supplementary-characters

Thanks! Pushed. On Wed, Sep 10, 2014 at 4:14 PM, huizhe wang wrote: > > On 9/10/2014 3:20 PM, Martin Buchholz wrote: > > > > On Wed, Sep 10, 2014 at 3:11 PM, huizhe wang > wrote: > >> Thanks Martin! >> >> Looks like the initial version of the jaxp port (from Xerces 2.7.1) >> missed the patch f

Re: RFR: JDK-8056934: ZipInputStream does not correctly handle local header data descriptors with the optional signature missing

> > > For the comment in ZipInputStream then it might be better to move that to > readEnd. My preference would be to not include the part starting "As of > 2014-08, phyton ..." as that might not interesting in years to come. I moved the comment into readEnd's javadoc. I think laying out the comp

Re: RFR: JDK-8056934: ZipInputStream does not correctly handle local header data descriptors with the optional signature missing

I tried and failed to expand the test to do ZIP64 as well - I ran into 32-bit limitations in python. The test is useful, but too brittle to be a permanent jtreg test, so I @ignored it. I'm ready to submit this.