On 4/7/2016 2:44 AM, Naoto Sato wrote:
Looks good overall. Here are my suggestions.
Thank you for your quick review.
- DateFormatSymbols.java: We could cache all candidate locales, e.g.,
if the requested locale is ja_JP_JP, and the bundle locale is ja, we
could also put ja_JP bundle in the
Looks good overall. Here are my suggestions.
- DateFormatSymbols.java: We could cache all candidate locales, e.g., if
the requested locale is ja_JP_JP, and the bundle locale is ja, we could
also put ja_JP bundle in the cache.
- DateFormatSymbolsCloneTest.java: import sentence for the Locale c
Hi all,
Please review the fix for JDK-8151431. clone() is no longer called to
create a cache entry.
Issue:
https://bugs.openjdk.java.net/browse/JDK-8151431
Webrev:
http://cr.openjdk.java.net/~okutsu/9/8151431/webrev.00/
Thanks,
Masayoshi
, 2016 1:46 PM
To: Ramanand Patil; i18n-dev@openjdk.java.net
Cc: core-libs-...@openjdk.java.net
Subject: Re: RFR: JDK-8087104: DateFormatSymbols triggers this.clone() in the
constructor
Looks good to me.
Masayoshi
On 2/24/2016 4:40 PM, Ramanand Patil wrote:
Hi all,
Please review the fix for bug
: Re: RFR: JDK-8087104: DateFormatSymbols triggers this.clone() in the
constructor
Looks good to me.
Masayoshi
On 2/24/2016 4:40 PM, Ramanand Patil wrote:
> Hi all,
> Please review the fix for bug:
> https://bugs.openjdk.java.net/browse/JDK-8087104
> Bug Description: DateFormatSymbol
Looks good to me.
Masayoshi
On 2/24/2016 4:40 PM, Ramanand Patil wrote:
Hi all,
Please review the fix for bug: https://bugs.openjdk.java.net/browse/JDK-8087104
Bug Description: DateFormatSymbols caches its own instance and calls
this.clone() in the constructor. Because of this, any subclass im
Hi all,
Please review the fix for bug: https://bugs.openjdk.java.net/browse/JDK-8087104
Bug Description: DateFormatSymbols caches its own instance and calls
this.clone() in the constructor. Because of this, any subclass implementation
(which expects a field is always initialized to non-null in th
Okutsu-san, Umaoka-san,
OK I got it now. We should cache data fields instead of the object itself.
Naoto
On 6/7/15 10:33 PM, Masayoshi Okutsu wrote:
I think what Umaoka-san pointed out is valid. Overrideable methods
shouldn't be called in a constructor.
Masayoshi
On 6/6/2015 6:53 AM, Naoto S
I think what Umaoka-san pointed out is valid. Overrideable methods
shouldn't be called in a constructor.
Masayoshi
On 6/6/2015 6:53 AM, Naoto Sato wrote:
Umaoka-san,
I believe the cloning is needed to return the defensive copy,
otherwise an app can mutate the state of the DateFormatSymbols f
Sato-san,
Yes, it's not thing wrong to check null in the clone() method, and
that's what I did to avoid this problem. But what we can do there is to
skip cloning the field in our code only.
With the current Java implementation, I'm pretty sure that it won't
cause any actual problem, because
Umaoka-san,
I believe the cloning is needed to return the defensive copy, otherwise
an app can mutate the state of the DateFormatSymbols for other apps. One
solution could be to not cache the instance if its from SPI, but
apparently that will affect the performance. I don't see anything wrong
On 6/5/2015 11:31 AM, Yoshito Umaoka wrote:
@Override
public Object clone() {
MyDateFormatSymbols mdfs = (MyDateFormatSymbols)super.clone();
mdfs.foo = this.foo.clone();
}
Minor correction - "return mdfs;" was missing in the pseudo code above.
-Yoshito
Hi folks,
ICU4J implements Java locale service provider interface. I recently
received a problem report from our customer. When they upgraded Java
version to 8, the provider implementation stopped working because of NPE
thrown by our custom DateFormatSymbols subclass. I dug into the problem
a
13 matches
Mail list logo
