Ubuntu 18.04 LTS Might Ship With OpenJDK 10, Transition To OpenJDK 11

[phoronix]

Phoronix: Ubuntu 18.04 LTS Might Ship With OpenJDK 10, Transition To OpenJDK 11

Canonical's Tiago Daitx has laid out a proposal today for having an OpenJDK stable release update exception for the upcoming Ubuntu 18.04 LTS "Bionic Beaver" to reduce their long-term maintenance burden...

http://www.phoronix.com/scan.php?page=news_item&px=Ubuntu-18.04-LTS-OpenJDK-Plans

[caligula]

I heard that jdk9 has some compatibility problems with software that favors using internal APIs instead of clean module interfaces.

[nanonyme]

I heard that jdk9 has some compatibility problems with software that favors using internal APIs instead of clean module interfaces.

Isn't this largely a good thing?

[varikonniemi]

It is amazing how many problems stem from this outdated idea of releases, instead of just shipping upstream after proper testing period.

[FireBurn]

Aren't OpenJDK going to use the new Java naming standard of 18.3, 18.9 etc?

[ciplogic]

There is a mistake: Epsilon is not a

""Epsilon" as a new low-overhead garbage collector"

It is a "no-GC" concept where there is no garbage collection at all, just memory allocation.

The purpose for it is simply to isolate cases when the Java program does not allocate (or it allocates a rate of very few MB/minutes) like in some financial fields or to isolate performance problems which are caused by GC.

As for "low-overhead GC", all GCs are typically low overhead, much lower overhead than "malloc" & friends.

http://openjdk.java.net/jeps/318

[Jumbotron]

I think this is the right move. I've tried both OpenJDK 9 and actual Oracle Java 9 on both my desktop and laptop running Ubuntu 17.10 and found it acting weirdly and causing weird hangs and faults on programs and websites that require Java. Went back to OpenJDK 8 and it's goodness and light again.

However....SUPER excited about the direction of Java in general and am looking forward to OpenJDK 10 and especially 11. As per Oracle's plans, Java official and OpenJDK will merge and the feature set will be identical. Add to this the increasing use of Kotlin as a JVM compatible language and I see good things ahead for Java.

[cj.wijtmans]

As for "low-overhead GC", all GCs are typically low overhead, much lower overhead than "malloc" & friends.

http://openjdk.java.net/jeps/318

Good joke. Maybe you just dont know how to program efficiently?

[cybertraveler]

Thanks for the info ciplogic. This is an interesting idea. I can already think of a few use cases of this pseudo-GC, 1 being: imagine a small application that is started to quickly perform a single task and only remains active for a short period of time. If the application is time sensitive and you have enough free memory, you could enable this GC mode and save time due to not having the GC run.

Another idea: any program that builds up data over time but never discards it from memory, could also benefit from this. The program would further benefit if the tasks can be run concurrently because this GC mode allows for lock-free, multi-threaded processing of the data being "managed" by this pseudo-GC.

This statement of yours caught me by surprise:

As for "low-overhead GC", all GCs are typically low overhead, much lower overhead than "malloc" & friends.

Are you saying that the overall CPU usage and memory consumption of a GC is likely to be lower than if a program used malloc (or similar)? If so, do you have any useful info on this topic you could link me to?

It is my current understanding that GCs are typically more memory and CPU hungry than malloc / manual-memory-management approaches. GCs have to perform periodic scans to check if objects can be freed. They also have a tendency to have bad effects on CPU cache which can reduce performance. I think that the reason for choosing GC instead of malloc is to save programmer time & reduce/remove a certain class of bugs (including memory leaks and dangling pointers). This is why I use GCs.

I did do some searching and couldn't find anything to suggest GCs are generally better on cpu & memory. I found this one set of slides where the author claims the opposite:
https://people.cs.umass.edu/~emery/p...gcvsmalloc.pdf
(see page 26 and 27)

[andre30correia]

It is amazing how many problems stem from this outdated idea of releases, instead of just shipping upstream after proper testing period.

proper testing sometimes need one year or two, it's way rolling releases never work like it should and breaks all the time, ex-arch linux user here