Re: Duplicate words typos in comments/javadoc/strings

> On 28 Jan 2019, at 22:23, Andrey Turbanov wrote: > > Thanks to review. Patch updated. I'm not really sure what to do next. > I should find someone who can create issue and commit my patch to > repository, right? Have you signed the OCA [1]? The full process is described here [2]. If you have

Re: RFR: JDK-8216528: test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java failing with Xcomp

Hi, I agree that the simplest way to fix the issue is just adding the reachabilityFence. But this patch might also fail since the VM doesn't guarantee that a GC would be performed. I didn't make such patch since I've learned from Sergey and Alan that calling "System.gc()" several times is

RFR: JDK-8217880 AIX build issue about JDK-8214533

Hello. Sorry about build issue for JDK-8214533. EUC_JP was extra entry on make/data/charsetmapping/stdcs-aix. Bug:https://bugs.openjdk.java.net/browse/JDK-8217880 Change: https://cr.openjdk.java.net/~itakiguchi/8217880/webrev.00/ Could you review the fix ? Thanks, Ichiroh Takiguchi IBM

Re: RFR: JDK-8217331: Problems when space in application name

Hi Andy, Looks fine. Thanks, Alexander On 1/27/2019 4:56 AM, Andy Herrick wrote: Please review the jpackage fix for bug [1] at [2]. This is a fix for the JDK-8200758-branch branch of the open sandbox repository (jpackage). The webrev includes removal of the APP_FS_NAME DeployParam, and

RE: RFR [11u backport]: 8034802: (zipfs) newFileSystem throws UOE when the zip file is located in a custom file system

Hi Goetz, > Patching the file myself really helped to see there are no real changes. > > For the missing patch of the constructor I understand it was only an arbitrary > reordering of arguments you omitted. Thus the whole chunk disappeared. > This makes sense, and in case someone downports the

Re: possible problem with JNI GetStringUTFChars

If you search the JDK repo for GetStringUTFChars, you will find several uses that do not appear to involve serialization or data input/output. It is not obvious whether these uses are correct or not. Consider test/jdk/java/nio/channels/FileChannel/directio/libDirectIO.c where GetStringUTFChars

Re: Duplicate words typos in comments/javadoc/strings

> On 28/01/2019 17:04, Lance Andersen wrote: > > The updates look fine > >> - * This includes the case where a module reads another another with > >> the > >> + * This includes the case where a module reads another with the > >> > This one is typo, it should say "another module". > >

Re: possible problem with JNI GetStringUTFChars

In case you missed my previous message, there is a use case for file paths using macOS APIs. Alan > On Jan 28, 2019, at 2:10 PM, Stuart Marks wrote: > > I think it would be far too troublesome to try to migrate the JNI methods to > process real UTF-8 instead of modified UTF-8. That raises

Re: possible problem with JNI GetStringUTFChars

On 1/26/19 3:19 PM, David Holmes wrote: On 27/01/2019 3:08 am, Martin Buchholz wrote: It's a pet peeve that the name GetStringUTFChars is deeply misleading - there are many "UTF"s, and this encoding is meant for use with the JVM only.  The documentation should make it clearer that this is

Re: RFR: JDK-8217331: Problems when space in application name

This looks fine to me. I note that it still allows characters that will cause problems (e.g., ":" on Linux or ";" on Windows), but that could be done as a follow-on bug. -- Kevin On 1/27/2019 4:56 AM, Andy Herrick wrote: Please review the jpackage fix for bug [1] at [2]. This is a fix for

RE: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over non-volatile memory

Thanks a lot Alan! This is very helpful. Best Regards, Sandhya -Original Message- From: Alan Bateman [mailto:alan.bate...@oracle.com] Sent: Monday, January 28, 2019 11:45 AM To: Viswanathan, Sandhya ; Andrew Dinn ; Brian Goetz Cc: core-libs-dev@openjdk.java.net; hotspot compiler ;

Re: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over non-volatile memory

On 28/01/2019 18:39, Viswanathan, Sandhya wrote: Hi Alan, Could you please let us know more on what does it mean to be a jdk-specific feature? How it is to be implemented? An example would be very helpful. ByteBuffer is a widely used API and deprecating ByteBuffer any time would make it

RE: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over non-volatile memory

Hi Alan, Could you please let us know more on what does it mean to be a jdk-specific feature? How it is to be implemented? An example would be very helpful. ByteBuffer is a widely used API and deprecating ByteBuffer any time would make it difficult for more and more Java software frameworks to

Re: Duplicate words typos in comments/javadoc/strings

