Glassfish server does not work with JDK 8

Question

I'm using jdk 8 with lambda in a web project with NetBeans, but when a deploy it to glassfish it shows me this error:

java.lang.RuntimeException: Uncompilable source code - Erroneous tree type: <any>

This is caused by lines of code that include lambda expression.

I tried changing the glassfish settings to work with jdk 8 but I have not gotten it to work.

Is there any way to make it work?

Answer 1

I have observed all kinds of strange behavior using GlassFish 4 combined with JDK 8. It seems to be the case that when using new syntax introduced in Java 1.8, the class which uses the new features will trigger an ArrayIndexOutOfBoundsException during startup that reads something like this:

   Exception while visiting
 martinandersson/com/malivechat/ejb/events/EventService.class of size
 7094

 java.lang.ArrayIndexOutOfBoundsException: 25966
   at org.objectweb.asm.ClassReader.readClass(ClassReader.java:2015)
   at org.objectweb.asm.ClassReader.accept(ClassReader.java:469)
   at org.objectweb.asm.ClassReader.accept(ClassReader.java:425)
   at org.glassfish.hk2.classmodel.reflect.Parser$5.on(Parser.java:362)
   at com.sun.enterprise.v3.server.ReadableArchiveScannerAdapter.handleEntry(ReadableArchiveScannerAdapter.java:165)
   at com.sun.enterprise.v3.server.ReadableArchiveScannerAdapter.onSelectedEntries(ReadableArchiveScannerAdapter.java:127)
   at org.glassfish.hk2.classmodel.reflect.Parser.doJob(Parser.java:347)
   at org.glassfish.hk2.classmodel.reflect.Parser.access$300(Parser.java:67)
   at org.glassfish.hk2.classmodel.reflect.Parser$3.call(Parser.java:306)
   at org.glassfish.hk2.classmodel.reflect.Parser$3.call(Parser.java:295)
   at java.util.concurrent.FutureTask.run(FutureTask.java:266)
   at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
   at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
   at java.lang.Thread.run(Thread.java:744)

Sometimes the class being examined by GlassFish survives the "crash" and can be used properly within the application, sometimes not. The crashed class will sometimes hinder your application from being deployed. GlassFish complain that the bean of the wanted type could not be found or instantiated. Sometimes, the crashing class will not hinder the deployment from succeeding but the class fails one way or another when he's used instead. For example, resources injected in the bean will fail and your application will inevitably throw a NullPointerException.

Except from the fact that GlassFish has a non-existent support of JDK 1.8, Java itself seem to crash for me every other time I try to build my project and a JavaFX application of mine sometimes black out and various components he's made of is extremely buggy too. So production code should definitely stay away from upgrading to Java 1.8 for a while.

Update

I'm also having serious problems with EclipseLink 2.5.2-M1. One entity class of mine worked perfectly in Java 1.7, then came the time when I added some neat JDK 8 syntax in it. After that, EclipseLink refused to let the entity class be a target for a JPA relationship. EclipseLink said that the entity class was a "non-entity" type. As soon as I rewrote the JDK 8 sugar into legacy 1.7 code all worked just fine again.

Update 2014-07-03

GlassFish 4.0.1-b05 has only one issue with Java 1.8 code: JPA entity classes. Meaning it is EclipseLink that are having the issues. But I can confirm that Java 1.8 code work in EJB:s and CDI managed beans.