Re: RFR: 8153955: java.util.logging.FileHandler can not create file synchronously over 101 access

Hi Ramanand, This looks good to me. best regards, -- daniel On 22/06/16 06:21, Ramanand Patil wrote: Thank you Sean. Updated Webrev: http://cr.openjdk.java.net/~rpatil/8153955/webrev.03/ Regards, Ramanand. -Original Message- From: Seán Coffey Sent: Friday, June 17, 2016 9:34 PM

Re: RFR 8159245: Loggers created by system classes are not initialized correctly when configured programmatically from application code.

Hi Hamlin, On 22/06/16 02:40, Hamlin Li wrote: Just another minor comment, I'm not sure if following line is necessary in Logger.java, as it's already been checked in LogManager.java line 577: 439 if (cfg == other) return cfg; Yes, you're right - but it makes sense for the method to have it

RE: RFR: 8153955: java.util.logging.FileHandler can not create file synchronously over 101 access

Thank you Sean. Updated Webrev: http://cr.openjdk.java.net/~rpatil/8153955/webrev.03/ Regards, Ramanand. -Original Message- From: Seán Coffey Sent: Friday, June 17, 2016 9:34 PM To: Ramanand Patil; Daniel Fuchs; Bernd Eckenfels; core-libs-dev@openjdk.java.net Subject: Re: RFR:

Re: RFR 8159245: Loggers created by system classes are not initialized correctly when configured programmatically from application code.

Hi Daniel, Thank you for detailed explanation, new version makes sense to me. Just another minor comment, I'm not sure if following line is necessary in Logger.java, as it's already been checked in LogManager.java line 577: 439 if (cfg == other) return cfg; Thank you -Hamlin On 2016/6/21

Re: [9] RFR: 8022291: Mac OS: Unexpected JavaLaunchHelper message displaying

> JBS: > https://bugs.openjdk.java.net/browse/JDK-8022291 > > Webrev: > http://cr.openjdk.java.net/~ddehaven/8022291/jdk.0/index.html > > This actually turned out to be pretty easy to fix, I eliminated the > JavaLaunchHelper class and in place of it stuffed the block it replaced into > a

Re: RFR 9 7131356 : (props) "No Java runtime present, requesting install" when creating VM from JNI [macosx]

Actually, j.u.Locale class' "country" code is defined as ISO-3166 alpha-2 *or* UN M.49 numeric-3 area code, so if the OSX's underlying setting is "es-419" for the preferred language, "user.country" should be "419". Naoto On 6/21/16 3:17 PM, Brent Christian wrote: Hi, Naoto "Spanish (Latin

Re: RFR 9 7131356 : (props) "No Java runtime present, requesting install" when creating VM from JNI [macosx]

Hi, Naoto "Spanish (Latin America)" already works the same as it did before the change - it maps to "es_XL". Because "es-419" has more than 2 characters following the '-', no change is made and getMacOSXLocale(LC_MESSAGES) returns "es-419". I added a mapping for "es-419" -> "es_XL" in

Re: RFR 9 7131356 : (props) "No Java runtime present, requesting install" when creating VM from JNI [macosx]

