为什么java与C不同，数据类型大小是固定的
在 C 中，我们知道数据类型（例如 int）的大小可能因编译器/硬件而异。
但是为什么java语言中数据类型的大小是恒定的呢？为什么我们不能根据编译器灵活地处理 Java 中的不同数据类型大小？
In C as we know the size of data types (ex. int) can vary depending on compiler / hardware.
But why the size of data types is constant in java language? Why don't we have the flexibility for different data type size in java depending on compiler?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
JVM（Java 虚拟机）被设计为独立于平台。如果跨平台的数据类型大小不同，则会牺牲跨平台一致性。
JVM 将程序与底层操作系统和平台隔离。这可能会使执行特定于系统的工作变得困难，但好处是您可以一次编写，随处运行（这在很大程度上是正确的，但存在一些不幸的问题。一次编写，随处测试是一种更实用的方法）。
The JVM (Java Virtual Machine) is designed to be platform independent. If data type sizes were different across platforms, then cross-platform consistency is sacrificed.
The JVM isolates the program from the underlying OS and platform. This can make life difficult for performing system-specific work, but the benefits are that you can write-once, run-anywhere (this is largely true, with some unfortunate issues. Write-once, test-everywhere is a much more practical approach).
如果不同平台上的数据类型大小不同，您就会失去可移植性。
If data type size varies on different platforms you lose portability.
为了获得这个问题的真正全面的答案，您需要阅读大量 Java 早期的历史资料。当然，设计者可以包含一个更复杂的原始类型系统。然而，当Java突然登上广阔的舞台时，它的目标是小应用程序。在浏览器中运行的代码，组织复杂的 UI，不需要（也不需要）知道它是在臭名昭著的 MNS-49（每个字 7 个 7 位字符）上运行，还是在 Honeywell 68000（4 9 -每个字的位字符），或无聊的现代处理器。这比任何人都可以在
int上编写位算术代码并知道 32 次移位后会发生什么更重要。To get a really comprehensive answer to this, you'd need to do a great deal of historical reading from the early days of Java. Certainly, the designers could have included a more complicated primitive type system. However, when Java burst onto the broad stage, it was aimed at applets. Code to run in a browser, organizing complex UI, didn't (and doesn't) need to know whether it is running on the infamous MNS-49 (7 7-bit chars per word), or the Honeywell 68000 (4 9-bit chars per word), or a boring modern processor. It's much more important than anyone can code bit arithmetic on an
intand know what's going to happen after 32 shifts.C 在这方面的灵活性有一些优势（如果使用 32 位而不是 64 位，则会减少内存/存储消耗），但随着硬件的改进，这些优势往往会变得不那么重要（这是在 70 年代设计的）。
然而，这种灵活性伴随着严重的互操作性和长期愿景问题（Y 2038 错误）。
相比之下，Java 对象无论如何都有一些存储开销，因此在每个 Date 对象上保存 4 个字节是毫无意义的，而且只会很麻烦。
The flexibility of C for this has some advantages (reduced memory/storage consumption if you use 32 instead of 64 bits), but these advantages tend to become less relevant as the hardware improves (this was designed in the 70s).
This flexibility however comes with severe interoperability and long-term vision problems (Y 2038 bugs).
In contrast, a Java object has anyway some storage overhead, so saving 4 bytes on each Date object would be quite pointless and only troublesome.
因为那是Java。请参阅 Java 语言规范。
Because that's Java. See the Java language specification.
java的思想是“一次编写，随处运行”，无需重新编译。这意味着每个虚拟机都具有相同的数据大小。当然，在 64 位机器上，它使用 64 位引用，但您无权访问这些引用，所以这并不重要。
它工作得很好，但我确实希望的一件事是希望我们可以获得 64 位数组索引。这在当时并不重要，但对于大型内存映射文件来说这是一个巨大的痛苦。你必须把它们分成 2GB 的块。
The idea of java was "Write once, Run anywhere" without recompiling. That means every VM has the same data size. Of course, on 64 bit machines, it uses 64 bit references, but you don't have access to those so it doesn't matter.
It works pretty well, but one thing I do wish is that wish we could get 64 bit array indexes. This didn't really matter back in the day, but for large memory mapped files it's a huge pain. You have to break them up into 2gb chunks.
C 语言有其自身的优势，即可以改变数据类型的大小。那时主存并不算太多……每个程序员都必须编写空间优化的代码。
如今，空间不再是问题……便携式程序更可取。
这就是为什么让java可移植java不支持不同大小的数据类型
c language has its own advantage of varying the data type size. that time main memory is not too much...every programmer has to write code that is space optimized.
nowadays space is no more a issue...a portable program is much more preferable.
that why to make java portable java do not support varying size datatypes
因为java是平台无关的语言。这就是为什么在java中数据类型的大小是固定的
because java is platform independent language. that's why in java size of data type is fixed