Love and hate for Java 8

Java 8 brings exciting developments, but as with any new technology, you can count on the good, the bad, and the headaches

1 2 3 4 5 Page 4
Page 4 of 5

Netscape created a piece of software called LiveScript to allow for scripting on its Web servers. It decided to port it to its browser and needed a fancier name, so it licensed the Java trademark from Sun and called it JavaScript -- which would long promote the confusion that JavaScript had very much to do with Java. However, after the apAOLcalypse, some members of the 12 colonies of Netscape were not done and sought to continue Netscape's plan of rewriting their browser in Java. In order to do so, it needed to create an implementation of JavaScript in Java. Netscape called the project Rhino; as with turducken, ours is not to question but to enjoy.

All joking aside, modern JavaScript isn't your father's JavaScript (yes, you theoretically could've learned JavaScript as a first language, then have an 18-year-old who's learning the newer dialects of it). It can be useful on both the server and the client, and you can write applications in it that are neither slow nor unreadable.

JDK 7 added support for dynamic languages to not suck on the JVM and called it invokeDynamic. JDK 8 will give us a more useful JavaScript implementation and possibly make Nodyn (Red Hat's port of Node.js to the JVM) -- which I call turduckaturducken -- not a kooky engineering boondoggle. In fact, the masters of open source and collaboration that they are, Oracle has its own Node.js implementation creatively called Node.jar. This seems to have caught more people's imagination than JavaScript from Java. If you believe the buzz, what most people are sure about is that they want to run stuff on the JVM, but they don't want that stuff to be written in the crickety ol' Java syntax.

While there are many places that it can be useful to run JavaScript from within Java (for instance, it is one way of using the same client-side validator as server-side validator), having your Node.js and Java too is like having your turducken cake and eating it too. Who wouldn't want that tasty beast? If in reading this you are unsure whether I'm being serious or sarcastic, that makes two of us.

I generally am not a fanboy and would rather make fanboys (particularly of the Apple ilk) cry. However, there are a few exceptions. One day I want to have Doug Lea sign my chest with a black Sharpie and, like a true fan, not shower for at least a week. I'm just saying that man can code. Doug Lea is the architect of modern concurrency in Java. Since java.util.concurrent was integrated, time has not stood still. JDK 8 will build on the fork/join framework added to JDK 7 and go further with adders and accumulators.

First there was synchronized. However, if all you need to do is increment a count across many threads, then synchronized is a bit heavy. It became less heavy in Java 6 by making uncontended locks cheaper. Mostly that helped old applications that still used Vector, and that almost single-threaded pile of crap that has infected every library known as the Java Activation Framework.

Package java.util.concurrent made everything better for thread pools and other relatively complex multithreaded constructs, but if all you want to do is increment a variable across threads, it was overkill and then some. For this we were given atomics, far faster and lighter than real locks. However, Doug Lea and his minion army of grad student slave labor are not done yet. In JDK 8 we will be given accumulators and adders. These are lighter weight than atomics with lower guarantee, though they're generally good enough for what most concurrent code needs for having a few threads that must increment a count. Expect to see it for things like map/reduce implementations or anywhere you need to sum a value across threads. You'll still need atomics if you have to read that value across those threads as the order of accumulation isn't guaranteed.

1 2 3 4 5 Page 4
Page 4 of 5
How to choose a low-code development platform