After all these years, Java 8 is finally available. Just make sure you don't get tripped up by the change in the classfile format!
After all these years, Java 8 is finally available. Of course, I have used it for about a year, while writing my book Java SE 8 for the Really Impatient. But I switched JAVA_HOME and the PATH whenever I worked on the book. Now I downloaded the official release and changed JAVA_HOME and the PATH one last time. Eclipse came up fine, and my Scala-based tools for e-book production worked without a hitch, and I forgot all about it. That's the nice thing about backwards compatibility.
These days, the blogosphere is awash in blogs that sing the praises of Java 8. I don't think I add any value by writing my own. It's a major release—the biggest change in the Java language since Java 1.0 and the biggest change in the Java API since Java 1.2 (Or was that Java 2? Or Java 2 version 1.2?) Here is a great list of links. Or, if you'd rather learn from a book than a list of links, you know what to do...
As my wife knows, if there is one person who can wring a drop of unhappiness from even the happiest event, that's me. So, this morning, I made a small fix to my side-project, the code-check autograder. It worked locally, and I ran the script to upload the WAR. Being a conscientious (and slightly pessimistic) person, I pointed my browser to the server, and whoa:
Ugh, not again! Time to check out the logs. Now if there is one thing that I really hate in life it is the Stack Trace from Hell. Why can't GlassFish be like Play or Rails, and give the file name and line number of the offending artifact?
But there is something worse than the Stack Trace from Hell. That would be Nothing At All. And that's what I got. Instead of noisily squawking about what ails its innards, it had turned into the strong and silent type:
[2014-03-20T15:08:41.869+0000] [glassfish 4.0] [WARNING] [NCLS-DEPLOYMENT-00041] [javax.enterprise.system.tools.deployment.autodeploy] [tid: _ThreadID=69 _ThreadName=AutoDeployer] [timeMillis: 1395328121869] [levelValue: 900] [[Attempt to create file /opt/domains/domain1/autodeploy/.autodeploystatus/codecheck.war failed; no further information.]]
For an hour I tried This And That, to no avail. The app ran on my machine and not on the server. “The requested resource is not available”
Finally, instead of using autodeploy, I logged into the server and deployed manually:
$ asadmin deploy codecheck.war
remote failure: Error occurred during deployment: Exception while loading the app :
java.lang.IllegalStateException: ContainerBase.addChild: start:
org.apache.catalina.LifecycleException: java.lang.IllegalArgumentException:
java.lang.UnsupportedClassVersionError: Class Initializer has unsupported major or minor version
numbers, which are greater than those found in the Java Runtime Environment version 1.7.0_40.
Please see server.log for more details.
Command deploy failed.
Oh good grief! Of course. I had compiled the WAR for Java 8. Now why could that information not be prominently displayed in the web page? Or at least in the logs? Dear reader, if you work on developing tools for developers, please put every irregularity in their face. You'd think that nobody would be stupid enough to make errors such as compiling the WAR with the wrong version of Java, but you'd be wrong.
I don't know how many hundreds of hours I have wasted with fiddly configuration stuff like this. To me, it's by far the worst part of Java EE . I would pay real money for an EE app server that serves developers and mercilessly traces every failure to a file name and line number in one of the app's artifacts. Like Play does: “No route found. In /app/views/Application/index.html (around line 4)”.