On 28/01/2019 17:04, Lance Andersen wrote: The updates look fine - * This includes the case where a module reads another another with the + * This includes the case where a module reads another with the This one is typo, it should say "another module". -Alan

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation (update 2)

On 1/27/2019 4:55 AM, Alan Bateman wrote: On 11/01/2019 19:41, Andy Herrick wrote: This is the second update to the Request For Review of the implementation of the Java Packager Tool (jpackager) as described in JEP 343: Packaging Tool I've

Re: Duplicate words typos in comments/javadoc/strings

The updates look fine > On Jan 27, 2019, at 5:35 PM, Andrey Turbanov wrote: > > Hello. > I noticed that Open JDK source code contains many duplicate words > typos which could be easily find via simple regexp. > I checked only java.base module and fixed problems there. Does it > makes sense to

Duplicate words typos in comments/javadoc/strings

Hello. I noticed that Open JDK source code contains many duplicate words typos which could be easily find via simple regexp. I checked only java.base module and fixed problems there. Does it makes sense to create patches to other modules too? Index:

Re: RFR : 8217093: Support extended-length paths in parse_manifest.c on windows

On 28/01/2019 16:09, Baesken, Matthias wrote: you should think of a JLI_open function and then you can put its implementation into the Windows version of java_md.c. Hi Christoph, I like this idea . New webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8217093.4/ This is the one.

Re: FW: RFR: JDK8U Backport of JDK-8212941: Support new Japanese era in java.time.chrono.JapaneseEra

Thanks for the reviews. Here's the final webrev which I hope to sponsor for Deepak once I have the necessary approvals. http://cr.openjdk.java.net/~coffeys/webrev.8212941.jdk8u/webrev/ Regards, Sean. On 28/01/19 16:06, Naoto Sato wrote: +1 Naoto On 1/28/19 3:18 AM, Chris Hegarty wrote:

RE: RFR [11u backport]: 8034802: (zipfs) newFileSystem throws UOE when the zip file is located in a custom file system

Hi Christoph, Patching the file myself really helped to see there are no real changes. For the missing patch of the constructor I understand it was only an arbitrary reordering of arguments you omitted. Thus the whole chunk disappeared. This makes sense, and in case someone downports the other

RE: JDK-8217777 TEST_BUG: jdk/java/util/prefs/ExportSubtree.java passes even when test should fail

Hi Christoph, Additional changes look OK to me. Happy for for you to push. Thanks Steve Groeger IBM Runtime Technologies Hursley, Winchester Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 Fax (44) 1962 816800 Lotus Notes: Steve Groeger/UK/IBM Internet: groe...@uk.ibm.com Unless

Re: JDK-8217777 TEST_BUG: jdk/java/util/prefs/ExportSubtree.java passes even when test should fail

Looks good, Thanks, Roger On 01/28/2019 10:49 AM, Langer, Christoph wrote: Hi Steve, Roger, I made some additional cleanups in the test (Declare constants final, formatting, nice up error output...) This is what ran through our test system without issues:

RE: RFR : 8217093: Support extended-length paths in parse_manifest.c on windows

> you should think of a JLI_open function and then you can > put its implementation into the Windows version of java_md.c. Hi Christoph, I like this idea . New webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8217093.4/ > > Would it be possible to add a jtreg testcase that shows/tests

Re: RFR: JDK11U Backport of JDK-8212941: Support new Japanese era in java.time.chrono.JapaneseEra

+1 Naoto On 1/28/19 3:19 AM, Chris Hegarty wrote: On 26/01/2019 10:57, Deepak Kejriwal wrote: Hi All, JBS report: https://bugs.openjdk.java.net/browse/JDK-8212941 Webrev: http://cr.openjdk.java.net/~rpatil/8212941/jdk11u/webrev.00/ This looks good Deepak. Reviewed. One minor comment.

Re: FW: RFR: JDK8U Backport of JDK-8212941: Support new Japanese era in java.time.chrono.JapaneseEra

+1 Naoto On 1/28/19 3:18 AM, Chris Hegarty wrote: On 27/01/2019 11:54, Deepak Kejriwal wrote: ... Hi All, JBS report: https://bugs.openjdk.java.net/browse/JDK-8212941 Webrev: http://cr.openjdk.java.net/~rpatil/8212941/jdk8u/webrev.00/ This looks good Deepak. Reviewed. One minor

RE: JDK-8217777 TEST_BUG: jdk/java/util/prefs/ExportSubtree.java passes even when test should fail

Hi Steve, Roger, I made some additional cleanups in the test (Declare constants final, formatting, nice up error output...) This is what ran through our test system without issues: http://cr.openjdk.java.net/~clanger/webrevs/821.0/ In case there was an error in the output, it would read

