Java JDK 9 Sees Its First Release Candidate

[ciplogic]

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.

I am wondering if are a troll or an idiot. Sorry, this is not a personal attack, it is how you describe yourself.

Let me explain some mistakes you miss:
- C++ (and "native" languages) tend to be better in latency (so to answer in a number of milliseconds) than on throughput. I found very often implementing throughput algorithms in Java, do run faster (especially if there are GC-free algorithms) than C++.
- comparing a PC version to an Android version is very silly. For example on the next link you see that a typical PC runs (using kind of unreliable, where iPhone was optimized a lot for) runs circles around iPhone 7 (for instance). Most Android phones are not 100% matching iPhone 7.

https://browser.geekbench.com/v4/cpu...aseline=387526

- let's say Java would run slower than C++, so what? There are cases when it runs better. Will you throw C++ out of the window, maybe KDE or XFCE (yeah, you know, it has many things written in C++) because Java runs it faster? One good example: Java 9 as we discuss will beat most string related coding like string concatenation doing with almost GC-free algorithms. I am ready any day to compare a STL based coding to a Java 9 based coding into processing a lot of text...

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.

Last but not least: let's say Android has problems, what it has to do with their (Google's) Java compatible implementation? Out of curiosity, do you have any phone for your child which is from a major vendor which runs Debian XFCE?

[ciplogic]

Java is like a virus and for idiots that do memory leaks etc. When it came in 90s, it took markets from C++ and we had slowly working software. Today we have android with its java implementation and do have poor games although mobile phone hardware is very powerful. Android is a big mistake, Debian testing Xfce does have better software architecture with its debian packaging and rolling release nature. With Android you need to flash a new firmware or buy a new phone to get newer os.

I think you live in 90s.

