Until recently, JVM vendors were lazy to update time zone rules. Since North America DST change in 2007, JVM vendors pay more attention to time zone rule changes and they are now delivering tzdata patch in timely manner.
In reality, many ICU4J clients have to deal both Java and ICU4J TimeZone. Because ICU4J has own time zone rule data, they have to apply tzdata update patch to both JVM and ICU4J.
There are some benefits to have own tzdata in ICU. For example, ICU allows users to access time zone transitions and rules. This features can be implemented in ICU, because ICU has its own tzdata. But, majority of ICU4J users do no need such advanced features. For those users who do not need advanced time zone features would be good enough with Java TimeZone. They would rather prefer to less maintenance effort.
This ticket proposes ICU4J to support Java TimeZone as primary TimeZone implementation in ICU4J. Actual tasks would be -
1. Add a class extending com.ibm.icu.util.TimeZone. Implementation of time zone operation in the new class actually calls methods in java.util.TimeZone.
2. Create a global switch to alter the behavior of com.ibm.icu.util.TimeZone#getTimeZone. The switch may be implemented as a static method in com.ibm.icu.util.TimeZone or external configuration file.
Some users avoid the dual-update problem by using only the ICU4J TimeZone class where it matters. That's what we advertise: Use ICU (and keep it up to date) and you get the most up-to-date time zone and Unicode and CLDR... behavior.
I think it's ok to add a new wrapper class and a switch, but the default behavior should be as before: getTimeZone() should by default return an instance of ICU's TimeZone class.
In many cases, application developers utilize existing software components/libraries developed by third parties. Even he/she wants to use ICU4J for his/her own Java code, he/she may not be able to modify components/libraries developed by third parties. In this case, his/her decision could be - not using ICU4J because of the maintenance/consistency problem. The primary goal for this ticket is to lower the bar for adopting ICU4J.
I'm not proposing the out of box default to be Java TimeZone. However, the ICU4J clients should be able to control the default behavior globally.
Replying to (Comment 2 markus):
Some users avoid the dual-update problem by using only
the ICU4J TimeZone class where it matters. That's what
we advertise: Use ICU (and keep it up to date) and you
get the most up-to-date time zone and Unicode and CLDR... behavior.
Also, ICU4J depends on underlying JVM's default zone detection. A certain type of change (such as Argentina timezone patch on Windows) requires JVM patch. Thus, updating ICU4J timezone data alone does not work always (you cannot avoid double update problem even you use ICU4J TimeZone only). Also, these days, Java vendors provide up-to-date tzdata in time (sometimes, earlier than Olson tzdata official release).
reviewed icu4j/branches/yoshito/javatz at r23528 to icu4j/trunk at r23528
Milestone 3.9.2 deleted