changements de TimeZone.setDefault dans JDK6

Question

Je viens de remarquer que JDK 6 a une approche différente de la fixation d'un décalage horaire par défaut que JDK5.

Auparavant, la nouvelle valeur par défaut serait stocké dans une variable de thread local. Avec JDK6 (je viens en revue 1.6.0.18) la mise en œuvre a changé, de sorte que si l'utilisateur peut écrire à la propriété « user.timezone », ou s'il n'y a pas SecurityManager installé, le fuseau horaire change VM à l'échelle! Sinon, un changement de thread local se produit.

Ai-je tort? Cela semble être tout à fait un changement radical, et je ne pouvais pas trouver quoi que ce soit sur le web à ce sujet.

Voici le code JDK6:

 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);
  }
 }

en avant (en JDK5), il était tout simplement:

 /**
  * 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);
 }

Answer 1

recherche dans la base de données de bogues était en fait une assez bonne idée:)

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

et aussi (re docs):

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

Résumé: JDK 1.5 a été une exception à la règle, avec JDK 1.6 les choses sont de retour à la « normale », qui, selon les documents, est qu'un changement de fuseau horaire est large VM

.

Answer 2

a probablement été fait pour corriger un bug. Je cherche bugs.sun.com pour trouver la justification. (Clues peut être trouvé aussi dans le notes de version . )

Answer 3

La documentation de l'API pour TimeZone.getDefault () indique que « la source de la valeur par défaut TimeZone peut varier la mise en œuvre. » Si votre code repose sur la mise en œuvre des comportements spécifiques des classes API standard (dans ce cas, que la zone horaire par défaut est maintenu à un fil de niveau local), vous devez vous attendre que votre code échoue avec les nouvelles versions de la machine virtuelle ou avec des machines virtuelles de différents les vendeurs.