0

public static native long currentTimeMillis()这是从Java类方法的源代码中提取的注释java.lang.System。

 * Returns the current time in milliseconds.  Note that
 * while the unit of time of the return value is a millisecond,
 * the granularity of the value depends on the underlying
 * operating system and may be larger.  For example, many
 * operating systems measure time in units of tens of
 * milliseconds.

从这个评论中很明显，这个本地方法的行为是平台相关的。如果是这种情况，我们是否应该避免在 Java 中编写真正独立于平台的代码的本地方法调用？

4

1 回答 1

1

从这个评论中可以明显看出，这个本地方法的行为是依赖于平台的。

那是对的。

如果是这种情况，我们是否应该避免在 Java 中编写真正独立于平台的代码的本地方法调用？

不，这不是从中吸取的正确教训。

Java 类库的许多功能最终都依赖于本机调用。如果您决定避免调用本机方法，那么（对于开始）您的程序将无法进行任何 I/O。这将使 Java 变得不切实际。就时间而言，如果您避免使用所有本地方法，那么您将根本无法获得时间。

一些标准 Java API 具有平台特定行为的真正原因是平台本身存在差异。如果不过度限制应用程序的功能， 就无法隐藏这些差异。

在您的示例中，注释解释了不同操作系统提供的系统时钟具有不同的粒度时间度量。这是一个无法回避的事实。隐藏这一点（以“可移植性”的名义）的唯一方法是人为地减少提供毫秒或更高分辨率的系统的粒度。这对于需要可用最大分辨率的人来说是不可接受的。

正确的教训（IMO）如下：

  • 您需要阅读并理解 javadocs 关于平台特定行为的实际说法。

  • 然后您需要设计您的应用程序，使其不依赖于平台特定的行为。例如，如果您需要最大的可移植性，请不要将您的应用程序设计为依赖于毫秒粒度的时钟。

  • 在可能的情况下，使用处理平台细节的 API。例如，在操作文件系统路径名时使用FileorPath而不是字符串攻击。

于 2017-07-06T14:48:23.670 回答