RFR of JDK-8176563: @since value errors in apis of java.base/java.logging module

Would you please review the below patch? bug: https://bugs.openjdk.java.net/browse/JDK-8176563 webrev: http://cr.openjdk.java.net/~mli/8176563/webrev.00/ Thank you -Hamlin

RFR of JDK-8176721: @since value errors java.sql module

Would you please review the below patch? bug: https://bugs.openjdk.java.net/browse/JDK-8176721 webrev: http://cr.openjdk.java.net/~mli/8176721/webrev.00/ Thank you -Hamlin

Re: Review request 8153912: StackFrame::getFileName and StackFrame::getLineNumber not needed

I have fixed the test that located the caller’s Class object with StackWalker. It is now faster than Reflection.getCallerClass() was. I have also created a test to get the Caller’s StackTraceElement with StackWalker. It is now much, much faster than walking the Throwable was in Java 8, so that

Re: RFR of JDK-8176566: @since value errors in types of java.base module

Hi Martin, On 2017/3/14 11:53, Martin Buchholz wrote: Thanks, Thank you. 10 years ago I fixed most of the @since mistakes using a hacky script, that may still be floating around at Oracle. I'm curious to see how you implemented it. I write a doclet in java which scans all the jdk versions

Re: RFR(L) : 8176176 : fix @modules in jdk_svc tests

Shura, Thank you for review, I agree that having separate bugs is more convenient. [1] is new webrev w/ changes only in the files w/ incorrect module dependency declarations. [1] http://cr.openjdk.java.net/~iignatyev//8176176/webrev.01/index.html

Re: RFR of JDK-8176566: @since value errors in types of java.base module

Thanks, 10 years ago I fixed most of the @since mistakes using a hacky script, that may still be floating around at Oracle. I'm curious to see how you implemented it. There's already a place to put tools like this; e.g. there's my own common/bin/blessed-modifier-order.sh I agree that now is a g

Re: RFR of JDK-8176566: @since value errors in types of java.base module

On 2017/3/14 11:25, Martin Buchholz wrote: Hi Hamlin, You probably did this using a tool - what is it? Is the tool part of openjdk? Hi Martin, Yes, I'm using a tool which I just implemented, it's not part of openjdk currently. If you have a tool, you can fairly easily fix all the code main

Re: RFR of JDK-8176566: @since value errors in types of java.base module

Hi Hamlin, You probably did this using a tool - what is it? Is the tool part of openjdk? If you have a tool, you can fairly easily fix all the code maintained by the openjdk project. You're fixing JDK-8164058 , so consider taking ownership of that

RFR of JDK-8176566: @since value errors in types of java.base module

Would you please review the below patch? bug: https://bugs.openjdk.java.net/browse/JDK-8176566 webrev: http://cr.openjdk.java.net/~mli/8176566/webrev.00/ Thank you -Hamlin

Re: RFR: testCommonPoolThreadContextClassLoader fails with "Should throw SecurityException"

Thank you Martin for the quick fix, looks good. Thanks, Amy On 3/14/17 7:04 AM, Martin Buchholz wrote: flaky test bug fix for jdk9 https://bugs.openjdk.java.net/browse/JDK-8176551 ttp://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-integration/testCommonPoolThreadContextClassLoader/

Re: RFR: 8176508 Update JAX-WS RI integration to latest version

Hi all, Additional minor comments on top of what others already provided MimetypesFileTypeMap.java - Are the Parens around lines 54-57 really needed? - defaultType and confDir, shouldn’t these be all caps like PROG? - For the doPrivileged method, not sure the minimum JDK

Re: RFR: testCommonPoolThreadContextClassLoader fails with "Should throw SecurityException"

Looks good to me Martin! Thanks, David On 14/03/2017 9:04 AM, Martin Buchholz wrote: flaky test bug fix for jdk9 https://bugs.openjdk.java.net/browse/JDK-8176551 ttp://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-integration/testCommonPoolThreadContextClassLoader/

RFR: testCommonPoolThreadContextClassLoader fails with "Should throw SecurityException"

flaky test bug fix for jdk9 https://bugs.openjdk.java.net/browse/JDK-8176551 ttp://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-integration/testCommonPoolThreadContextClassLoader/

Re: RFR 9: 8165641 : Deprecate Object.finalize

As Dr Deprecator, I approve of this change. :-) One small comment. Deprecation warnings aren't issued at the use site of a deprecated API if the use site itself is deprecated. Thus, the @SuppressWarnings annotation isn't necessary in the following diff hunk: --- old/src/java.base/share/clas

Re: Review request 8153912: StackFrame::getFileName and StackFrame::getLineNumber not needed

Hi Ralph, I have filed https://bugs.openjdk.java.net/browse/JDK-8176593 for Throwable::getStackTrace performance regression. > On Mar 13, 2017, at 1:57 PM, Daniel Fuchs wrote: > > Hi Ralph, > > On 13/03/17 19:06, Ralph Goers wrote: >> OK - I will do that when I fix the other bug. But if you

