TimeZone implementations questions

[Naoto Sato]

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