Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

javaworld.com

Post reply on HN
Print view View original

51–60 of 138 posts

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

#51

Post by nknight »

kamaal wrote: post #45
meepmorp wrote: post #29

Earlier quoted context omitted.

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.

It's never occurred to me to think of Oracle as being a company concerned with any of those things. It seems totally outside their character, everything they do screams "huge, established customers only".

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

#52

Post by yummyfajitas »

calpaterson wrote: post #42
yummyfajitas wrote: post #12

Earlier quoted context omitted.

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

I stand corrected. I guess Haskell before H98 was a very different language than it is today.

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

#53

Post by protomyth »

sek wrote: post #20
JunkDNA wrote: 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?

To be fair, if you were researching computer languages and rewrites, you would be looking at Python 3.0 and Perl 6.0. I believe both will be successful in time, but for business planing, it looks like a lot of problems and a slow evolution will work better. Oracle is pretty comfortable with the slow evolution route.

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

#56

Post by sek »

protomyth wrote: post #53
sek wrote: 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?

To be fair, if you were researching computer languages and rewrites, you would be looking at Python 3.0 and Perl 6.0. I believe both will be successful in time, but for business planing, it looks like a lot of problems and a slow evolution will work better. Oracle is pretty comfortable with the slow evolution route.

I think Python 3.0 is really well executed. With such a big ecosystem this takes a while, but when you wait too long somebody else eats your lunch.

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

#57

Post by floppydisk »

kamaal wrote: post #44
JunkDNA wrote: 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.

Apache and the Open Source community already have a Java implementation in the Open JDK.

One thing not touched on in the article but would definitely be worth know is if Oracle will start inserting "pay-to-use" features in the language or release a solid JIT compiler and run time companies must pay for in order to use. I know it's been bandied about in the past that Oracle might start restricting access to some language features and with such a long term roadmap, I'm wondering if they're thinking about making some of these selling point features into business revenue features.

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

#58

Post by kbd »

protomyth wrote: post #53
sek wrote: 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?

To be fair, if you were researching computer languages and rewrites, you would be looking at Python 3.0 and Perl 6.0. I believe both will be successful in time, but for business planing, it looks like a lot of problems and a slow evolution will work better. Oracle is pretty comfortable with the slow evolution route.

There's no way I'd put Python 3 and Perl 6 in the same sentence.

Also, IMO there's no chance of Perl 6 being successful in time (which makes me sad, because 10 years ago or so I was really hopeful about it).

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

#59

Post by yummyfajitas »

ramblerman wrote: post #35
EdiX wrote: 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.

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

Why not? Very often, a class will have some data members which are pretty much meaningless elsewhere. Why should the class used to represent that data be exposed elsewhere?

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

#60

Post by riffraff »

eternalban wrote: post #18
rukkyg wrote: post #13

Earlier quoted context omitted.

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.

would you care to explain why this is not enough? You can pass them around, invoke them, get their properties.

The interface may be bad but I'm not sure what is missing.

Post reply on HN