@SneakyThrows on Java 9 fails to remove reference to lombok/Lombok.sneakyThrow from bytecode

[wrprice]

@SneakyThrows appears to be broken using (as of today) the most recent lombok-edge.jar (1.16.19, 2017-11-06 22:07:40 UTC) with Java 9.0.0 GA. The symptoms are similar to closed issue #708 (for Java 8), and I'm referencing issue #985 for tracking purposes.

Example code:

@SneakyThrows
public Object invoke(Object arg)
{
    return methodHandle.invokeExact(arg);
}

Java 8u152 generates:

  public java.lang.Object invoke(java.lang.Object);
    Code:
       0: aload_0
       1: getfield      #25                 // Field methodHandle:Ljava/lang/invoke/MethodHandle;
       4: aload_1
       5: invokevirtual #87                 // Method java/lang/invoke/MethodHandle.invokeExact:(Ljava/lang/Object;)Ljava/lang/Object;
       8: areturn
       9: astore_2
      10: aload_2
      11: athrow
    Exception table:
       from    to  target type
           0     8     9   Class java/lang/Throwable

Java 9 generates:

  public java.lang.Object invoke(java.lang.Object);
    Code:
       0: aload_0
       1: getfield      #25                 // Field methodHandle:Ljava/lang/invoke/MethodHandle;
       4: aload_1
       5: invokevirtual #87                 // Method java/lang/invoke/MethodHandle.invokeExact:(Ljava/lang/Object;)Ljava/lang/Object;
       8: areturn
       9: astore_2
      10: aload_2
      11: invokestatic  #89                 // Method lombok/Lombok.sneakyThrow:(Ljava/lang/Throwable;)Ljava/lang/RuntimeException;
      14: athrow
    Exception table:
       from    to  target type
           0     8     9   Class java/lang/Throwable

All my other uses of Lombok in this project work correctly AFAICT; my getters/setters, constructors, etc. are all there. Unit tests caught it, and now they don't pass unless Lombok is in the runtime classpath.

[rspilker]

Thanks, I'll look into this.

[rspilker]

I can reproduce the problem

[rspilker]

In jdk9, JavaFileManager.getJavaFileObjectForOutput(...) is not invoked for writing the class files, where in jdk8 it is. Or a different fileManager reference is used, we replace the fileManager in the Context and in JavacFiler that is in the processingEnv. Possibly jdk9 still has a different reference, still browsing the source code.

[rspilker]

I wanted to suggest a workaround: using java -jar post-compile . would remove lombok references from the generated class files. However, that one is also still broken :-( but the fix seems pretty simple: we need to update our dependency on ASM.

[rspilker]

1. We've updated ASM, so in the next release we will be able to use the post-compile command again
2. But that should not be necessary, since we've discovered how to invoke get involved in writing to classfiles in jdk9!
3. Still need to do some code cleanup and test on jdk8/jdk7 before we can push it.

[wrprice]

Thanks for the updates, the hard work, and the workarounds. I've got javassist on my classpath, so I hand-crafted my own bytecode to do something similar to sneakyThrow in the meantime. We're looking forward to the next release, it's my last blocker for JDK9.

[rspilker]

Tested the fix in jdk8 and jdk9. Both work.