Live data from Hacker News

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

javaworld.com

91–100 of 138 posts

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

#91
post #41

Earlier quoted context omitted.

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.

Probably in Totem and Taboo? This concept is expressed in a number of his books, however.

Oh if you could find it I would be super grateful. I've done my usual rounds such as searching on Google Books and found nothing. Made me start to wonder if it had been Jung instead.

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

#92

Earlier quoted context omitted.

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.

Java objects have functionality beyond dispatch tables. Synchronization is one. You can also have x != y where x and y are different objects with the same value.

>You can also have x != y where x and y are different objects with the same value.

May be true, but it's not guaranteed one way or the other. In the Oracle JVM the smaller integers are cached such that

  new Integer(10) == new Integer(10)
but

  new Integer(1000) != new Integer(1000)

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

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

Java is already 30 years behind the state of the art, so planning 10 years ahead is very easy. Just do what other languages were doing 20 years ago. (Fuck boxed primitive types. How about generics that weren't designed by drunk retarded monkeys?)

Yep, Gilad Bracha, Philip Wadler, Martin Odersky... all drunken, retarded monkeys.

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

#94
post #47

Earlier quoted context omitted.

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…

> stuff like Hadoop for big data or Groovy for DSLs were built upon the existing JVM

Hadoop become popular for handling big data, but I'm not sure if many are using Groovy for DSL's. The 2 big uses for Groovy in industry seem to be (1) scripting on Grails, and (2) quick standalone scripts for testing or booting Java code. For these it rocks but the stuff added after Groovy 1.0, such as DSL's, isn't really being used much.

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

#95
I just want passable functions, or even better, first class functions in module namespace.

I still find it hilarious how even Swing shows how crippled the language is without that feature, where adding event listeners is complicated like new EventListener(Event e) { @override onEvent... etc. When just overriding some declared event handler method would be so much clearer.

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

#96
post #45

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.

I don't get the impression that Oracle really cares about startups. It costs a shitload to license Oracle, and the companies that fork out that kind of money do so because they're running SAP or Siebel, PeopleSoft, data warehousing, legacy LOB apps, etc.

There's lots of old, conservative, slowly changing companies out there that have craploads of money and need (for certain meanings of the term) Oracle. Having control over Java gives them a lot more leverage in those markets, too.

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

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

The only word that's wrong in that language is "new". Java's been COBOL for as long as it's been around.

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

#98
post #92

Earlier quoted context omitted.

Java objects have functionality beyond dispatch tables. Synchronization is one. You can also have x != y where x and y are different objects with the same value.

>You can also have x != y where x and y are different objects with the same value. May be true, but it's not guaranteed one way or the other. In the Oracle JVM the smaller integers are cached such that new Integer(10) == new Integer(10) but new Integer(1000) != new Integer(1000)

Actually, "new Integer()" is guaranteed to always return a new, distinct object. The caching only comes into play during autoboxing conversions, or when you call Integer.valueOf().

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

#99

Earlier quoted context omitted.

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.

Java objects have functionality beyond dispatch tables. Synchronization is one. You can also have x != y where x and y are different objects with the same value.

The only issue that comes up is synchronization, because it requires maintaining identity, localized escape analysis alleviates a lot of the burden here, but the fact remains that anytime you escape an Integer you'll need to allocate it, because you might want to synchronize on it, without the synchronization issue you can come up with schemes to avoid allocating even if the object does escape. Every other issue can be handled by a compiler optimization (either AOT, or JIT).

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

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

For years, some in the Java community (and programming community in general) have been claiming that Java is the new COBOL, so this is a refutation of that assertion. They are not fools, they just expect their audience is aware of the context.
Post reply on HN