Java 12

I&#x27;m so glad I was taught Java at Macquarie University back in 1998. For the past 20 years I&#x27;ve had a career built on a solid API that doesn&#x27;t change every 2 years like some flavour-of-the-month Javascript framework.<p>Even on the client where Java has lost to Javascript, I&#x27;m finding it more enjoyable to add features to my 15-year-old SWT app [0] rather than dealing with the multiple layers of abstractions that is Javascript+CSS+DOM (+ maybe Electron). Personally I think it&#x27;s a shame Sun dropped the ball with client Java - if they had chosen SWT over Swing and provided a minimal JVM then maybe Java Web Start would have beaten Javascript web apps. It&#x27;s also a shame Sun sold Java to Oracle - Google would have been a better steward, and probably would have been willing to pay more for the Java parts of Sun.<p>I&#x27;m now trying Dart to develop a few Flutter apps. It&#x27;s no doubt a better language, but not <i>that much</i> better - I think Flutter would have been more successful if it was built on Java.<p>[0] <a href="https:&#x2F;&#x2F;www.solaraccounts.co.uk" rel="nofollow">https:&#x2F;&#x2F;www.solaraccounts.co.uk</a>

The most interesting new feature I think is the Shenandoah GC. The summary from [1]:<p>&quot;Add a new garbage collection (GC) algorithm named Shenandoah which reduces GC pause times by doing evacuation work concurrently with the running Java threads. Pause times with Shenandoah are independent of heap size, meaning you will have the same consistent pause times whether your heap is 200 MB or 200 GB.&quot;<p>The original algorithm was published in 2016 [2]. It consists of 4 phases: initial marking, concurrent marking, final marking, and concurrent compaction.<p>[1] <a href="http:&#x2F;&#x2F;openjdk.java.net&#x2F;jeps&#x2F;189" rel="nofollow">http:&#x2F;&#x2F;openjdk.java.net&#x2F;jeps&#x2F;189</a><p>[2] <a href="https:&#x2F;&#x2F;dl.acm.org&#x2F;citation.cfm?id=2972210" rel="nofollow">https:&#x2F;&#x2F;dl.acm.org&#x2F;citation.cfm?id=2972210</a>

Switch expressions prepare the way for pattern matching (<a href="https:&#x2F;&#x2F;openjdk.java.net&#x2F;jeps&#x2F;305" rel="nofollow">https:&#x2F;&#x2F;openjdk.java.net&#x2F;jeps&#x2F;305</a>), instead of `instanceof` checks and casts.<p>But (in my naive opinion) double dispatch seems a more elegant and java-ry solution, i.e. polymorphism on argument classes, so different methods are invoked for different object <i>runtime</i> classes (instead of using the <i>compiletime</i> type of the variable).<p>The switching could be optimised, as ordinary polymorphism is in the JVM.<p>Sure, you&#x27;d wreck legacy code if you just introduced it, but there&#x27;s surely a backcompatible way to do it that isn&#x27;t too awkward.<p>BONUS: goodbye visitor pattern!

Anybody know how the graal project ties in with all of this? Is oracle effectively developing 3 different JVMs (OpenJDK, Oracle JDK, GraalVM)? Or is there some sort of convergence plan?<p>From what I understand, graal has made a lot of headway with language interop, as well as a handful of specific memory optimizations and native compilation, but overall is lagging in pure throughput&#x2F;latency performance behind hotspot. It would be really cool if we could get the best of both worlds.

Included is JEP 230, a Microbenchmark Suite. It&#x27;s based off of JMH. Nice to see this included!<p><a href="http:&#x2F;&#x2F;openjdk.java.net&#x2F;jeps&#x2F;230" rel="nofollow">http:&#x2F;&#x2F;openjdk.java.net&#x2F;jeps&#x2F;230</a><p><a href="http:&#x2F;&#x2F;openjdk.java.net&#x2F;projects&#x2F;jdk&#x2F;12&#x2F;" rel="nofollow">http:&#x2F;&#x2F;openjdk.java.net&#x2F;projects&#x2F;jdk&#x2F;12&#x2F;</a>

Are they <i>ever</i> going to release value types?

Still nothing to handle checked exceptions in streams properly... sigh.

The new switch feature looks nice, the way it previously used to work was so unwieldy.

Meanwhile, most enterprise apps still seem to only work with JRE 8. And those which I know of have elected to replace Java rather than upgrade.

Great to see Java 12 (and the shorter release cycles) but how quickly do people actually move to newer Java? Here&#x27;s a poll with some results: <a href="https:&#x2F;&#x2F;twitter.com&#x2F;otisg&#x2F;status&#x2F;1108093046397247488" rel="nofollow">https:&#x2F;&#x2F;twitter.com&#x2F;otisg&#x2F;status&#x2F;1108093046397247488</a> (still open, please vote so there is more data)

I wonder if they might condescend to utilize the JVM so I don&#x27;t have to compile JMC myself for another 5 months, or maybe at least they&#x27;ll remove their circular links that infuriatingly obscure the fact JMC binaries don&#x27;t currently exist. For the past 5 months.

I wonder if they&#x27;ll fix the performance again. I&#x27;m mostly peripheral to clojure-land and 8 still seems to be the best choice.

presumably there&#x27;s still primitives and boxing ?

I wish they did not decouple JavaFX...

I’m missing the TL;DR on what language features may be introduced. Any ideas?

I understand why Java has to keep on chugging along, but I feel bad for the people that have to be a part of it. It&#x27;s like watching people keep coal trains going while people are moving to cars.<p>Why? Besides being owned by Oracle, which is enough of a reason to never use Java ever again, it&#x27;s also lost the niches that brought it into existence. Java no longer runs everywhere. Java on the web is dead, and you can now write ubiquitous apps in basically every language. There&#x27;s no reason to deal with the JVM and it&#x27;s domain knowledge when you can write a nimble Go app for your backend and a Javascript app that will run on mobile, web, or desktop. A VM language? You mean v8 sandboxing and web workers; WASM which lets me write C, C++, and Rust all of which can talk to Javascript APIs. All of my services are stateless and ephemeral. Crashing is expected, and I can use host monitoring tools instead of introspecting the JDK. On the cloud it gets even worse for Java. Why use a meaty framework like Spring when I want to just spin up a bunch of micro services, or have an API gateway kickoff a bunch of lambda jobs.<p>Java also took OO in so many terrible directions. OO defined by it&#x27;s creator looks nothing like the enterprise OO that big business sold to commoditize programming, which now only exists as a ball and chain on legacy systems.<p>One day Java will be like Cobol. There&#x27;s probably a lot of money for Java developers for many more decades, but god I do not envy anyone that has to do it.