You cannot hope to have interpreted code running on different architectures with the hope that it runs indentically on each architecture. The point is that native code (and programmers writing such code) take advantage of architecture specific features.
For example, look at the floating point unit on the x86 architecture. It supports 4 kinds of rounding modes (round to nearest even, round to positive infinity, round to negative infinity, round to zero). If someone were writing a scientific application, the possibility that he needs to change the rounding mode of the CPU could arise for various reasons. Such a task is simple in languages such as C.
Java however does not support any rounding mode other than round to nearest even. The reason for this is that some architectures do not support multiple rounding modes (that may be false, since the rounding modes are part of the floating point standard, and any architecture that supports floating point *should* support them), and therefore supporting architecture specific code would make it not portable, defeating the purpose altogether.
Slashdot Mirror
You cannot hope to have interpreted code running on different architectures with the hope that it runs indentically on each architecture. The point is that native code (and programmers writing such code) take advantage of architecture specific features.
For example, look at the floating point unit on the x86 architecture. It supports 4 kinds of rounding modes (round to nearest even, round to positive infinity, round to negative infinity, round to zero).
If someone were writing a scientific application, the possibility that he needs to change the rounding mode of the CPU could arise for various reasons. Such a task is simple in languages such as C.
Java however does not support any rounding mode other than round to nearest even. The reason for this is that some architectures do not support multiple rounding modes (that may be false, since the rounding modes are part of the floating point standard, and any architecture that supports floating point *should* support them), and therefore supporting architecture specific code would make it not portable, defeating the purpose altogether.
Has everyone forgotten minidisc?
5+ hours on a single $2 disc, one battery lasts 50+ hours in a player. ~$100 for a good player.
I think minidisc speaks for itself...