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

[coder111]

There's another use case. Low-latency (mostly financial) applications. In most cases they are already written very carefully to use primitives where possible, not to allocate new objects, always use or reuse buffers or existing instances or use Unsafe or memory mapped files for direct memory management. For apps like that, GC mostly just gets in the way and is not really needed. Another problem apps like that deal with is JIT pauses. There's JVMs like Azul that can work around that.

Which sometimes makes me question why write them in Java in the first place, but I guess having Java still brings some advantages.

Thanks for the info ciplogic. This is an interesting idea. I can already think of a few use cases of this pseudo-GC

[cybertraveler]

There's another use case. Low-latency (mostly financial) applications. In most cases they are already written very carefully to use primitives where possible, not to allocate new objects, always use or reuse buffers or existing instances or use Unsafe or memory mapped files for direct memory management. For apps like that, GC mostly just gets in the way and is not really needed. Another problem apps like that deal with is JIT pauses. There's JVMs like Azul that can work around that.

Which sometimes makes me question why write them in Java in the first place, but I guess having Java still brings some advantages.

I actually wondered how financial apps could benefit from this (the link ciplogic gave mentioned them). Thanks

I'm surprised that interpreter pauses is a claimed problem of GCs. I would have thought this issue could be trivially solved by allowing devs to manually, pause, resume and trigger a GC run (at a desired age/depth/aggressiveness level). In the case of a game, you could pause the GC while the player is doing something interactive and then resume the GC momentarily when the player performs an action like open a menu, when a video cutscene plays or when a new scene is loaded. In each of these situations you could design the game in such a way as to not make the game appear to stutter or become unexpectedly unresponsive. You could even do something like this in open world games like pubg where there are no scene changes or video cutscenes. For this type of game you could run the GC only while a full-screen map is displayed. The map could be a static image. You could interrupt/pause/stop the GC only when the player zooms/scrolls the map or when they close the map. It would be harder to achieve, but you could probably also do this with an inventory management screen. There are some what-ifs involved (eg what if the player never opens the map!), but I'm pretty sure you could reduce these what-ifs to some unlikely-to-occur-often, corner-case scenarios with some creativity.

[Charlie68]

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

This is only partially true, for example Tumbleweed's rolling method seems to offer a good, reliable alternative, although there is still work to be done, but the road is the right one in my opinion.

[sireangelus]

the thing that annoys me is that even xubuntu 16.04 has still many many bugs on it, wouldn't this mean that this lts is going to be as buggy? it's incomparable to the stability and the bugfix that went into the 14.04... that was a truly stable lts...

[Slithery]

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

Really? I've been using Arch on tens of machines for 7+ years and never had a breakage due to the rolling-release model.

[ElectricPrism]

the thing that annoys me is that even xubuntu 16.04 has still many many bugs on it, wouldn't this mean that this lts is going to be as buggy? it's incomparable to the stability and the bugfix that went into the 14.04... that was a truly stable lts...

Idealistically the 6 month cycle should create more stable software.

Realistically however it simply doesnt. Canonical has to hit 6 moving targets instead of just 1 or 2.

If it was me I would abolish the 6 month cycle and just do Ubuntu LTS and Ubuntu Rolling.

Experiencing bugs which cannot be fixed due to the software being old is very frustrating.

Because this I use rolling release with filesystem snapshot every day on 15 machines.

I think Ubuntu sticks to the 6 month thing as a PR stunt, in actuality its not such a good idea.

[sebastianlacuesta]

@Michael: Isn't there a typo at COBRA->CORBA?

[Thpn]

Which sometimes makes me question why write them in Java in the first place, but I guess having Java still brings some advantages.

What open source applications in a GTK-based Ubuntu desktop flavor have Java as a dependency?

[Delgarde]

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

Yes, that was one of the reasons why Java 9 was delayed for so long... the new modularisation system meant that using internal APIs was now impossible rather than just inadvisable... but that meant finding solutions to the problems that were forcing developers to use internal APIs to get the job done.

In general, Java 9 does seem to have broken compatibility a bit more than usual. Historically, Java has been very good at keeping compatibility, such that libraries compiled years ago for 1.0 still run on 8... binary-compatibility has been almost perfect, and source-compatibility very nearly so (barring the introduction of a few new keywords). The whole module system means that Java 9 breaks things a little – it's still pretty good, but most non-trivial projects will have to do *some* work to upgrade. As such, I suspect the transition from 8 to 9 (and 9's successors) will be much slower than with previous releases... particularly in enterprise, where JavaEE specs are slow-moving.

[anarki2]

6 month release cycle sounds _great_ for something as crucial and mission-critical as Java, congrats for the decision-makers.