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