JDK 9 RFR: 8066640: clarify security checks in ObjectInputStream.enableResolveObject

.. and ObjectOutputStream.enableReplaceObject. https://bugs.openjdk.java.net/browse/JDK-8066640 Please review this small spec change for these methods. This aligns the specification to be in agreement with the actual implementation. Essentially the change replaces the current wording: << If

Re: RFR 9: 8165641 : Deprecate Object.finalize

On 3/13/17 5:17 AM, Andrew Dinn wrote: On 13/03/17 12:15, Andrew Dinn wrote: On 12/03/17 09:55, Andrew Haley wrote: Oh, absolutely, I know about that. I was just wondering why now, and is this something you just came up with, and are we going to have the compatibility discussion? Perhaps n

RE: RFR: 8176508 Update JAX-WS RI integration to latest version

Hi, Bill. >> 59 * (Where java.home is the value of the "java.home" System >> property >> 60 * and conf is the directory named "conf" if it exists, >> 61 * otherwise the directory named "lib"; the "conf" directory was >> 62 * introduced in JDK 1.9.) In line 62, can we change "JDK 1.9"

Re: Review request 8153912: StackFrame::getFileName and StackFrame::getLineNumber not needed

Hi Ralph, On 13/03/17 19:06, Ralph Goers wrote: OK - I will do that when I fix the other bug. But if you can suggest some other way to bail out of the loop after I have found the correct StackFrame that would help as well. I'd suggest using filter + findFirst, possibly with a statefull Pre

Re: Review request 8153912: StackFrame::getFileName and StackFrame::getLineNumber not needed

> On Mar 13, 2017, at 12:04 PM, Daniel Fuchs wrote: > > Hi Ralph, > > I see one issue in your benchmark: > > StackWalker walker = > StackWalker.getInstance(StackWalker.Option.RETAIN_CLASS_REFERENCE); > > will return a new StackWalker every time it's called. > I'd suggest to create the StackW

Re: JDK 9 RFR of 8176221: Preferences docs contain reference to Sun's JRE

Looks good Brian; thanks, -Joe On 3/13/2017 12:44 PM, Brian Burkhalter wrote: Please review this simple doc-only change for [1]: --- a/src/java.prefs/share/classes/java/util/prefs/Preferences.java +++ b/src/java.prefs/share/classes/java/util/prefs/Preferences.java @@ -188,8 +188,8 @@ * admi

JDK 9 RFR of 8176221: Preferences docs contain reference to Sun's JRE

Please review this simple doc-only change for [1]: --- a/src/java.prefs/share/classes/java/util/prefs/Preferences.java +++ b/src/java.prefs/share/classes/java/util/prefs/Preferences.java @@ -188,8 +188,8 @@ * administrator to replace the default preferences implementation with an * alternative

Re: RFR 9: 8165641 : Deprecate Object.finalize

> On Mar 11, 2017, at 1:56 PM, Hans Boehm wrote: > Stepping back, I'm a little surprised at the deprecation. In my opinion, > the problems with finalizers are, in rough order of significance: I think an important difference between finalize and other j.l.r.Reference-based cleanups that hasn't bee

Re: Review request 8153912: StackFrame::getFileName and StackFrame::getLineNumber not needed

Hi Ralph, I see one issue in your benchmark: StackWalker walker = StackWalker.getInstance(StackWalker.Option.RETAIN_CLASS_REFERENCE); will return a new StackWalker every time it's called. I'd suggest to create the StackWalker only once and put it in a private (or package) static. This will el

Re: Review request 8153912: StackFrame::getFileName and StackFrame::getLineNumber not needed

> On Mar 13, 2017, at 11:54 AM, Ralph Goers wrote: > > >> On Mar 13, 2017, at 11:52 AM, Ralph Goers wrote: >> >>> >>> On Mar 13, 2017, at 11:32 AM, Daniel Fuchs wrote: >>> >>> Hi Ralph, >>> >>> On 13/03/2017 04:25, Ralph Goers wrote: Sorry for not getting back sooner but I finally fo

Re: Review request 8153912: StackFrame::getFileName and StackFrame::getLineNumber not needed

> On Mar 13, 2017, at 11:52 AM, Ralph Goers wrote: > >> >> On Mar 13, 2017, at 11:32 AM, Daniel Fuchs wrote: >> >> Hi Ralph, >> >> On 13/03/2017 04:25, Ralph Goers wrote: >>> Sorry for not getting back sooner but I finally found some time to follow >>> up. >>> >>> I took a look at >>> htt

Re: RFR: 8176508 Update JAX-WS RI integration to latest version

