English 中文(简体)
TimeZone.setDefault changes in JDK6
原标题:

I just noticed that JDK 6 has a different approach to setting a default TimeZone than JDK5.

Previously the new default would be stored in a thread-local variable. With JDK6 (I just reviewed 1.6.0.18) the implementation has changed, so that if the user can write to the "user.timezone" property, or if there is no SecurityManager installed, the timezone changes VM-wide! Otherwise a thread-local change occurs.

Am I wrong? This seems to be quite a drastic change, and I couldn t find anything on the web about it.

Here is the JDK6 code:

 private static boolean hasPermission() {
  boolean hasPermission = true;
  SecurityManager sm = System.getSecurityManager();
  if (sm != null) {
   try {
    sm.checkPermission(new PropertyPermission("user.timezone", "write"));
   } catch (SecurityException e) {
    hasPermission = false;
   }
  }
  return hasPermission;
 }

 /**
  * Sets the <code>TimeZone</code> that is
  * returned by the <code>getDefault</code> method.  If <code>zone</code>
  * is null, reset the default to the value it had originally when the
  * VM first started.
  * @param zone the new default time zone
  * @see #getDefault
  */
 public static void setDefault(TimeZone zone)
 {
  if (hasPermission()) {
   synchronized (TimeZone.class) {
    defaultTimeZone = zone;
    defaultZoneTL.set(null);
   }
  } else {
   defaultZoneTL.set(zone);
  }
 }

while before (in JDK5) it was simply:

 /**
  * Sets the <code>TimeZone</code> that is
  * returned by the <code>getDefault</code> method.  If <code>zone</code>
  * is null, reset the default to the value it had originally when the
  * VM first started.
  * @param zone the new default time zone
  * @see #getDefault
  */
 public static synchronized void setDefault(TimeZone zone)
 {
  defaultZoneTL.set(zone);
 }
最佳回答

Searching the bugs database was actually quite a good idea :)

http://bugs.sun.com/view_bug.do?bug_id=6352812

and also (re docs):

http://bugs.sun.com/view_bug.do?bug_id=6181786

Summary: JDK 1.5 was an exception to the rule, with JDK 1.6 things are back to normal , which, according to the docs, is that a timezone change is VM wide.

问题回答

This was probably done to fix a bug. I d search bugs.sun.com to find the rationale for it. (Clues might also be found in the release notes.)

The API documentation for TimeZone.getDefault() states that "the source of the default TimeZone may vary with implementation." If your code relies on implementation specific behaviour of the standard API classes (in this case, that the default time zone is kept at a thread local level), you must expect that your code fails with newer versions of the VM or with VMs from different vendors.





相关问题
Spring Properties File

Hi have this j2ee web application developed using spring framework. I have a problem with rendering mnessages in nihongo characters from the properties file. I tried converting the file to ascii using ...

Logging a global ID in multiple components

I have a system which contains multiple applications connected together using JMS and Spring Integration. Messages get sent along a chain of applications. [App A] -> [App B] -> [App C] We set a ...

Java Library Size

If I m given two Java Libraries in Jar format, 1 having no bells and whistles, and the other having lots of them that will mostly go unused.... my question is: How will the larger, mostly unused ...

How to get the Array Class for a given Class in Java?

I have a Class variable that holds a certain type and I need to get a variable that holds the corresponding array class. The best I could come up with is this: Class arrayOfFooClass = java.lang....

SQLite , Derby vs file system

I m working on a Java desktop application that reads and writes from/to different files. I think a better solution would be to replace the file system by a SQLite database. How hard is it to migrate ...

热门标签