Re: RFR: JDK-8216528: test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java failing with Xcomp

Hi, The simplest fix for this failing test is to add a call to reachabilityFence to prevent the loader and loaderRef from going out of scope early.  It maintains getting debug output on a failure. Offlist, Jie and I explored some alternate ways to write the test and settled on this one.

RE: RFR: 8214533 IBM-29626C is required for AIX default charset

Hello Goetz. Thank you for your suggestion. I just open JDK-8217880 [1]. I just restart clean build. I'll post new fix including testcase for EUC_JP_LINUX and EUC_JP_Open. [1] https://bugs.openjdk.java.net/browse/JDK-8217880 Thanks, Ichiroh Takiguchi On 2019-01-28 22:11, Lindenmaier, Goetz

RE: RFR : 8217093: Support extended-length paths in parse_manifest.c on windows

Hi Matthias, thanks for the update. I still think you should avoid introducing a file parse_manifest_md.c. As per my previous mail, you should think of a JLI_open function and then you can put its implementation into the Windows version of java_md.c. You can take example on the implementation

ClassValue - clarify Javadoc

computeValue() documentation says: "This method will be invoked within the first thread that accesses the value with the get method. Normally, this method is invoked at most once per class, but it may be invoked again if there has been a call to remove." It sounds exactly like ClassValue

RE: RFR: 8214533 IBM-29626C is required for AIX default charset

Hi Ichiroh, just open a bug, like "Fix aix build after 8214533" and post a RFR for it. I assume the fix is quite trivial so we can review it quick. Best regards, Goetz. > -Original Message- > From: ppc-aix-port-dev On > Behalf Of Ichiroh Takiguchi > Sent: Montag, 28. Januar 2019

RE: RFR: 8214533 IBM-29626C is required for AIX default charset

Hello. I'm very sorry. It's my fault. EUC_JP class was moved to java.base module. (sun.nio.cs.EUC_JP). make/data/charsetmapping/stdcs-aix should have EUC_JP_LINUX and EUC_JP_Open. Could you suggest me how I should provide new webrev files ? Thanks, Ichiroh Takiguchi On 2019-01-28 17:03,

RE: RFR : 8217093: Support extended-length paths in parse_manifest.c on windows

Hello Alan / Christoph, new webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8217093.3/ - moved ELP_PREFIX define out of the function - added a check(wfullnamelen > 247) before CreateFileW is attempted - some other formatting (mostly suggested by Christoph) Best regards,

Re: RFR: JDK11U JDK-8216546: Support new Japanese era in java.lang.Character for Java SE 11

On 25/01/2019 18:35, Deepak Kejriwal wrote: Hi All, JBS report: https://bugs.openjdk.java.net/browse/JDK-8216546 Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Erpatil/8216546/"http://cr.openjdk.java.net/~rpatil/8216546/ This change looks good Deepak. Reviewed. I have added myself

Re: RFR: JDK8U JDK-8216396: Support new Japanese era and new currency code points in java.lang.Character for Java SE 8

On 25/01/2019 18:37, Deepak Kejriwal wrote: Hi All, JBS report: https://bugs.openjdk.java.net/browse/JDK-8216396 Webrev: http://cr.openjdk.java.net/~rpatil/8216396/ This change looks good Deepak. Reviewed. -Chris.

Re: RFR: JDK11U Backport of JDK-8212941: Support new Japanese era in java.time.chrono.JapaneseEra

On 26/01/2019 10:57, Deepak Kejriwal wrote: Hi All, JBS report: https://bugs.openjdk.java.net/browse/JDK-8212941 Webrev: http://cr.openjdk.java.net/~rpatil/8212941/jdk11u/webrev.00/ This looks good Deepak. Reviewed. One minor comment. "The of(int) and valueOf(String) methods ...",

Re: FW: RFR: JDK8U Backport of JDK-8212941: Support new Japanese era in java.time.chrono.JapaneseEra

On 27/01/2019 11:54, Deepak Kejriwal wrote: ... Hi All, JBS report: https://bugs.openjdk.java.net/browse/JDK-8212941 Webrev: http://cr.openjdk.java.net/~rpatil/8212941/jdk8u/webrev.00/ This looks good Deepak. Reviewed. One minor comment. "The of(int) and valueOf(String) methods ...",

RE: RFR: 8214533 IBM-29626C is required for AIX default charset

Hello, seems 8214533 got pushed recently into jdk/jdk. Now we see build errors on AIX , are they related to this change ? /nb/rs6000_64/nightly/output-jdk-test/support/gensrc/jdk.charsets/sun/nio/cs/ext/EUC_JP_LINUX.java:63: error: Decoder is not public in EUC_JP; cannot be