no more primitive data types in Java (JDK 10+). What do you think?

[Nasser M. Abbasi]

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.

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.

Any one knows more information about this item?
Any truth to it? Do you think it will really happen?

--Nasser

 

[Arne Vajhøj]

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.

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.

Any one knows more information about this item?
Any truth to it? Do you think it will really happen?

C# has it that way. No performance problem. It should
certainly be possible to implement.

(note: everything object does not imply everything
a reference type)

I don't know if it will actually happen.

And I don't think the practical impact will be big
if it does happen (neither performance nor the way Java code
is written).

Arne

 

[Lew]

C# has it that way. No performance problem. It should
certainly be possible to implement.

(note: everything object does not imply everything
a reference type)

And reference type doesn't inherently imply a performance hit. Java's Hotspot famously enregisters and stack-allocates objects under the hood when it deems it felicitous.

I don't know if it will actually happen.

And I don't think the practical impact will be big
if it does happen (neither performance nor the way Java code
is written).

And it is quite likely that computers will be enough faster, if not 1000 times so, before Java 10 comes out. How much longer for even Java 8, and how long was it between 6 and 7? Java usually has had about two years between versions, meaning that Java 10 might be out in 2017. The very paradigm for computing might render the notion of "primitives" irrelevant by then. Even assuming current computing models, Moore's Law hints that we might see an eightfold increase in computer power by then.

There is a movement in the Java community for value objects, as opposed to references, in support of Arne's point.

There's also the point that source distinctions might look different in bytecode or machine code. What we might think of as an 'int' object at the source level might be treated as an ordinary machine integer at the lower level.

 

[Arved Sandstrom]

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.

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.

Any one knows more information about this item?
Any truth to it? Do you think it will really happen?

--Nasser

I think the main idea is a good one. I'd like everything to be an object.

I trust that the language experts can work out the details of optimizing
arrays of objects. I wouldn't restrict it merely to arrays of
single-primitive-value-holder (SPVO) type of objects, but also arrays of
objects that would provably reduce to being composites of such SPVO
objects (this could be recursive); anything in other words where a
sizeof() type of operation would be the same for every object in an array.

I'm not so sure that I'd want to see an actual struct versus reference
distinction as we have in C#. I'd like to think that the objects of a
given class could be situationally value or reference types, not always
be one or the other. Again, it might boil down to the compiler checking
the array type to see if it can be so optimized.

All literals would now be objects, so there'd be common sense syntax
changes there. In terms of my hypothetical scheme there'd also be
questions related to mutable types.

In the final analysis, if the language people can't work out something
acceptable then they are not trying very hard. This is the teens of the
21st century after all.

On a related note I'd like to see some thought put into null. If we go
over to all objects, I'd like to see that uninitialized variables of a
"value" type get the sensible default, not null. So

Integer ints[] = new Integer[10];

would be 10 objects of a value type Integer(0).

AHS

 

[Joshua Cranmer]

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.

 

[Arne Vajhøj]

WTF? If you downloaded the doc yourself (and so obviously must have the
link), just provide the damn link here.

(And no, I was unable to track down the PDF using either Google or Bing...I
did try for a few minutes to follow your ridiculous instructions, to no
avail).
http://qconlondon.com/dl/qcon-londo...r_TheFutureOfTheJavaPlatformJavaSE8Beyond.pdf

It depends on what they mean by "no more primitives, make everything
objects".

[...]

Any one knows more information about this item?
Any truth to it? Do you think it will really happen?

C# has it that way. No performance problem. It should
certainly be possible to implement.

I haven't seen the context, so I don't know if they elaborate or not.
Certainly the statement quoted does not provide enough detail to know
whether they mean a C#-style design or not.

Note that while C# (actually, .NET...the same type system is shared by all
the .NET languages) unifies the types through a common base System.Object
type, that's not the same as having a completely unified type system.
Value types are still fundamentally different from reference types, and
there are most certainly real differences between primitive types in .NET
(which do exist in spite of the unified type system) and user-defined value
types, as well of course between all value types primitive or otherwise and
reference types.

