Live data from Hacker News

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

javaworld.com

41–50 of 138 posts

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

#41
post #25

The presentation declares, "Java is not the new Cobol." It shocks me that a major company like Oracle would be so foolish as to make a statement like this. Stating that something is not is one of the most effective ways to imply that it is and the speaker knows it.

Freud somewhere talks about a primitive tribe where the punishment for saying "The king is not an ass" is the same as for saying "The king is an ass".

Edit: I remember reading this years ago and have been unable to track it down. Would love it if somebody did.

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

#42
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 don't think typeclasses were in from day one, they were added quite late in the development of the language (but some years before H98). I don't think they're in Miranda, for example.

Here's a paper introducing them.

http://dl.acm.org/citation.cfm?id=227700

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

#43
Video and slides of the same presentation by the same presenter in October 2011: http://lanyrd.com/2011/jax-london-autumn/sgzyx/

It's mind-blowing that they plan on having GPU and FPGA support before they offer arrays of structs and multidimensional arrays. Frustrating, too. I guess I can't complain, since clearly somebody is paying for all this, and it isn't me.

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

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

Not when you consider Java as a 'business' for Oracle.

And business planning is always done like this.

If Java no longer remains useful to Oracle expect the same thing what happened to things like flash.

It will be donated to Apache software foundation.

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

#45
post #25

The presentation declares, "Java is not the new Cobol." It shocks me that a major company like Oracle would be so foolish as to make a statement like this. Stating that something is not is one of the most effective ways to imply that it is and the speaker knows it.

It somewhat surprises me that they'd not want Java to become the new COBOL. COBOL is still alive, still runs large systems, and still sells hardware and software. Owning the new COBOL has the potential to be quite lucrative in the long term.

I don't think so, Although I agree with you that COBOL is still alive and kicking. That is totally different that being used for awesome projects and by start ups.

If Oracle's plan is to keep Java alive as a glue for their DB that strategy would work fine.

But it would be a long term disaster in terms of overall innovation, and long term viability for choosing everyday projects.

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

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

I didn't say they should rewrite everything, but to make a new Java version with backward incompatibilities. Drop a new 1.x version on java for decades can't be the solution.

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

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

It pretty much depends on industry. Look at mobile, 2007: J2ME, Symbian, Windows Mobile, BlackBerry -> 2012: iOS, Android, Windows Phone. Now look at the web: it was more of a evolution than revolution.

What happened at back-end, like server-side functionality of business apps? They didn't really change and probably won't change for a longer period of time. Even stuff like Hadoop for big data or Groovy for DSLs were built upon the existing JVM.

It's hard to say what devices we'll have in 5 years, or what internet would look like, but i'm pretty sure servers would run good old Java.

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

#48
post #25

The presentation declares, "Java is not the new Cobol." It shocks me that a major company like Oracle would be so foolish as to make a statement like this. Stating that something is not is one of the most effective ways to imply that it is and the speaker knows it.

It somewhat surprises me that they'd not want Java to become the new COBOL. COBOL is still alive, still runs large systems, and still sells hardware and software. Owning the new COBOL has the potential to be quite lucrative in the long term.

[deleted]

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

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

Not sure I agree with the GP's point, but I believe he's arguing that when fulfilling the contract of a fictional MouseClickListener: interface MouseClickListener { void mouseClicked(MouseEvent e); } one often uses an anonymous class to do so: void init() { mouse.setClickListener(new MouseClickListener() { void mouseClicked(MouseEvent e) { println(e); } }); } the exact effect could be achieved with a reference to a n…

First class functions pretty much have no bearing on whether or not interfaces are useful. Sure, one use case for inner classes is to implement interfaces in-place in situations where what you really want to do is just pass a function, and in those cases it's probably better to use a function instead, but the equivalence doesn't go the other way.

There are plenty of cases where you really need to pass an object to a function and know that the object supports multiple operations, for instance take a look at Map: http://docs.oracle.com/javase/6/docs/api/java/util/Map.html

There are 14 methods there, and when I write code that takes a Map object, I really mean it - I'm not just using the interface as a hack because I want a function pointer, I need an object that supports all of those methods, and I'm probably going to be using several of them.

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

#50
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…

>In C# primitives are not objects

http://msdn.microsoft.com/en-us/library/system.valuetype(v=V...

>Data types are separated into value types and reference types. Value types are either stack-allocated or allocated inline in a structure. Reference types are heap-allocated. Both reference and value types are derived from the ultimate base class Object.

Post reply on HN