Live data from Hacker News

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

javaworld.com

11–20 of 138 posts

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

#11
I'm curious how they're going to handle the GPU thing since there really isn't a unified GPU architecture, yet (by 2015, who knows but still). Have vendor specific translations or try to rally around something like OpenCL? I'd love it if GPU coding would become more available and vendor agnostic, so I'm really curious about this.

I know the article didn't mention it, I also wonder what the memory bloat will look like when they turn all primitives into Objects and introduce object overhead just to track int i in a for loop.

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

#12
post #9
post #5

Earlier quoted context omitted.

This is a very good point. If functions become objects, interfaces would become literally useless. Somehow it seems that it would not be the case since this would be a drastic change (even thought getting rid of primitives are as well.)

Literally useless? Would you like to elaborate on how specifying a contract that has to be implemented is suddenly useless because you have function types?

I think the experience of Haskell is relevant here. Once Haskell introduced first class functions, everyone stopped using typeclasses.

[edit: apparently my sarcasm was too subtle. HOF and typeclasses are both vitally important pieces of Haskell, which are orthogonal to each other. I'm pretty sure both were in Haskell from day 1. Some code for which both are essential:

    class Monad m where
      (>>=) :: m a -> (a -> m b) -> m b
      (>>) :: m a -> m b -> m b
      return :: a -> m a
      fail :: String -> m a

]

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

#13
post #8

All-OOP? So functions will be objects too? And classes? And contexts? Not meaning to start a flame, just saying the title's a bit inaccurate IMHO...

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).

Aren't methods already an object of class java.lang.reflect.Method? Do you mean you should be able to do something like foo(PrintStream.println.method) like you can do foo(PrintStream.class)?

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

#14

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 implement on primitives is wait/notify/synchronization, but I don't actually know how those are done in the JVM either.

Even if these things turn out to be impossible to optimize at compile time, they're probably then betting on JIT functionality to detect primitive objects that are only used as primitives.

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

#15
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.

Maybe I'm too cynical, but I don't think you can seriously plan releases so far in future. What you can do is delude yourself (which happens all the time at big bureaucracies) or make it look like you're planning seriously in order to appear responsible and visionary.

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

#16
post #9

Earlier quoted context omitted.

Literally useless? Would you like to elaborate on how specifying a contract that has to be implemented is suddenly useless because you have function types?

I think the experience of Haskell is relevant here. Once Haskell introduced first class functions, everyone stopped using typeclasses. [edit: apparently my sarcasm was too subtle. HOF and typeclasses are both vitally important pieces of Haskell, which are orthogonal to each other. I'm pretty sure both were in Haskell from day 1. Some code for which both are essential: class Monad m where (>>=) :: m a -> (a -> m b) ->…

I'm genuinely curious: is this because Haskell is generally hard to learn[] or because of some inherent property of Haskell that makes type classes unnecessary when you have first class functions?

[] This statement is based purely on my own experience. I find the Haskell documentation a bit unfriendly with its "academic" style. The content is great, but the form makes it a bit hard to assimilate. Monads were especially painful.

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

#17
post #6

All-OOP? So functions will be objects too? And classes? And contexts? Not meaning to start a flame, just saying the title's a bit inaccurate IMHO...

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 that generics are baked deeply into the platform, so using primitive (actually, any value-type struct) types as generic arguments will not require object memory or casting overheads.

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

#18
post #13
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).

Aren't methods already an object of class java.lang.reflect.Method? Do you mean you should be able to do something like foo(PrintStream.println.method) like you can do foo(PrintStream.class)?

No, a class's methods are not instances of java.lang.reflect.Method. The latter is simply a 'reflection', per the package name, of first class JVM construct e.g. a reflection on a method.

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

#19
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.

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

#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?

Post reply on HN