Praveen Kumar M K wrote:
My question - In case I'm working on a 64-bit machine, although the machine can support (2^64 - 1) to (-2^64) integral values, I cant utilize all of that since "int" is 4 bytes only in Java. Is that right? If so, atleast in higher versions of Java why was this not changed?
Praveen Kumar M K wrote:am sure there is loss of accuracy
Jeff Verdegan wrote:you can use long and double
Praveen Kumar M K wrote:but am sure that this cant be the only reason to hold back
Regards,
Anayonkar Shivalkar (SCJP, SCWCD, OCMJD, OCEEJBD)
No, you do not assume 32 bits. You might use 37 bits, or 21 bits, or 44 bits, for all the JVM cares. Portability means you load a 32 bit JRE/JDK or a 64 bit JDK/JRE, and then forget all about how many bits. And when Java™ came out about 16 years ago, there were still people using 16 bit computers, who couldn’t perceive any difference from a 32 bit machine.Praveen Kumar M K wrote: . . . assuming a 32-bit machine with 8-bit/byte and IEEE754 floating-point math, . . .
Praveen Kumar M K wrote:But wouldnt it be better to upgrade?
I mean currently, whether its a 32-bit system or a high-end system the precision of calculations is currently still the same, am sure there is loss of accuracy.
I'm guessing that backward compatibility would be an issue - If JLS were to redefine int as 8 bytes in a new major version, then programs/JVM of the older version wouldn't probably work...but am sure that this cant be the only reason to hold back.
If JLS were to redefine int as 8 bytes in a new major version, then programs/JVM of the older version wouldn't probably work...but am sure that this cant be the only reason to hold back.
Praveen Kumar M K wrote:Not completely
Every new version any language, let alone Java, comes up with newer features and gets rid of the older not-so-useful ones.
HOLD ON THERE, I need a clarification - In Java parlance, are portability and backward compatibility defined only in the confines of the basic constructs? Constructs that were created back during Java 1.1? I mean, util is just a package, if I had written a program without the functions of this package during 1.1, it should work in the current version.
Jeff : However, there's a huge difference between deprecating methods in the Date class in the API and changing the format of a fundamental data type in the language.
Praveen Kumar M K wrote:About the 32-bit and 64-bit query, my thought process is like this - The hardware has advanced over the years. Even a normal respectable PC configurations today were thing-of-the-mighty in the past. We might come to replace every 32-bit with a 64-bit and every 64-bit with a 128-bit thereby putting more information into each "word".
Double.MaxValue is the greatest number that I can define no matter how big the background system is.(Please correct me if there is a work around).
I agree however that the same language has to cater to an 8-bit microprocessor too, but then, until when?
Jeff Verdegan wrote:
Nobody ever "settled for" a 32-bit int in Java because a 64-bit long wouldn't work on his 32-bit hardware. It's always been, "If you need 64 bits, use a long. If you don't, use an int."
Praveen Kumar M K wrote:
Jeff Verdegan wrote:
Nobody ever "settled for" a 32-bit int in Java because a 64-bit long wouldn't work on his 32-bit hardware. It's always been, "If you need 64 bits, use a long. If you don't, use an int."
This is the thing that I missed or let me say misunderstood! I went through a very old javaworld article and I'll quote verbatim -
Unfortunately, the features that make Java so portable have a downside. Java assumes a 32-bit machine with 8-bit bytes and IEEE754 floating-point math. Machines that don't fit this model, including 8-bit microcontrollers and Cray supercomputers, can't run Java efficiently. For this reason, we should expect C and C++ to be used on more platforms than the Java language. We also should expect Java programs to port easier than C or C++ between those platforms that do support both.
This made me think if an efficiency problem is already known, why was it not changed.
Praveen Kumar M K wrote:This is the thing that I missed or let me say misunderstood! I went through a very old javaworld article and I'll quote verbatim -
Unfortunately, the features that make Java so portable have a downside. Java assumes a 32-bit machine with 8-bit bytes and IEEE754 floating-point math. Machines that don't fit this model, including 8-bit microcontrollers and Cray supercomputers, can't run Java efficiently. For this reason, we should expect C and C++ to be used on more platforms than the Java language. We also should expect Java programs to port easier than C or C++ between those platforms that do support both.
This made me think if an efficiency problem is already known, why was it not changed.
Campbell Ritchie wrote:All sorts of things have changed in the 15 years since that article appeared.
Campbell Ritchie wrote:All sorts of things have changed in the 15 years since that article appeared.
Praveen Kumar M K wrote:
I see that C# and .NET's CLR also proclaim of incorporating portability. But I havent come across a .NET CLR for non-Windows machines from Microsoft. Any idea why? There is an open source project called "Mono" but of course, there is no official support.
Praveen Kumar M K wrote:An off-topic question -
I see that C# and .NET's CLR also proclaim of incorporating portability. But I havent come across a .NET CLR for non-Windows machines from Microsoft. Any idea why? There is an open source project called "Mono" but of course, there is no official support.
OCPJP
In preparing for battle I have always found that plans are useless, but planning is indispensable. -- Dwight D. Eisenhower
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime. |