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

BTW, I did *remove* the unnecessary @since for ObjectInputFilter.checkInput. :-) Thank you -Hamlin On 2017/3/15 11:34, Hamlin Li wrote: Hi everyone, Thanks a lot for the patient review and comments, I think you're right to remove @since when overriding methods, I will also adjust the tool

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

Hi everyone, Thanks a lot for the patient review and comments, I think you're right to remove @since when overriding methods, I will also adjust the tool to take this into account. I have updated as everyone suggested, new webrev is at : http://cr.openjdk.java.net/~mli/8176563/webrev.01/

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

Hi Lance, Thank you for reviewing, I agree with you, and will adjust the tool's algorithm to take this into account. I just reverted the changes for xxxDataSource for the getXXX/setXXX methods, and pushed the code. Thank you -Hamlin On 2017/3/14 20:43, Lance Andersen wrote: Hi Hamlin,

Re: RFR 9: 8165641 : Deprecate Object.finalize

> On Mar 14, 2017, at 7:06 PM, Roger Riggs wrote: > > On 3/14/17 4:53 PM, Mandy Chung wrote: >> This patch looks fine in general. >> >> Does @inheritDoc inherit @deprecated? What does the javadoc of >> javax.imageio.stream.* look like? > Yes, the deprecation is inherited, see: > > http://cr.

Re: RFR 9: 8165641 : Deprecate Object.finalize

Hi Mandy, Webrev updated in place with your and Stuart's review comments. http://cr.openjdk.java.net/~rriggs/webrev-finalize-deprecate-8165641/ On 3/14/17 4:53 PM, Mandy Chung wrote: This patch looks fine in general. Does @inheritDoc inherit @deprecated? What does the javadoc of javax.imag

Re: RFR: 8176541: XML deprecation "since" values should use 1.x version form for 1.8 and earlier

Thanks Roger, Joe! -Joe On 3/14/2017 6:16 PM, Roger Riggs wrote: Looks fine Joe. On 3/14/17 9:08 PM, huizhe wang wrote: Hi, Please review a correction of the "since" values for several deprecated classes / methods. diff --git a/src/java.xml/share/classes/javax/xml/stream/XMLEventFactory.

Re: RFR 9: 8165641 : Deprecate Object.finalize

Hi Stuart, Thanks, I'll remove the unnecessary @SuppressWarnings in the next update. Roger On 3/13/17 6:57 PM, Stuart Marks wrote: 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

Re: RFR: 8176541: XML deprecation "since" values should use 1.x version form for 1.8 and earlier

Looks fine; cheers, -Joe On 3/14/2017 6:08 PM, huizhe wang wrote: Hi, Please review a correction of the "since" values for several deprecated classes / methods. diff --git a/src/java.xml/share/classes/javax/xml/stream/XMLEventFactory.java b/src/java.xml/share/classes/javax/xml/stream/XMLE

Re: RFR: 8176541: XML deprecation "since" values should use 1.x version form for 1.8 and earlier

Looks fine Joe. On 3/14/17 9:08 PM, huizhe wang wrote: Hi, Please review a correction of the "since" values for several deprecated classes / methods. diff --git a/src/java.xml/share/classes/javax/xml/stream/XMLEventFactory.java b/src/java.xml/share/classes/javax/xml/stream/XMLEventFactory.

RFR: 8176541: XML deprecation "since" values should use 1.x version form for 1.8 and earlier

Hi, Please review a correction of the "since" values for several deprecated classes / methods. diff --git a/src/java.xml/share/classes/javax/xml/stream/XMLEventFactory.java b/src/java.xml/share/classes/javax/xml/stream/XMLEventFactory.java --- a/src/java.xml/share/classes/javax/xml/stream/X

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

Hamlin, I have to agree with Martin here. These changes seem very misguided in places. Only NEW types or new type members should be flagged with @since. For example, adding "@since 9" to java.lang.reflect.Field.setAccessible is just WRONG! David On 15/03/2017 2:06 AM, Martin Buchholz wrote

