Re: [14] RFR: 8233579: DateFormatSymbols.getShortMonths() return wrong string on es_CL, es_CO locales

That sounds good. JIRA makes sense. Best, Joe On 11/6/19 6:34 PM, naoto.s...@oracle.com wrote: Hi Joe, Thanks for the review! I tried to draft some comments, but thinking of it, it could be confusing to leave a comment for a removed (wrong) code. So instead of leaving code comments, I

Re: [14] RFR: 8233579: DateFormatSymbols.getShortMonths() return wrong string on es_CL, es_CO locales

Hi Joe, Thanks for the review! I tried to draft some comments, but thinking of it, it could be confusing to leave a comment for a removed (wrong) code. So instead of leaving code comments, I modified the JIRA issue mentioning it, so that maintainers later could find out the rationale. Naoto

Re: [14] RFR: 8233579: DateFormatSymbols.getShortMonths() return wrong string on es_CL, es_CO locales

Looks good to me. It might be good to leave a note to the method about the change (e.g. why it no longer substitutes). -Joe On 11/6/19 1:45 PM, naoto.s...@oracle.com wrote: Hi, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8233579 The proposed

Re: [14] RFR: 8232871: Host Locale Provider on Mac does not return translated values of Japanese calendar

Hi Brent, Thank you for the review! Please see my comments below. On 11/6/19 3:27 PM, Brent Christian wrote: Hi, Naoto Looks pretty good.  I have a few comments: -- src/java.base/macosx/classes/sun/util/locale/provider/HostLocaleProviderAdapterImpl.java  572 map =

Re: [14] RFR: 8232871: Host Locale Provider on Mac does not return translated values of Japanese calendar

Hi, Naoto Looks pretty good. I have a few comments: -- src/java.base/macosx/classes/sun/util/locale/provider/HostLocaleProviderAdapterImpl.java 572 map = new HashMap<>(); FWIW, I believe the HashMap could be pre-sized using 'names.length'. --

[14] RFR: 8233579: DateFormatSymbols.getShortMonths() return wrong string on es_CL, es_CO locales

Hi, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8233579 The proposed changeset is located at: https://cr.openjdk.java.net/~naoto/8233579/webrev.00/ The problem was in the CLDR converter where it substitutes the context dependent style names with

Re: RFR (XXS) 8233658 : Escape + in the expression describing Runtime.Version string

Thank you Naoto! Pushed. On 11/6/19 8:24 AM, naoto.s...@oracle.com wrote: Hi Ivan, Looks good to me. Naoto On 11/5/19 9:39 PM, Ivan Gerasimov wrote: Hello! Here's yet another javadoc-only fix. Format of the Runtime.Version string is described as a list of regular expressions [1]:  

Re: RFR: JDK-8233594: create a new option --bind-servces to pass on to jlink

On 06/11/2019 16:35, Michael Paus wrote: I still don't see how entries like this java.desktop provides javax.sound.midi.spi.MidiDeviceProvider used by java.desktop I assume you have this line in the output: java.desktop provides java.net.ContentHandlerFactory used by java.base

Re: RFR: JDK-8233594: create a new option --bind-servces to pass on to jlink

Am 06.11.19 um 16:32 schrieb Alan Bateman: On 06/11/2019 14:01, Michael Paus wrote: The --suggest-providers option would be more useful if one could limit it to the providers that can actually be used by my code, i.e. a call like jlink --add-modules java.base --suggest-providers should

Re: RFR (XXS) 8233658 : Escape + in the expression describing Runtime.Version string

Hi Ivan, Looks good to me. Naoto On 11/5/19 9:39 PM, Ivan Gerasimov wrote: Hello! Here's yet another javadoc-only fix. Format of the Runtime.Version string is described as a list of regular expressions [1]: $VNUM(-$PRE)?\+$BUILD(-$OPT)? $VNUM-$PRE(-$OPT)? $VNUM(+-$OPT)?

Re: RFR: JDK-8233594: create a new option --bind-servces to pass on to jlink

On 06/11/2019 14:01, Michael Paus wrote: The --suggest-providers option would be more useful if one could limit it to the providers that can actually be used by my code, i.e. a call like jlink --add-modules java.base --suggest-providers should only return the providers which can be reached

Re: RFR: JDK-8233594: create a new option --bind-servces to pass on to jlink

Am 06.11.19 um 14:07 schrieb Alan Bateman: On 06/11/2019 12:24, Michael Paus wrote: But this is also a very dangerous option because it may place time-bombs into your packaged applications. For example, I recently realized that I could not make any https-requests any more in my packaged

Re: RFR: JDK-8233594: create a new option --bind-servces to pass on to jlink

On 06/11/2019 12:24, Michael Paus wrote: But this is also a very dangerous option because it may place time-bombs into your packaged applications. For example, I recently realized that I could not make any https-requests any more in my packaged application. To fix that I had to explicitly add

Re: RFR: JDK-8233594: create a new option --bind-servces to pass on to jlink

But this is also a very dangerous option because it may place time-bombs into your packaged applications. For example, I recently realized that I could not make any https-requests any more in my packaged application. To fix that I had to explicitly add "jdk.crypto.ec" to the list of modules for

Re: RFR of JDK-8232446: logging enhancement for rmi when socket closed

On 2019/11/6 5:36 PM, Peter Levart wrote: Hi Hamlin, in TCPTransport.decrementExportCount():  283 try {  284 if (tcpLog.isLoggable(Log.BRIEF)) {  285 tcpLog.log(Log.BRIEF, "close server socket on " + ss);  286 }  287

Re: RFR of JDK-8232446: logging enhancement for rmi when socket closed

Hi Hamlin, in TCPTransport.decrementExportCount():  283 try {  284 if (tcpLog.isLoggable(Log.BRIEF)) {  285 tcpLog.log(Log.BRIEF, "close server socket on " + ss);  286 }  287 ss.close();  288 } catch