Re: RFR: 8225648:[TESTBUG] java/lang/annotation/loaderLeak/Main.java fails with -Xcomp

Hi Alan, I've updated the patch by adding the review info. http://cr.openjdk.java.net/~jiefu/8225648/webrev.01/ Is it OK to be pushed? Thanks a lot. Best regards, Jie On 2019/6/19 下午2:04, Ioi Lam wrote: Sure, you can add me as reviewer. Thanks On Jun 18, 2019, at 10:54 PM, Jie Fu wrote:

Re: RFR(XS): 8226286 Remove unused method java.lang.Integer::formatUnsignedInt

Hello, Brian! Thank you for review. Here's updated version: http://cr.openjdk.java.net/~tvaleev/webrev/8226286/r2/ I left dangling javadoc in-place in the same way as it's done in > java.lang.Long. > > > I don’t know whether this was intentional per some policy or an oversight. > Seems it was an

The final optimized version of Dual-Pivot Quicksort (ver.19.1)

Hi team, Please review the final optimized version of Dual-Pivot Quicksort (ver.19.1), see http://cr.openjdk.java.net/~alanb/8226297/0/webrev (link to Jira task https://bugs.openjdk.java.net/browse/JDK-8226297) The new version was published here more than one year ago (on Jan 19, 2018). Since tha

Re: [14]RFR: 8220229: Timezone pattern "OOOO" does not result in the full "GMT+00:00" substring

Hi Naoto, It reads OK. I will add myself as a CSR reviewer also > On Jun 18, 2019, at 3:37 PM, naoto.s...@oracle.com wrote: > > Hello, > > Please review the fix to the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8220229 > > The proposed changeset and CSR are located at: >

[14]RFR: 8220229: Timezone pattern "OOOO" does not result in the full "GMT+00:00" substring

Hello, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8220229 The proposed changeset and CSR are located at: https://cr.openjdk.java.net/~naoto/8220229/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8226308 This is to simply clarify the cases for z

Re: RFR [14] 8226303: Examine the HttpRequest.BodyPublishers for exception handling

Hi Pavel, Mostly looks good to me. One remark about the test: 107 CompletableFuture future() { 108 return f.copy(); 109 } I had to read the javadoc to convince myself that this was OK ;-) If the existing tests all pass reliably you have my review. best regards,

Re: RFR (T): 8226203: MappedByteBuffer.force method may have no effect on implementation specific map modes

On 18/06/2019 17:15, Andrew Dinn wrote: Could I please have a review for the following trivial change to the javadoc for the two MappedByteBuffer.force methods: JIRA: https://bugs.openjdk.java.net/browse/JDK-8226203 webrev: http://cr.openjdk.java.net/~adinn/8226203/webrev.00/ It allows

Re: RFR [14] 8226303: Examine the HttpRequest.BodyPublishers for exception handling

Pavel, > On 18 Jun 2019, at 17:56, Pavel Rappo wrote: > > Hi Chris, > > Thanks for adding net-dev. I should've posted there in the first place, but > something went wrong. As for your comments: > > 1) I will add this before pushing the change: > >* @summary Verifies that some of the stand

Re: RFR [14] 8226303: Examine the HttpRequest.BodyPublishers for exception handling

Hi Chris, Thanks for adding net-dev. I should've posted there in the first place, but something went wrong. As for your comments: 1) I will add this before pushing the change: * @summary Verifies that some of the standard BodyPublishers relay exception * rather than throw it

RFR (T): 8226203: MappedByteBuffer.force method may have no effect on implementation specific map modes

Could I please have a review for the following trivial change to the javadoc for the two MappedByteBuffer.force methods: JIRA: https://bugs.openjdk.java.net/browse/JDK-8226203 webrev: http://cr.openjdk.java.net/~adinn/8226203/webrev.00/ It allows for the possibility of failures when extende

Re: RFR(XS): 8226286 Remove unused method java.lang.Integer::formatUnsignedInt

Hello, > On Jun 17, 2019, at 9:55 PM, Tagir Valeev wrote: > > Please review: > https://bugs.openjdk.java.net/browse/JDK-8226286 > > http://cr.openjdk.java.net/~tvaleev/webrev/8226286/r1/ >

Re: RFR [14] 8226303: Examine the HttpRequest.BodyPublishers for exception handling