If the original reference simply means introducing something like what .NET
has, then I'd agree it shouldn't cause any sort of performance problem, nor
should be all that disruptive to the Java community itself.

But if the original reference means going further than that, where every
single type is fundamentally the same, where there are genuinely no types
that can be considered "primitive" (i.e. handled in ways by the compiler
that are special to those types and unavailable to user-defined types),
then doing that without sacrificing some performance could in fact be
harder or even impossible.

Let me copy a bit more from page 42:

<quote>
* Unified type system (JDK 10+)
* No more primitives, make everything objects
* Other type reification (JDK 10+)
* True generics
* Function types
* Data structure optimizations (JDK 10+)
* Structs, multi-dimensional arrays, etc
</quote>

It sounds as if it could be relative close to the C# way.

Arne

 

[Arne Vajhøj]

I think the main idea is a good one. I'd like everything to be an object.

It is obviously a good idea.

I just don't think it will be that important.

I'm not so sure that I'd want to see an actual struct versus reference
distinction as we have in C#. I'd like to think that the objects of a
given class could be situationally value or reference types, not always
be one or the other. Again, it might boil down to the compiler checking
the array type to see if it can be so optimized.

They do mention the term "struct", so ...

All literals would now be objects, so there'd be common sense syntax
changes there. In terms of my hypothetical scheme there'd also be
questions related to mutable types.

In the final analysis, if the language people can't work out something
acceptable then they are not trying very hard. This is the teens of the
21st century after all.

On a related note I'd like to see some thought put into null. If we go
over to all objects, I'd like to see that uninitialized variables of a
"value" type get the sensible default, not null. So

Integer ints[] = new Integer[10];

would be 10 objects of a value type Integer(0).

I would expect "backwards compatibility" to be a concept
frequently mentioned in the design discussions.



Arne

 

[Nasser M. Abbasi]

WTF? If you downloaded the doc yourself (and so obviously must have the
link), just provide the damn link here.

Hello Peter,

The reason I did not put the link, is because Google has some way of
making some links so very long (it seems to encode them somehow?),
so that the link was very long. If I have put the link I was
using at the time, people here would have screamed at me, and the link
would also have broken anyway, since my Thunderbird news reader that I use
does not allow more than 132 long lines.

Here is the link I was looking at

http://www.google.com/url?sa=t&rct=j&q="to java se 8 and
beyond!%22%20&source=web&cd=5&ved=0CEQQFjAE&url=http%3A%2F%2
Fqconlondon.com%2Fdl%2Fqcon-london
2012%2Fslides%2FSimonRitter_TheFutureOfTheJavaPlatformJavaSE8Beyond.pdf
&ei=K8WQT43LI9Octweh-ZnqBA&usg=AFQjCNF8M1Xi7sGluyZu-lMDVQksqqm1sg&cad=rja

Googling a string is just as easy. I am not sure where you could
not find it. Here is a screen shot when I Google the string, and
you can see the PDF file is right there, the 5th link as I said

http://12000.org/tmp/april_19_2012/screen_shot.png

Sorry for any trouble that my instructions have caused you,
but I hope you understand more now why.

--Nasser

 

[Lew]

This is the teens of the 21st century after all.

Quibble: Not until next year.

 

[Tsukino Usagi]

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.

What do the experts here think of the idea?

It's impossible. Whatever they mean when they say "remove primitives"
cannot possibly be what those words actually mean. Just think, how would
it be possible to state a = a + 1 without the number 1? Ok, so you can
use .add(Integer x). But how precisely do you call it? .add(1)? There's
still a 1. And what's worse is if numbers act like objects, which
introduces it's own dangerous problem. Is the number 5 really 5, or is
it something else? Treating primitives like objects, without them
actually being objects, is UN-neccessary and confusing.

5.length() or 5.size()? Well if 5 is an object I should be able to
over-ride it.