Alan Bateman wrote on 03/12/17 08:14 AM: > In MailcapCommandMap then the following doesn't seem right for the class > description: > > 59 * (Where java.home is the value of the "java.home" System > property > 60 * and conf is the directory named "conf" if it exists, > 61 * otherwise the

Re: Review request 8153912: StackFrame::getFileName and StackFrame::getLineNumber not needed

> On Mar 13, 2017, at 11:32 AM, Daniel Fuchs wrote: > > Hi Ralph, > > On 13/03/2017 04:25, Ralph Goers wrote: >> Sorry for not getting back sooner but I finally found some time to follow up. >> >> I took a look at >> https://www.sitepoint.com/deep-dive-into-java-9s-stack-walking-api/ >>

Re: Review request 8153912: StackFrame::getFileName and StackFrame::getLineNumber not needed

Hi Ralph, On 13/03/2017 04:25, Ralph Goers wrote: Sorry for not getting back sooner but I finally found some time to follow up. I took a look at https://www.sitepoint.com/deep-dive-into-java-9s-stack-walking-api/ and modifie

Re: Review request 8153912: StackFrame::getFileName and StackFrame::getLineNumber not needed

On 2017-03-13 16:56, Mandy Chung wrote: On Mar 12, 2017, at 9:25 PM, Ralph Goers wrote: 1. Walking the Throwable StackTraceElements is significantly faster in Java 8 than Java 9. I am not sure what benchmark Brent used but my results differ. I’ll be surprised if jdk 9 Throwable is slower

JDK 9 VarHandle memory mode usage guide

[Reposting from concurrency-interest list] As may recall, JDK 9 VarHandles with new memory modes were incorporated without a full overhaul of the Java Memory Model that would be needed to formally specify them. For the past year or so I've been sporadically working on an expert-programmer guide

Re: Review request 8153912: StackFrame::getFileName and StackFrame::getLineNumber not needed

> On Mar 12, 2017, at 9:25 PM, Ralph Goers wrote: > > Sorry for not getting back sooner but I finally found some time to follow up. > > I took a look at > https://www.sitepoint.com/deep-dive-into-java-9s-stack-walking-api/ >

Re: RFR 9: 8165641 : Deprecate Object.finalize

Hi, A reasonably complete treatment of finalizers and suggestions for correct use are in Josh Bloch' Effective Java. It may be a bit dated but is a good start for the casual reader. Josh provided an excerpt: http://www.informit.com/articles/article.aspx?p=1216151&seqNum=7 There is a lot more

Re: RFR 9: 8165641 : Deprecate Object.finalize

On 03/12/2017 07:55 PM, Hans Boehm wrote: But I think we agree that it doesn't matter for this discussion; neither of these problems are addressed by deprecating finalizers. PhantomReferences have exactly the same issues. ... The motivation seems more along the lines of "denigration" vs deprec

Re: RFR 9: 8165641 : Deprecate Object.finalize

In regards to the optimized-out "this" stuff - remember that a while ago Paul Sandoz introduced java.lang.ref.Reference#reachabilityFence()... On 03/12/2017 06:55 PM, Hans Boehm wrote: I agree that's indeed a solvable problem, perhaps not terribly elegantly, but without too much user-visible co

Re: RFR 9: 8165641 : Deprecate Object.finalize

On 13/03/17 12:15, Andrew Dinn wrote: > On 12/03/17 09:55, Andrew Haley wrote: >> Oh, absolutely, I know about that. I was just wondering why now, and >> is this something you just came up with, and are we going to have the >> compatibility discussion? > > Perhaps now is the chosen moment (and

Re: RFR 9: 8165641 : Deprecate Object.finalize

On 12/03/17 09:55, Andrew Haley wrote: > Oh, absolutely, I know about that. I was just wondering why now, and > is this something you just came up with, and are we going to have the > compatibility discussion? Perhaps now is the chosen moment (and a good choice at that, I say) because deprecation

Re: Shouldn't InputStream/Files::readAllBytes throw something other than OutOfMemoryError?

On 03/13/2017 12:33 PM, Chris Hegarty wrote: Anthony, Many of the Collection types throw OOME if requested to grow greater than ~2GB. Likewise some operations of String and StringBuilder. Though this behavior is not strictly part of the current specification, I suspect that it is the defacto

Re: Shouldn't InputStream/Files::readAllBytes throw something other than OutOfMemoryError?

Anthony, Many of the Collection types throw OOME if requested to grow greater than ~2GB. Likewise some operations of String and StringBuilder. Though this behavior is not strictly part of the current specification, I suspect that it is the defacto standard ( since the implementation has always b

Re: RFR 9: 8165641 : Deprecate Object.finalize

On 12/03/2017 09:55, Andrew Haley wrote: : I have no problem with the deprecation, BTW. It's what happens next that is more problematic. I think it has to be baby steps and I would expect going further will involve years and several major releases. That should give time to look at use-cases