Let's see, I reported this bug 8 months ago, so whatever version of Java 8 was current back then. 8u25, I think. Now I have 8u51, same exception.

The exception is thrown from the transformer, not the call site, so depending on your weaving setup you won't see a stack trace. The JVM eats exceptions thrown by transformers. I just have Spring "helpfully" logging it for me:

{{2015-08-11 17:09:41.135 WARN 38169 — [localhost-startStop-1] o.s.o.j.p.ClassFileTransformerAdapter : Error weaving class [null] with transformer of clas
s [org.hibernate.ejb.instrument.InterceptFieldClassFileTransformer]

java.lang.instrument.IllegalClassFormatException: null
at org.hibernate.ejb.instrument.InterceptFieldClassFileTransformer.transform(InterceptFieldClassFileTransformer.java:79)
at org.springframework.orm.jpa.persistenceunit.ClassFileTransformerAdapter.transform(ClassFileTransformerAdapter.java:56)
at org.springframework.instrument.classloading.InstrumentationLoadTimeWeaver$FilteringClassFileTransformer.transform(InstrumentationLoadTimeWeaver.java:184)
at sun.instrument.TransformerManager.transform(TransformerManager.java:188)
at sun.instrument.InstrumentationImpl.transform(InstrumentationImpl.java:428)
at sun.misc.Unsafe.defineAnonymousClass(Native Method)
at java.lang.invoke.InnerClassLambdaMetafactory.spinInnerClass(InnerClassLambdaMetafactory.java:324)
at java.lang.invoke.InnerClassLambdaMetafactory.buildCallSite(InnerClassLambdaMetafactory.java:194)
at java.lang.invoke.LambdaMetafactory.metafactory(LambdaMetafactory.java:304)
at java.lang.invoke.CallSite.makeSite(CallSite.java:302)
at java.lang.invoke.MethodHandleNatives.linkCallSiteImpl(MethodHandleNatives.java:307)
at java.lang.invoke.MethodHandleNatives.linkCallSite(MethodHandleNatives.java:297)
... (redacted) ...}}

The stack trace looks weird because InterceptFieldClassFileTransformer eats the NPE. You could set a breakpoint in AbstractClassTransformerImpl, which is what I had to do to root cause this bug.

Repro is simple: set up the enhancer then call a lambda. Bam, exception. Technically it needs to be the first time the lambda is called or else the call site will already be resolved. Also it's an implementation detail whether lambda resolution creates a class. IIUC method references sometimes don't, and maybe simple lambdas don't either. So maybe repro isn't very simple, I dunno, never tried. I've been more on the "stop these stack traces clogging my logs" end of things.

BTW it's literally impossible to trigger this bug with classes compiled by JDK7 because lambdas are Java 8. Modulo crazy hacks or backports, which I'd be somewhat surprised to see in Hibernate's test suite.

So here's the bottom line: I encountered this bug, root caused it, and made a bug report. You guys can do what you want with that, I'd null check className and not bother transforming given that lambdas don't have fields, but it's not my code. If you have a policy about test cases or something that sounds great to me, but I don't have time to write one for you.

P.S. This is also a bug in 4.2.20. The code is the same. And it throws the same exceptions.

P.P.S Have fun trying to come up with a test case for a bug that's usually invisible and at worst causes annoying log messages for people with special snowflake setups.