Java JDK 9 Sees Its First Release Candidate

[Hadrian]

Also, how did you manage to bring your Debian+Xfce crap into a discussion about Java and Android?

Indeed. It seems to be the purpose of "Debianfxce": to bring crap into any discussion here on Phoronix.

He hasn't got any Java knowledge but a big mouth. When he's so unhappy with Java, why does he write in a Java dedicated thread (topic) in the first instance? There's no sense in this. It just destroys constructive posters' articles who try to help each other here.

[Ray54]

One big problem with Java applications is also that people tend to care very little about building bloaty abstractions on abstractions. It's really easy to lose yourself in the sea of abstractions where there are classes and patterns for everything. Java fails pretty hard in simple things. The primitive types are limited and expressing even simple things like a group of values (tuple) is impossible without introducing a new class for each use case. TBH, it's hard to design it right. Even Scala got many things wrong. The Scala 2.0 seems quite promising. Even with all the flaws, it will be better than Java or C#.

Thank you Caligula for reminding me about Scala, and I did not know there was a Scala 2.0 version. My younger son said some time ago that he had bought a Scala book and was experimenting with the language, so I will try and quiz him on Scala. I agree with your tuple issue, although I thought a built-in tuple was on the Java road-map for a later release. There is a lot of bad Java code around, I have heard of 10K line class produced by poor subcontractors for a large corporation, and I have never liked automatically generated code in any language, but with any very popular language these things always happen.

[ssokolow]

Yay. I still rely on a few crappy Java applications so HiDPI support will be very nice

Let me guess. JDownloader and/or FreeMind are on that list?

That's my list... though I actively avoid HiDPI hardware because, If I have to pay to drive more pixels, I want to be able to fit more applications. (If I do go 4K, I'll probably save up for a 54" display so I can keep the DPI roughly the same. I'm already using a row of three 1280x1024 monitors, so having a ridiculously large desktop wouldn't be a new thing.)

[bug77]

Thank you Caligula for reminding me about Scala, and I did not know there was a Scala 2.0 version. My younger son said some time ago that he had bought a Scala book and was experimenting with the language, so I will try and quiz him on Scala. I agree with your tuple issue, although I thought a built-in tuple was on the Java road-map for a later release. There is a lot of bad Java code around, I have heard of 10K line class produced by poor subcontractors for a large corporation, and I have never liked automatically generated code in any language, but with any very popular language these things always happen.

Scala 2.0 is only about 11 years old.
And as much as I like the language (I really do), tuples are one of its quirks. Just look at this: https://github.com/scala/scala/tree/.../library/scala
Tuple1.scala ... Tuple22.scala. Good luck if you need to lump together more than that.
I know there's probably a good explanation for that, but it still sticks out like a sore thumb.

[alvez]

Stay factual! I don't think that we Java developers actually are idiots doing memory leaks :-)



I have to admit that Java was slower in its early stages of development, but it really has come to age now! Hardware got better, there is the Just-in-time compiler (JIT) and other optimizations like Java HotSpot etc. Only when it comes to solely calculations, C++ can be up to 20% faster (that's why you don't make a raytracer in Java)
So nowadays, when C++ developers are still fiddling around with pointers, you can already show a first prototype in Java (kind of) ;-)


Cheers

Don't feed our pet troll. Probably not even a real person. Far too dumb for that.

[caligula]

Scala 2.0 is only about 11 years old.

I meant the Dotty language.

And as much as I like the language (I really do), tuples are one of its quirks. Just look at this: https://github.com/scala/scala/tree/.../library/scala
Tuple1.scala ... Tuple22.scala. Good luck if you need to lump together more than that.
I know there's probably a good explanation for that, but it still sticks out like a sore thumb.

When was the last time you needed more than 22 members in a tuple?

[bug77]

I meant the Dotty language.


When was the last time you needed more than 22 members in a tuple?

Never, because I haven't been involved in Scala projects as much as I would have liked. But it has bitten others: http://underscore.io/blog/posts/2016...wenty-two.html

[Michael_S]

Java is prone to bloaty abstractions because of the language core features. Take dependency injection - a very useful feature for making flexible code. You don't need Spring Dependency Injection or Google Guice Dependency Injection, you can do it all manually in your Java code. You just make your objects hold instances of the configurable behavior, and then set them up with getters and setters (yucky) or with constructor input parameters (better). But you end up writing a huge amount of code. Manual dependency injection in Python, Perl, Scala, and dozens of other languages involves far less code.

Or take the way Hibernate does - or at least used to do - runtime bytecode modification. That's a workaround for the lack of multiple inheritance or similar.

etc... etc.... It's not a bad language. I make my living working on it. But the verbosity and leaky abstractions are hard to escape. I'd much rather use Scala, Kotlin, Ceylon, or Clojure at work. Even Groovy. But I can't convince the rest of the team to switch, and I like everything else about the job too much to quit.

[bug77]

Java is prone to bloaty abstractions because of the language core features. Take dependency injection - a very useful feature for making flexible code. You don't need Spring Dependency Injection or Google Guice Dependency Injection, you can do it all manually in your Java code. You just make your objects hold instances of the configurable behavior, and then set them up with getters and setters (yucky) or with constructor input parameters (better). But you end up writing a huge amount of code. Manual dependency injection in Python, Perl, Scala, and dozens of other languages involves far less code.

Or take the way Hibernate does - or at least used to do - runtime bytecode modification. That's a workaround for the lack of multiple inheritance or similar.

etc... etc.... It's not a bad language. I make my living working on it. But the verbosity and leaky abstractions are hard to escape. I'd much rather use Scala, Kotlin, Ceylon, or Clojure at work. Even Groovy. But I can't convince the rest of the team to switch, and I like everything else about the job too much to quit.

Clojure no. It's not my cup of tea. But Go isn't too shabby as I've recently bothered to find out.

Also, lack of multiple inheritance was never a problem, because inheritance in Java is done by encapsulating the super class anyway. You can always encapsulate as many as you want. But since Java8 and its default implementations in interfaces, you effectively get multiple inheritance.

As far as work is concerned, I'm too a Java drone on a project that screams for functional/Scala. But since nobody on the team knows Scala, they're not willing to consider switching. Unlike you, the project isn't even that interesting. In fact, I think I've never delivered such low-quality code in my entire career. But I've also never been paid better.

[bug77]

There are many Android java games, just google: android java games. Also C++ is used, but android user level is implemented with java, so it could be faster if everything is written with c++, Sure you hope that that touch screen would react faster in action games and wish that games do have same graphics quality and story that pc games do have. Compare Final Fantasy pc and android versions to get the idea.

Facepalm.

It would much wiser to use Debian testing Xfce instead of Android where java plays a big role. You can update Debian testing every day, android phone can be non functional because of incompatible os, like my kid has problems with android 5.1 and google services. My kid needs to buy a new phone, because of android. With Debian testing you can use same hardware forever.

You tried bringing that up with Google? You might help them save a ton of money.