[ adding net-dev ] Pavel, > On 18 Jun 2019, at 14:22, Pavel Rappo wrote: > > Hello, > > Please review the following change: > > http://cr.openjdk.java.net/~prappo/8226303/webrev.00 This looks good. Just a few minor comments: 1) Please add the bug no. and a brief summary, to the test tags.

Re: EnumSet.class serialization broken - twice

On 6/18/19 4:00 PM, Martin Buchholz wrote: Java Historian says: I was a reviewer for Effective Java 3rd Edition and EnumSet is the canonical example of the Serialization Proxy pattern, so I tried to make sure the pattern was implemented as perfectly as possible. 8192935: Fix EnumSet's Seria

Re: EnumSet.class serialization broken - twice

Java Historian says: I was a reviewer for Effective Java 3rd Edition and EnumSet is the canonical example of the Serialization Proxy pattern, so I tried to make sure the pattern was implemented as perfectly as possible. 8192935: Fix EnumSet's SerializationProxy javadoc All of us who try to make jav

Re: 8226242 : Diagnostic output for posix_spawn failure

Hi David, The error that is being reported is the absence of an ack from jsspawnhelper (CHILD_IS_ALIVE) indicating that it has started (and is about to exec the target exe). The child process should continue to run; reporting the status of the child will hopefully lead to identifying why the ch

RFR [14] 8226303: Examine the HttpRequest.BodyPublishers for exception handling

Hello, Please review the following change: http://cr.openjdk.java.net/~prappo/8226303/webrev.00 This change increases robustness of convenience BodyPublishers by going the extra mile and ensuring unlikely thrown exceptions are relayed downstream. Thanks, -Pavel

RE: [11u]: RFR: 8215281: Use String.isEmpty() when applicable in java.base

Hello Christoph, looks good with the exception of src/java.base/share/classes/jdk/internal/module/Checks.java http://cr.openjdk.java.net/~clanger/webrevs/8215281.11u/src/java.base/share/classes/jdk/internal/module/Checks.java.frames.html /** - * Returns {@code true} if the given n

Re: Question re: Usage of JNICALL with varargs function with 32bit compilers

Hi Thomas, There are not issues caused by this, as you state, the compile forces the callee and caller back to the same convention. The only issue we had was with the amount of warning that were produced when we (IBM) compiled the jdk. We avoided the error by adding -Wno-ignored-attributes in t

EnumSet.class serialization broken - twice

Hi, I recently stumbled on an exception thrown when deserializing stream produced on JDK 8 and read with JDK 11. I narrowed the problem down to serialization/deserialization of a public EnumSet.class object. There were several changes made to EnumSet in the Mercurial history of jdk repo, but

Re: Question re: Usage of JNICALL with varargs function with 32bit compilers

Hi Steve, I always saw this as a harmless warning, safe to ignore, since both caller and callee are forced back to the same convention so it all works out in the end. Or can you envision a scenario where this would be harmfull? Thank god Microsoft abandoned this calling convention circus with 64b

Re: Slightly faster java.util.Arrays.byteSort(byte[])

Hi Rodion, I looked at your byte sorting and compared it with the version which is under review now. Here is the summary of my results: 1. net.coderodde.Arrays.sort(byte[]) works slower on small data (len < ~70). The reason is that insertion sort is invoked on small arrays where counting sort is

Re: RFR: 8224974: Implement JEP 352

Hi Alan, Thanks for reviewing the JEP one more time. On 16/06/2019 09:47, Alan Bateman wrote: > I re-read the JEP, trying to put myself in the position of someone > reading it for the first time in 2020. > > Summary section: > > What would you think about replacing this with a sentence that mak

Question re: Usage of JNICALL with varargs function with 32bit compilers

Hi all, I had a query regarding the use of JNICALL with varargs functions, which I am hoping someone can comment on. As explained on MSDN at [1], all functions declared as __stdcall that have variable parameters (varargs) will be forced back to __cdecl by the MSVC. In such case, keeping JNICA

[11u]: RFR: 8215281: Use String.isEmpty() when applicable in java.base

Hi, please review the backport of the String.isEmpty() cleanups in java.base. The main reason to bring this down to JDK11u is that it'll ease backporting of later changes which otherwise run into conflicts and won't resolve. Furthermore, the original change is a nice cleanup and improves perfor