Class 6 Extends 14 {}

Is that what they mean, or do they mean they will just treat numbers
/like/ objects? I guess I need more information. In the absence of a
good reason, I don't believe such a change will ever actually make it
into Java.

 

[Stefan Ram]

Is that what they mean, or do they mean they will just treat numbers
/like/ objects? I guess I need more information. In the absence of a
good reason, I don't believe such a change will ever actually make it
into Java.

I suggest, you might learn some Smalltalk or at least Ruby.

 

[Arved Sandstrom]

It's impossible. Whatever they mean when they say "remove primitives"
cannot possibly be what those words actually mean. Just think, how would
it be possible to state a = a + 1 without the number 1? Ok, so you can
use .add(Integer x). But how precisely do you call it? .add(1)? There's
still a 1. And what's worse is if numbers act like objects, which
introduces it's own dangerous problem. Is the number 5 really 5, or is
it something else? Treating primitives like objects, without them
actually being objects, is UN-neccessary and confusing.

5.length() or 5.size()? Well if 5 is an object I should be able to
over-ride it.

Class 6 Extends 14 {}

Is that what they mean, or do they mean they will just treat numbers
/like/ objects? I guess I need more information. In the absence of a
good reason, I don't believe such a change will ever actually make it
into Java.

However they do things there will be problems and concerns. What you
talk about is not likely to be one of them. In a system where all things
are objects, numeric literals are objects: they are syntactic sugar.

a = 2;

really means

a = new Integer(2);

and

a = a + 1;

means that a is some Number and you're adding Integer(1) to it. Who
cares that underneath the hood the compiler translates that to (int)13 +
(int)1?

Just because you've got literals doesn't mean that you need primitives.

As for instance calls on a literal, you and I already do that with
String literals. E.g. "some string".length().

I think you can see that in your example '5' is an instance; Java is
class-oriented for inheritance/extension, not object-oriented, so you
won't be extending an instance. But yes, we'd expect that you could do
5.someMethod(), for instance methods that make sense.

AHS

 

[Roedy Green]

"Unified type system (JDK 10+)
No more primitives, make everything objects"

This is the way Eiffel works, but under the covers there are still
primitives. Perhaps what they have in mind for Java, more intelligent
boxing. At least at the low levels of the JVM you need primitives.
--
Roedy Green Canadian Mind Products
http://mindprod.com
When you were a child, if you did your own experiment
to see if it was better to put to cocoa into your cup first
or the hot milk first, then you likely have the programmer gene..

 

[Tsukino Usagi]

I suggest, you might learn some Smalltalk or at least Ruby.

I can see myself learning smalltalk for the bragging rights, but there's
no need to bring ruby into this. Ruby has serious problems and I don't
understand why they don't just fix them.

 

[Tsukino Usagi]

However they do things there will be problems and concerns. What you
talk about is not likely to be one of them. In a system where all things
are objects, numeric literals are objects: they are syntactic sugar.

a = 2;

really means

a = new Integer(2);

and

a = a + 1;

means that a is some Number and you're adding Integer(1) to it. Who
cares that underneath the hood the compiler translates that to (int)13 +
(int)1?

Just because you've got literals doesn't mean that you need primitives.

As for instance calls on a literal, you and I already do that with
String literals. E.g. "some string".length().

I think you can see that in your example '5' is an instance; Java is
class-oriented for inheritance/extension, not object-oriented, so you
won't be extending an instance. But yes, we'd expect that you could do
5.someMethod(), for instance methods that make sense.

AHS

I get what your saying, my point was exactly that requiring Integer(1)
is ridiculous. If your going to type "1", type "1" and be done with it.

 

[Robert Klemme]

There's also the point that source distinctions might look different in bytecode or machine code. What we might think of as an 'int' object at the source level might be treated as an ordinary machine integer at the lower level.