Re: RFR 9: 8165641 : Deprecate Object.finalize

On 15/03/2017 12:01 AM, Timo Kinnunen wrote: Hi, File handles aren’t that scarce of a resource, really, at least on Windows. On Windows threads are a lot scarcer resource than file handles, and I don’t recall anyone suggesting Java’s GC wasn’t suitable for managing that limited but crucially

Re: RFR: 8176709: JarFileSystem::isMultiReleaseJar is incorrect

I agree with the goal to reduce the number of qualified exports, which I always like to keep. Duplicating code like this isn’t ideal although it’s straight-forward. This is a performance optimization. One solution is to keep using the Manifest API and check the attribute value equals to `true

Re: RFR 9: 8165641 : Deprecate Object.finalize

The problem with runFinalizers() is that it only executes one additional (second) finalized-queue processing thread. It will not trigger the Gc mechanism needed to actually detect and enqueue the unreachable candidates. So it might help with slow or stalled finalize() calls, but by doing so it

Re: RFR 9: 8165641 : Deprecate Object.finalize

On Mar 14, 2017, at 3:02 PM, Hans Boehm wrote: > > If runFinalization() waits unconditionally for the other thread to complete, > then I think it would be great to add a warning. Conversely, if it times out > quickly enough to consider it non-blocking, that's useful information, too. > Block

Re: RFR 9: 8165641 : Deprecate Object.finalize

Since nothing is proposed to be removed in this patch, Object.finalize and runFinalization will stay. runFinalization is a hint. The spec states that it suggests the JVM expend effort toward running the finalizer methods of objects pending for finalization. It’s best effort and no guarantee.

Re: RFR 9: 8165641 : Deprecate Object.finalize

This patch looks fine in general. Does @inheritDoc inherit @deprecated? What does the javadoc of javax.imageio.stream.* look like? + * @deprecated Finalization is deprecated and should not be used. + * See {@link Object#finalize} for the explanation and recommended replac

RFR 9: 8176272 : (process) ProcessHandle::onExit fails to wait for non-child process

Please review a change to the implementation of ProcessHandle.onExit to correctly handle waiting for any process to terminate and a corresponding new test. On Linux, waitpid only waits for direct children; waiting for non-children now polls for termination. Please review and comment: Webrev: h

Re: Review Request: JDK-8174977: Update license files with consistent license/notice names

On 14/03/2017 19:58, Mandy Chung wrote: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8174977/webrev.00/index.html Small edits to the license files, contributed by jeannette.h...@oracle.com. I am sponsoring it. Also I have reviewed it. Mandy Looks okay to me.

Re: RFR 9: 8165641 : Deprecate Object.finalize

> On Mar 14, 2017, at 10:37 AM, Stuart Marks wrote: > > Tagir Valeev asked on Twitter whether System.runFinalization() and > Runtime.runFinalization() should also be deprecated. The obvious answer is > "yes" since we're deprecating finalization, but maybe it's not so obvious. > > One view is t

Review Request: JDK-8174977: Update license files with consistent license/notice names

http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8174977/webrev.00/index.html Small edits to the license files, contributed by jeannette.h...@oracle.com. I am sponsoring it. Also I have reviewed it. Mandy

Re: RFR 9: 8165641 : Deprecate Object.finalize

> On Mar 14, 2017, at 12:25 PM, Timo Kinnunen wrote: > > Hi, > > Maybe rather than “an ugly waste of memory” which sounds somewhat negative, > we could instead call it “an honestly assessed true resource cost”? > Yuck! I'm imagining opening 32k file descriptors that represent sockets in e.

RE: RFR 9: 8165641 : Deprecate Object.finalize

Hi, Maybe rather than “an ugly waste of memory” which sounds somewhat negative, we could instead call it “an honestly assessed true resource cost”? Besides, this amount wouldn’t have to be set in stone. It could be easily increased or decreased in response to resource pressures. Lots of ergono

Re: RFR: 8176709: JarFileSystem::isMultiReleaseJar is incorrect

Hi, Alan raised some concerns offline that we should try to reduce the number of qualified exports, not adding more, and that it might be better to accept some code duplication here. Thus I'm proposing this as an alternative: http://cr.openjdk.java.net/~redestad/8176709/jdk.02/ Neither solution

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

On 3/14/17 7:53 AM, Roger Riggs wrote: Hi, - The @since in ObjectInputFilter.checkInput is unnecessary; the class has @since 9 - java.util.Properties.replace @since seems unnecessary because it will not be seen. The @hidden is a bit odd too but that has its own explaination (btw, it is the on

Re: RFR 9: 8165641 : Deprecate Object.finalize

On 14/03/17 14:01, Timo Kinnunen wrote: > File handles aren’t that scarce of a resource, really, at least on > Windows. I've seen processes running out of file handles. It is possible to change the per-process limit. And, of course, there is a lot of hidden context in the kernel and device driv

Re: RFR 9: 8165641 : Deprecate Object.finalize

Tagir Valeev asked on Twitter whether System.runFinalization() and Runtime.runFinalization() should also be deprecated. The obvious answer is "yes" since we're deprecating finalization, but maybe it's not so obvious. One view is that we're not deprecating the entire finalization mechanism, we'r

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

> On 14 Mar 2017, at 01:45, Hamlin Li wrote: > > Hi Martin, > > I update the webrev in place to remove blank lines between tags, > http://cr.openjdk.java.net/~mli/8176566/webrev.00/ > +1 Paul. > Thank you > > -Hamlin

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

Hi Hamlin, I had the same remark than Roger & others about ObjectInputFilter::checkInput. The changes to LogManager are OK. How did I forget that @since? Thanks for catching that! Don't count me as Reviewer for the other java.util changes though. best regards -- daniel On 14/03/2017 06:40, H

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

On Tue, Mar 14, 2017 at 12:46 AM, Hamlin Li wrote: > > @since *since-text* > > Introduced in JDK 1.1 > > Adds a *Since* heading with the specified since-text value to the > generated documentation. The text has no special internal structure. This > tag is valid in any documentation comment: overv

RE: Review request 8153912: StackFrame::getFileName andStackFrame::getLineNumber not needed

Hi, I was curious so I tried my hand at a couple of different implementations for getting a caller’s class. These were all run in JDK 1.8.0_102, VM 25.102-b14. I’m not sure our results agree, but neither am I sure how to properly compare them. And since you have no baseline score this makes c

RFR: 8176709: JarFileSystem::isMultiReleaseJar is incorrect

Hi, please review this change to adapt the JarFileSystem::isMultiReleaseJar method to align with the evolved specification in JEP 238 Bug: https://bugs.openjdk.java.net/browse/JDK-8176709 Webrev: http://cr.openjdk.java.net/~redestad/8176709/jdk.01/ This unfortunately adds a qualified export fro

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

Hi, - The @since in ObjectInputFilter.checkInput is unnecessary; the class has @since 9 - java.util.Properties.replace @since seems unnecessary because it will not be seen. The @hidden is a bit odd too but that has its own explaination (btw, it is the only one in the jdk). - I agree abou

RE: RFR 9: 8165641 : Deprecate Object.finalize

Hi, File handles aren’t that scarce of a resource, really, at least on Windows. On Windows threads are a lot scarcer resource than file handles, and I don’t recall anyone suggesting Java’s GC wasn’t suitable for managing that limited but crucially important resource. The question should then b

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

Hi Hamlin, Everything with the exception of the xxxDataSource changes are correct. Best Lance > On Mar 14, 2017, at 7:05 AM, Lance Andersen wrote: > > Hi Hamlin, > > The changes for xxxDataSource for the getXXX/setXXX methods which you marked > as @since 9 is not correct. The common method

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

Hi Hamlin, The changes for xxxDataSource for the getXXX/setXXX methods which you marked as @since 9 is not correct. The common methods were placed in CommonDataSource in JDBC 4/JDK 1.6 to make it easier for updates. Please see https://bugs.openjdk.java.net/browse/JDK-8164061

Re: RFR 9: 8165641 : Deprecate Object.finalize

On 12/03/17 23:55, 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. And in > my experience it's unfortunately unrealistic to say we're going to

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

Hi Ralph, On 14/03/2017 06:03, Ralph Goers wrote: 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

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

Looks fine Stuart. -Chris. > On 13 Mar 2017, at 22:11, Stuart Marks wrote: > > .. 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 wi

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

Hamlin, > On 14 Mar 2017, at 08:21, Hamlin Li wrote: > > > On 2017/3/14 15:46, Hamlin Li wrote: >> Hi Martin, >> >> >> On 2017/3/14 15:06, Martin Buchholz wrote: >>> I wouldn't put a blank line between javadoc tags. >> Will fix it. > Hi Martin, > > Just update webrev in place to remove blank

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

Hi Martin, I update the webrev in place to remove blank lines between tags, http://cr.openjdk.java.net/~mli/8176566/webrev.00/ Thank you -Hamlin On 2017/3/14 13:16, Hamlin Li wrote: Hi Martin, On 2017/3/14 11:53, Martin Buchholz wrote: Thanks, Thank you. 10 years ago I fixed most of

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

On 2017/3/14 15:46, Hamlin Li wrote: Hi Martin, On 2017/3/14 15:06, Martin Buchholz wrote: I wouldn't put a blank line between javadoc tags. Will fix it. Hi Martin, Just update webrev in place to remove blank lines, webrev still at http://cr.openjdk.java.net/~mli/8176563/webrev.00/ Than

Re: Unintentional abort with SIGUSR2

On 14/03/2017 5:03 PM, Takao, Shinji wrote: Hi all, I encountered an unintentional process abort with SIGSEGV when a Java process received a SIGUSR2. I was little surprised because I believed that the SIGUSR2 was to be ignored when it had no user definition. Is there any documentation for the

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

Hi Martin, On 2017/3/14 15:06, Martin Buchholz wrote: I wouldn't put a blank line between javadoc tags. Will fix it. I'm not sure whether @since is justified for new specialized implementations like ArrayDeque.removeAll. It is somewhat misleading to add the @since because that method has

Re: Unintentional abort with SIGUSR2

This looks like a bug. I can reproduce it on Linux (slowdebug jdk10-hs): # To suppress the following error report, specify this argument # after -XX: or in .hotspotrc: SuppressErrorAt=/os_linux.cpp:4014 # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/pri

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

Hi Martin, On 2017/3/14 15:09, Martin Buchholz wrote: An automated tool for detecting @since mistakes needs to be run every release. So it's important to make it available as open source. For this part, I can not give you the answer right now, I can only promise I will let you updated in case

Re: Unintentional abort with SIGUSR2

signal(7) documents the default behavior of Unix signals.

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

An automated tool for detecting @since mistakes needs to be run every release. So it's important to make it available as open source. Running such a tool should not be completely automated - human judgement still required.

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

I wouldn't put a blank line between javadoc tags. I'm not sure whether @since is justified for new specialized implementations like ArrayDeque.removeAll. It is somewhat misleading to add the @since because that method has worked just fine in past releases with no substantive spec change. H..

Unintentional abort with SIGUSR2

Hi all, I encountered an unintentional process abort with SIGSEGV when a Java process received a SIGUSR2. I was little surprised because I believed that the SIGUSR2 was to be ignored when it had no user definition. Is there any documentation for the behavior? # # A fatal error has been detecte