[Bug java/12005] New: TimeZone.getID() produces NPE

[paul at gear dot dyndns dot org]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12005

           Summary: TimeZone.getID() produces NPE
           Product: gcc
           Version: 3.2.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: java
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: paul at gear dot dyndns dot org
                CC: gcc-bugs at gcc dot gnu dot org

Test case:

import java.util.*;


public class TimeZoneTest
{


public static void
main( String[] argv )
{
    TimeZone t = TimeZone.getDefault();
    System.out.println( t );

    String name = t.getDisplayName();
    System.out.println( name );

    String id = t.getID();
    System.out.println( id );
}


}       // class TimeZoneTest


Environment: Red Hat Linux 9, standard packages & errata applied.  My system is
set to time zone "Australia/Brisbane".  Sun j2sdk-1.4.2-fcs RPM (using jikes
1.18 as compiler) produces this result with the above test code:

sun.util.calendar.ZoneInfo[id="Australia/Brisbane",offset=36000000,dstSavings=0,useDaylight=false,transitions=18,lastRule=null]
Eastern Standard Time (Queensland)
Australia/Brisbane

The same test code with gcc-java and libgcj 3.2.2-5 produces:

java.util.SimpleTimeZone[id=UTC,offset=0,dstSavings=3600000,useDaylight=false]
GMT+00:00
Exception in thread "main" java.lang.NullPointerException
   at 0x40222ef2: _Jv_ThrowSignal (/usr/lib/libgcj.so.3)
   at 0x40222f26: ?? (??:0)
   at 0xbfffd26c: ?? (??:0)
   at 0x4026e16d: java.lang.StringBuffer.StringBuffer(java.lang.String)
(/usr/lib/libgcj.so.3)
   at 0x402a2eda: java.util.Locale.toString() (/usr/lib/libgcj.so.3)
   at 0x402a6438: java.util.ResourceBundle.getBundle(java.lang.String,
java.util.Locale, java.lang.ClassLoader) (/usr/lib/libgcj.so.3)
   at 0x402a5e34: java.util.ResourceBundle.getBundle(java.lang.String,
java.util.Locale) (/usr/lib/libgcj.so.3)
   at 0x403091d2:
java.text.DateFormatSymbols.DateFormatSymbols(java.util.Locale)
(/usr/lib/libgcj.so.3)
   at 0x402a7d1f: java.util.TimeZone.getDisplayName(boolean, int,
java.util.Locale) (/usr/lib/libgcj.so.3)
   at 0x08048a73: TimeZoneTest::main(JArray<java::lang::String*>*) (??:0)
   at 0x4024add8: gnu.gcj.runtime.FirstThread.call_main() (/usr/lib/libgcj.so.3)
   at 0x402b502d: gnu.gcj.runtime.FirstThread.run() (/usr/lib/libgcj.so.3)
   at 0x40257c4c: _Jv_ThreadRun(java.lang.Thread) (/usr/lib/libgcj.so.3)
   at 0x402248ac: _Jv_RunMain(java.lang.Class, byte const, int, byte const,
boolean) (/usr/lib/libgcj.so.3)
   at 0x402249cd: JvRunMain (/usr/lib/libgcj.so.3)
   at 0x080489a9: main (??:0)
   at 0x420156a4: __libc_start_main (/lib/tls/libc.so.6)
   at 0x080488ed: _start (../sysdeps/i386/elf/start.S:83)

This seems to be related to the fact that the time zone is not being picked up
correctly in the first place, but doesn't seem to be the same issue as 11941 or
7789.