As an additional data point: Ruby MRI works like that. Basically
integers (instances of class Fixnum) look like ordinary objects but
under the hood the value is encoded in the reference and there is no
object on the heap. You get a nice consistent model for the language
user but avoid the overhead of GC. Ruby is still not a racing car
compared with other PL - usual trade offs apply. The concept is
described here:
http://en.wikipedia.org/wiki/Tagged_pointer

It could require a signicifant (nice typo, sounds like an animal) change
in the JVM definition though.

Kind regards

robert

 

[Robert Klemme]

I can see myself learning smalltalk for the bragging rights, but there's
no need to bring ruby into this. Ruby has serious problems and I don't
understand why they don't just fix them.

I don't know what "serious problems" you are talking about and this is
probably not the place to discuss them either. But Stefan's hint was a
good one in this context because MRI has a clean object model for the
user with not too bad performance for primitive numbers. (see ref to
Wikipedia article elsewhere in this thread)

Kind regards

robert

 

[Stefan Ram]

I get what your saying, my point was exactly that requiring Integer(1)

It's »Integer.valueOf( 1 )«, not »new Integer( 1 )« and
surely not »Integer( 1 )«.

Arithmetics and similar actions on integer objects can
and probably will be optimized to use effectively the same
processor operations as on primitive values whenever possible.

 

[Robert Klemme]

Rather

a = Interer.valueOf(2)

as it is done already today with autoboxing. But yes, the literal can
be translated to anything.

I get what your saying, my point was exactly that requiring Integer(1)
is ridiculous. If your going to type "1", type "1" and be done with it.

I am sorry, but that statement proves that you did not get the point.

Cheers

robert

 

[BGB]

Yeah, but you have to take into account the kind of people who insisted
that the new millennium started on Jan 1, 2000. The concept of "teens"
may be more, um...flexible to some people than to others.

(For the record, I'm with you, but I hardly ever try to explain this sort
of mistake to people who make them any more )

I think for many, "teens" starts at 10 (rather than 13), so 2010-2019
would be the "teens" of the new millennium.

nevermind, many people apparently believe that the world will end in a
few months from now.


as for the topic:
I just kind of find it funny, I express some annoyances with the JVM:
lack of value types, awkward FFI, ...
people then make a fuss about it, counter-arguing (unnecessary, wouldn't
help, ...).

Oracle then goes stating plans to go work on it.

even more funny would be if they added extensions for pointers and RAII
and similar, but this seems less likely.


it was not stated what sort of FFI design Oracle is considering.


in my own VM/language, I did like this (a boilerplate-free FFI), and
used an HLL-level interface for importing roughly like:

native import C.stdio; //import C's "stdio.h"

actually, it doesn't directly import the header (the actual mechanism is
more convoluted, as it aliases the header-name to a target-specific
library-name, and imports the library instead, and the contents of the
"headers" are aliases to a DB keyed with the same name as the library).

(say, "C.stdio" maps to "msvcrt.dll", and loads the "msvcrt_meta" DB).

the "C." prefix basically indicates the intended target language (of
which, C is the currently only supported option).


exporting works more like:
native package C.foo
{
struct SomeStruct
{
...
}

...

function somefunc(x:int):void //takes int, returns void
{
...
}

//takes C-string, returns struct pointer
function somefunc(str:cstring):*SomeStruct
{
...
}

...
}

with anything declared within the package being exported to C land, and
expected to conform to C-friendly rules (the language also has pointers,
for sake of easing C interfacing, which have a syntax like "x:*void;").
pardon the strange syntax.

the mechanism in this case currently involves using a tool which spits
out headers and C-based glue-code though (which are then compiled and
linked with native code), as I do not yet know of a clearly better
option here (C lacks late-binding...).


a Java analogue could be, say:
public native class Foo
{
...
public static void somefunc(int x)
{
...
}
}

with any static methods within the class being exported as native C or
C++ functions or similar.

maybe also doing direct cross-language class-to-class mappings, like in
GCJ (where class-members can be identity-mapped across the language
boundary).


or such...