Take two projects that do the same stuff: take Visual Studio, add Resharper (a standard tool in .Net's world) and compare it with Rider, the IDE from JetBrains whic is written with Java and embeds Resharper. Write to me after you test which starts and runs faster...

To me there is no comparison, Java runs better on the JetBrain's IDEs than C++ on Microsoft's IDEs.

Also, the more you run real software, I tend to see that if I ignore the startup cost (yes, I know it exists) and memory (yes, memory matteers, but not that much), Java applications tend to run faster than C++. By a big margin in fact, in my experience it is more than 10% for high volume computations, somewhere in between GCC O2 and GCC O3.

[caligula]

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

FWIW, some languages don't provide tuples at all. I'd claim this is more of a problem with program/framework design and/or DB data models. Relational data isn't the only way to go. Limiting the size of builtin tuples isn't some Scala related unique limitation. Many previous functional languages did the same thing. There's really nothing wrong with nested data if you have 100 fields in a record.

[caligula]

if I ignore the startup cost (yes, I know it exists) and memory (yes, memory matteers, but not that much), Java applications tend to run faster than C++. By a big margin in fact, in my experience it is more than 10% for high volume computations, somewhere in between GCC O2 and GCC O3.

One main point of new Java 9 is the modularization of the std lib. The JVM runtime spends significant time loading the standard classes every time. You can already achieve faster startup by using Avian or slicing the jars with proguard. I guess the Java experts here already knew all this.

[Hi-Angel]

In other words: "well-written code is easy to understand".

I've seen way too many Java programs written like shit or using frameworks where the method names meant little to anyone that wasn't the framework developer. I can assure you that forcing people to be wordy is not a sure way to get decent code.

https://stackoverflow.com/questions/...erfactoryproxy

[ciplogic]

One main point of new Java 9 is the modularization of the std lib. The JVM runtime spends significant time loading the standard classes every time. You can already achieve faster startup by using Avian or slicing the jars with proguard. I guess the Java experts here already knew all this.

Java 9 has a linker which improves startup times. JLink.
http://mail.openjdk.java.net/piperma...er/004806.html

But my comment it is that Java is understood that it starts slow but it generates at the end quick code by most measures.

An unbiased benchmark shows how Java is basically in the same league (maybe at worst with a 2X slowdown) as C/C++. In my experience, Java beats C++ in my most real kind of software. I know how to saturate an SSD using Java (like processing hundreds of megabytes per second) and it is very hard to beat it with C++. It could be possible, of course, but I found it very seldom to run C++ much quicker.

http://www.stefankrause.net/wp/?p=9#more-9

[caligula]

Java 9 has a linker which improves startup times. JLink.
http://mail.openjdk.java.net/piperma...er/004806.html

But my comment it is that Java is understood that it starts slow but it generates at the end quick code by most measures.

An unbiased benchmark shows how Java is basically in the same league (maybe at worst with a 2X slowdown) as C/C++. In my experience, Java beats C++ in my most real kind of software. I know how to saturate an SSD using Java (like processing hundreds of megabytes per second) and it is very hard to beat it with C++. It could be possible, of course, but I found it very seldom to run C++ much quicker.
http://www.stefankrause.net/wp/?p=9#more-9

Sure, won't disagree with any of that. I had the impression that stdlib modularization is the main achievement in jdk9, but probably jlink is also needed. Avian and proguard basically do the same, a static linking step which also discards unused parts. Still, even with jlink & modularization, I think proguard can optimize things further. The previous results were quite impressive. One thing people also don't realize is that machines have improved quite a bit since the early Java days. A modern PC cold boots the OpenJDK jvm in 90 ms, all class loading included. If Java 9 can improve this further, the startup cost is similar to large C++ apps.

[bug77]

FWIW, some languages don't provide tuples at all. I'd claim this is more of a problem with program/framework design and/or DB data models. Relational data isn't the only way to go. Limiting the size of builtin tuples isn't some Scala related unique limitation. Many previous functional languages did the same thing. There's really nothing wrong with nested data if you have 100 fields in a record.

Maybe so, but a seemingly artificial limitation like this flies straight in the face of the elegance functional languages are capable of. And yes, I know Scala isn't a pure functional language.

[caligula]

Maybe so, but a seemingly artificial limitation like this flies straight in the face of the elegance functional languages are capable of. And yes, I know Scala isn't a pure functional language.

I beg to differ. Tuple is basically a lightweight record with no field names:

-- tuple coordinate pair (least verbose)
(1, 2)

-- algebraic data
data Coordinate = Coordinate Int Int
Coordinate 1 2

-- record (most verbose)
data Coordinate = Coordinate { x:: Int, y:: Int }

Now if you had something like a player character with a position given as a coordinate, you'd do

data Player = Player { position :: Coordinate, name :: String, ... }

not

(1, 2, "John")

It's really hard to keep track of things when you have 20+ anonymous packed values. It's just a thing you shouldn't do. I've seen functional programs that use really long and complex data types for mundane tasks. It's a sign of 'code smell'. You should always consider nested records or some other way.

There are similar examples of bad design choices for C or Java. Imagine a procedure in C with 100 000 lines of code. Makes no sense. Or procedures with 1 000 local variables. Or a class with 100 constructors. At some point the complexity needs to be split into smaller modular units.

[bug77]

I beg to differ. Tuple is basically a lightweight record with no field names:

-- tuple coordinate pair (least verbose)
(1, 2)

-- algebraic data
data Coordinate = Coordinate Int Int
Coordinate 1 2

-- record (most verbose)
data Coordinate = Coordinate { x:: Int, y:: Int }

Now if you had something like a player character with a position given as a coordinate, you'd do

data Player = Player { position :: Coordinate, name :: String, ... }

not

(1, 2, "John")

It's really hard to keep track of things when you have 20+ anonymous packed values. It's just a thing you shouldn't do. I've seen functional programs that use really long and complex data types for mundane tasks. It's a sign of 'code smell'. You should always consider nested records or some other way.

There are similar examples of bad design choices for C or Java. Imagine a procedure in C with 100 000 lines of code. Makes no sense. Or procedures with 1 000 local variables. Or a class with 100 constructors. At some point the complexity needs to be split into smaller modular units.

Ok, going overboard is a code smell in any language. But in Scala, you can do some nifty pattern matching using tuples if you, say, need to implement a FSM. Having to nest states just because of a language limitation is something I'd rather live without. Or maybe I'm just looking at all of this the wrong way?