Re: no more primitive data types in Java (JDK 10+). What do you think?
On 4/19/2012 6:27 PM, Nasser M. Abbasi wrote:
According to
"To Java SE 8, and Beyond! Simon Ritter Technology Evangelist, Oracle"
(Google the string "To Java SE 8 and Beyond!" and click on
the PDF file, about the 5th link down the page)
On page 42, it says:
"Unified type system (JDK 10+)
No more primitives, make everything objects"
I've seen very little discussion on this very important
subject.
First off, this is listed as an idea (explicitly differentiated from the
earlier bullet points which were presented more as "we really want this
to get in").
What do the experts here think of the idea?
For me, and I am no expert, I think it will be good to have
a consistent type model (everything is an object), but I am
worried that the performance will take a hit (computational finite
elements methods, large meshes, etc...), unless PC's and computers
will become 1000 times faster by the time JDK 10+ comes in few years
from now, which might be possible.
The Java language was designed when JIT technology was still moderately
weak. Thanks in large part to Java, the performance of JITs has
drastically improved over the last two decades, while the onset of
JavaScript as a major performance target for JITs has also focused some
of the research into improving performance in those cases. Note that
JavaScript doesn't distinguish between integers and floating points (all
arithmetic in JS is 100% double!), not to mention the problems related
to weak and dynamic typing. This means that the performance assumptions
of what would be slow aren't necessarily the case.
A lot of it depends on how the "removal" of primitive types work,
especially considering the need for backwards compatibility in Java. If
they decide to make minimal changes to the VM spec (which, given
history, has been the case), then it may just be compiler sugar for
certain operations. Then again, the slides also indicate a more forceful
modification to the Java type system.
The change, in short, strikes me much more of a "let int be treated as a
subclass of Object." Theorizing possible implementation strategies, it's
extremely feasible [1] to let the cost of this change in terms of
performance be limited entirely to where int is actually used as an
Object--i.e., where it would need to be boxed/unboxed. Given that the
JVM is already capable of optimizing away boxing/unboxing even now, I
suspect that the cost would be even lower than that. In other words,
it's a feature you won't pay for unless you use it.
[1] Basic implementation idea: make a shell class (i.e., the internal
int.class object) otherwise unobservable that inherits from Object.
Whenever you "convert" int -> Object, wrap it in that shell class. It's
fairly simple to implement--I ended up doing something similar in an
undergrad compilers course.
--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth