Live data from Hacker News

Java 9 with GPU processing, Java 10 will be all-OOP without primitives

javaworld.com

31–40 of 138 posts

Re: Java 9 with GPU processing, Java 10 will be all-OOP without primitives

#31
post #17
post #6

Earlier quoted context omitted.

I think similar to C# where the primitives are objects is what they want, terribly misleading title I agree. However, I cringe when I think of what this does to performance. The memory overhead of objects in java is pretty high (relative) while primitives are very memory efficient. If they can make the primitives just as efficient, it would be awesome, but I guess its a wait and see. I don't currently mind using the…

In C# primitives are not objects, but they can be boxed into objects. So if you have a class: public class X { public Int32 i; public Int32 j; public Int32 k; } Then it takes 12 bytes + single object overhead (which in MS .NET I believe is two pointers). But if you assign a primitive (e.g. Int32) to an variable of type 'object' then it will be boxed and then require the object overhead. A neat thing about C#/.NET is…

Well, actually, in C# struct instances ARE objects allocated on the stack, instead of the heap.

A parallel can be drawn with C++ in which the user of a class decides on declaration/initialization where to store the object (either on the stack, or on the heap). The difference with C++ is that in C# the author of the class decides where instances of it should be stored, so this decision happens when the class is declared, not when it's used.

Otherwise there are few differences between structs and classes and all differences stem from the differences in storage. For example struct instances must be passed by value and not reference, because by definition stack-allocated values are short-lived and playing with references to stack-allocated values is dangerous. Structs must also have an implicit constructor because stack-allocated values cannot be NULL (logically, you need a reference to represent NULL).

In my experience, all discussions about what is or isn't an object are counter-productive.

What really bugs me about Java is that you cannot build your own types that behave just like the built-in types. For instance you cannot override operators like "+" (which works for primitives or Strings), you cannot override [] (which works for arrays), you cannot declare other stack-allocated structures, arrays are reified and yet you cannot declare your own reified data-structures and so on. The presence of primitives doesn't bother me as much as lacking the means to build my own primitives.

Re: Java 9 with GPU processing, Java 10 will be all-OOP without primitives

#32
post #3

Wow, how can you seriously plan releases of a programming language out to 2021? That is an eternity in this industry. Even 2015 for JDK 9 seems mighty far off, especially accounting for the usual slippage of release dates with big software projects.

Considering it's Java and some people are still thinking about whether to upgrade from 1.5... Yeah - it may make sense in their case.

And considering you own industry, and language basically. YES WE CAN!

Re: Java 9 with GPU processing, Java 10 will be all-OOP without primitives

#35
post #23
post #8

Earlier quoted context omitted.

Classes are already objects. I don't know whether Java 8 will finally introduce function as a data type, but if it does, I'm pretty sure they won't do it the way Ruby blocks work (i.e. block is not an object).

I'd rather they didn't. It would be redundant with inner classes that are already there, I don't like this piling up of features. It would be more interesting if they allowed inner classes to close over non-final variables.

An inner class is the ugly half-brother of a closure. 99% of the time they're used they define just one method.

When they are used for more than 1 method implementations, well ... they shouldn't be inner classes.

They just exist to fill the gap of having no closures. I say this as a long time and affectionate java user but project lambda in JDK8 is long overdue.

Re: Java 9 with GPU processing, Java 10 will be all-OOP without primitives

#36
post #20
post #3

Wow, how can you seriously plan releases of a programming language out to 2021? That is an eternity in this industry. Even 2015 for JDK 9 seems mighty far off, especially accounting for the usual slippage of release dates with big software projects.

Why don't they start now and build Java 2.0 from ground up instead of Java 10 for 2017? That would be way faster and they learned so much by now to make a great successor. Who wants a Java 1.x in 2040?

Because they learned from netscape's mistake, that's why.

http://www.joelonsoftware.com/articles/fog0000000069.html

Re: Java 9 with GPU processing, Java 10 will be all-OOP without primitives

#37

It seems to me that eliminating primitives could be a really bad idea. If you have a class: public class CompoundObject { int i; int j; double k; } This class's data members are all a few bytes away from each other, so once the object is loaded into the CPU cache, all operations should be fast. With boxed types, you might get 3 cache misses when accessing i,j,k. On the other hand, referential transparency can help he…

They don't say how they're implementing it. Given the compiler always knows the actual type of a primitive at compile-time, they can probably implement most of the Object functionality by plugging in the class meta-info at compile-time. When a primitive would need to be boxed, Java programmers are already used to the performance implications of this. The only object functionality I can think of that would be hard to…

The "boxed primitive" types (Integer and so on) should be `final`. This means no inheriting from them, which means no polymorphism, which means their sizes and all operations on them are known statically. This means you can store them as values in the object with no fuss, and you can inline all of their access functions.

Re: Java 9 with GPU processing, Java 10 will be all-OOP without primitives

#39
post #20

Earlier quoted context omitted.

Why don't they start now and build Java 2.0 from ground up instead of Java 10 for 2017? That would be way faster and they learned so much by now to make a great successor. Who wants a Java 1.x in 2040?

Because they learned from netscape's mistake, that's why. http://www.joelonsoftware.com/articles/fog0000000069.html

"You are wasting an outlandish amount of money writing code that already exists."

On the contrary, there has been a number of times that I've completely rewritten some code to use a framework or library that was already battle-tested and more fully-featured than the previous effort. I ended up saving myself from writing code that already exists.

Re: Java 9 with GPU processing, Java 10 will be all-OOP without primitives

#40
post #23

Earlier quoted context omitted.

I'd rather they didn't. It would be redundant with inner classes that are already there, I don't like this piling up of features. It would be more interesting if they allowed inner classes to close over non-final variables.

An inner class is the ugly half-brother of a closure. 99% of the time they're used they define just one method. When they are used for more than 1 method implementations, well ... they shouldn't be inner classes. They just exist to fill the gap of having no closures. I say this as a long time and affectionate java user but project lambda in JDK8 is long overdue.

They are there, they have been there for over ten years, much code exists that needs them to be there. You can't take them out of the language.

More syntax sugar for them would be good, adding first class functions IMHO isn't good.

Post reply on HN