Hi Brent, I looked at the system preference setting panel and noticed there is "Spanish (Latin America)", which I think uses UN M.49 code ("es-419") as the designate region. Can you make changes to deal with it? (sorry I should have noticed this earlier, and it's unfortunate not to be able to

Re: [9] RFR: 8159548: Formatter returns unexpected strings if locale is null.

+1 On 6/16/16, 2:48 PM, Naoto Sato wrote: Hi, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8159548 The proposed fix is located at: http://cr.openjdk.java.net/~naoto/8159548/webrev.00/ The previous fix to 8146156 overly localized the formatted text

Re: RFR: 8150173: JAXBContext.newInstance causes PrivilegedActionException when createContext's declared in absract class extended by discovered JAXB implementation

> On Jun 21, 2016, at 10:39 AM, Daniel Fuchs wrote: > > Hi, > > Please find below a somewhat trivial patch for > > 8150173: JAXBContext.newInstance causes PrivilegedActionException > when createContext's declared in absract class extended > by

[9] RFR: 8022291: Mac OS: Unexpected JavaLaunchHelper message displaying

JBS: https://bugs.openjdk.java.net/browse/JDK-8022291 Webrev: http://cr.openjdk.java.net/~ddehaven/8022291/jdk.0/index.html This actually turned out to be pretty easy to fix, I eliminated the JavaLaunchHelper class and in place of it stuffed the block it replaced into a NSBlockOperation then

Re: RFR: 8150680 JarFile.Release enum needs reconsideration with respect to it's values

Hi Paul, > Hi. I would like to point out that it appears JarFile.Release enum is > specifically tailored to address multi-version jar specification. I think you are looking at the current code, not the webrev. What the webrev does is remove the JarFile.Release enum. > However, I find nothing

Re: [jdk9] RFR: 8159822: Non-synchronized access to shared members of com.sun.jndi.ldap.pool.Pool

On 21.06.2016 18:43, Aleksey Shipilev wrote: On 06/21/2016 06:14 PM, Ivan Gerasimov wrote: Hello! The Pool has a member `map`, which is accessed from different threads, thus the access is synchronized. However, in some code paths (mostly in debug printing) it is accessed without proper

Re: RFR 8159245: Loggers created by system classes are not initialized correctly when configured programmatically from application code.

> On Jun 21, 2016, at 8:39 AM, Daniel Fuchs wrote: > > I don't understand this scenario. > ConfigurationData should remain as simple as possible. > Logger.getLogger() / LogManager.demandSystemLogger() will never return > a logger before it has been configured. > When

Re: [jdk9] RFR: 8159822: Non-synchronized access to shared members of com.sun.jndi.ldap.pool.Pool

On 06/21/2016 06:14 PM, Ivan Gerasimov wrote: > Hello! > > The Pool has a member `map`, which is accessed from different threads, > thus the access is synchronized. > However, in some code paths (mostly in debug printing) it is accessed > without proper synchronization, which results in

Re: RFR 8159245: Loggers created by system classes are not initialized correctly when configured programmatically from application code.

On 21/06/16 16:12, Mandy Chung wrote: On Jun 21, 2016, at 4:54 AM, Daniel Fuchs wrote: Hi Hamlin, I was mistaken in my first assessment. The case where the system handler's list is not empty should only happen if by misfortune two different threads happen to

Re: RFR(L): 8143211: provide bytecode intrinsics for loop and try/finally executors

Hi Michael, this looks quite good to me. Forgettable ramblings: MethodTypeForm: could it be beneficial to have a cleaner to remove mappings from loopLambdaForms various LambdaForms are GCd? InvokerBytecodeGenerator/IntrinsicMethodHandle: stringly typed localStateDesc seems like a wart to

[jdk9] RFR: 8159822: Non-synchronized access to shared members of com.sun.jndi.ldap.pool.Pool

Hello! The Pool has a member `map`, which is accessed from different threads, thus the access is synchronized. However, in some code paths (mostly in debug printing) it is accessed without proper synchronization, which results in intermediate ConcurrentModificationException when the debug

Re: RFR 8159245: Loggers created by system classes are not initialized correctly when configured programmatically from application code.

> On Jun 21, 2016, at 4:54 AM, Daniel Fuchs wrote: > > Hi Hamlin, > > I was mistaken in my first assessment. > > The case where the system handler's list is not empty > should only happen if by misfortune two different threads > happen to attempt to merge the same two

Re: RFR 8158880: java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java fail with zh_CN locale

Hi Bhanu, It can be problematic to change the default Locale for the entire process, especially since many tests are run in the same process. It would be preferable to set the locale in the DateTimeFormatter builder instead of changing the process wide Locale. Please identify the specific

Re: Get user.dir as a symlink not resolved

Hi Max, The user.dir system property returns the value from the Unix 'getcwd' function which is defined as the absolute pathname. An absolute pathname would be preferred over a symbolic link which would need to be constantly re-evaluated because it might be changed externally. The absolute

Re: RFR 8159245: Loggers created by system classes are not initialized correctly when configured programmatically from application code.

Hi Hamlin, I was mistaken in my first assessment. The case where the system handler's list is not empty should only happen if by misfortune two different threads happen to attempt to merge the same two configurations concurrently. Though of no consequence for level, filter, etc... (single

RFR 8158880: java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java fail with zh_CN locale

Hi all, May I request you to review fix for following issue Bug id: https://bugs.openjdk.java.net/browse/JDK-8158880 Solution: To avoid test failure in non english locales, set the default locale while initial test setup Webrev: http://cr.openjdk.java.net/~bgopularam/JDK-8158880/webrev.00/

Get user.dir as a symlink not resolved

I'm on a Mac inside /tmp, which is a symlink to /private/tmp. System.getProperty("user.dir") shows me "/private/tmp". Is there a way to get "/tmp" which is exactly what `pwd` return? I only like "/private/tmp" if I called "cd /private/tmp". Thanks Max

Re: RFR 8159245: Loggers created by system classes are not initialized correctly when configured programmatically from application code.

On 21/06/16 04:29, Hamlin Li wrote: Hi Daniel, I just has one simple question. In new version, in Logger::importConfig, userParentHandlers, filter, levelObject are copied from other(ConfigurationData) unconditionally, handlers in other are only *copied *when it's empty in system. In previous