JDK6 中的 TimeZone.setDefault 更改

发布于 2024-08-20 08:00:59 字数 1598 浏览 5 评论 0原文

我刚刚注意到 JDK 6 设置默认时区的方法与 JDK5 不同。

以前,新的默认值将存储在线程局部变量中。使用 JDK6(我刚刚回顾了 1.6.0.18),实现发生了变化,因此,如果用户可以写入“user.timezone”属性,或者如果没有安装 SecurityManager,则时区会在虚拟机范围内更改!否则会发生线程局部更改。

我错了吗?这似乎是一个相当大的变化,我在网上找不到任何关于它的信息。

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

而之前(在 JDK5 中)它很简单:

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

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

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

虫児飞 2024-08-27 08:00:59

搜索 Java Bug 数据库 实际上是个好主意:)

JDK-6352812 : (tz) 回归:JDK 1.5 TimeZone.setDefault() 与 JDK 1.4 和 Mustang 不一致

(重新文档):

JDK-6181786 :(tz) TimeZone.getDefault() 和的文档TimeZone.setDefault() 应该更清晰

摘要:JDK 1.5 是一个例外,JDK 1.6 的情况又恢复到“正常”,根据文档,时区更改是 VM 范围内的。

Searching the Java Bug Database was actually quite a good idea :)

JDK-6352812 : (tz) REGRESSION: JDK 1.5 TimeZone.setDefault() inconsistent with JDK 1.4 and Mustang

and also (re docs):

JDK-6181786 : (tz) Documentation for TimeZone.getDefault() and TimeZone.setDefault() should clearer

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.

独自唱情﹋歌 2024-08-27 08:00:59

这样做可能是为了修复一个错误。我会搜索 Java Bug 数据库 以找到其基本原理。 (线索也可以在发行说明.)

This was probably done to fix a bug. I'd search the Java Bug Database to find the rationale for it. (Clues might also be found in the release notes.)

无法言说的痛 2024-08-27 08:00:59

TimeZone.getDefault() 的 API 文档指出“默认 TimeZone 的来源可能会因实现而异。”如果您的代码依赖于标准 API 类的实现特定行为(在本例中,默认时区保持在线程本地级别),则您必须预期您的代码会因使用较新版本的 VM 或来自不同版本的 VM 而失败。供应商。

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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文