Hi Andrey,
Not the original author of the code but I guess they are left over from
the old refactorings.
On 7/23/22 11:04 AM, Andrey Turbanov wrote:
Hello.
While I was browsing the source of java.util.TimeZone found a couple
of confusing things:
1. Static methods 'getAvailableIDs' and 'getAvailableIDs' are marked
as synchronized.
But all they do - just delegate call to sun.util.calendar.ZoneInfoFile methods:
public static synchronized String[] getAvailableIDs(int rawOffset) {
return ZoneInfo.getAvailableIDs(rawOffset);
}
public static synchronized String[] getAvailableIDs() {
return ZoneInfo.getAvailableIDs();
}
It seems 'synchronized's are unnecessary there. Am I right?
There's a piece of very old code in this JIRA issue:
https://bugs.openjdk.org/browse/JDK-4250355
where getAvailableIDs() was doing some logic within the method, but
since then the code has been refactored to simply call `ZoneInfo`. So I
think you are correct, but I am hesitant to remove it as this is a
sensitive code for the JDK startup.
2. There is confusing NPE catch in a method 'java.util.TimeZone#setDefaultZone'
try {
zoneID = getSystemTimeZoneID(javaHome);
if (zoneID == null) {
zoneID = GMT_ID;
}
} catch (NullPointerException e) {
zoneID = GMT_ID;
}
Only possible source of NPE here is the method 'getSystemTimeZoneID'.
I checked native sources and it seems there is no NPE thrown.
Can we remove the catch (NullPointerException) then?
It could be that it was meant to avoid the case where `java.Home` could
be null, before the fix to StaticProperty change. So I think this one
can be removed.
Naoto
