Jochen – thanks for the clarification. I didn't realize this limit was in the JVM – good to know.
I guess my larger point was more perception-oriented than anything. ClassFormatError smells like a bad internal error, and someone like myself seeing that (without knowing as much as yourself about what is really going on), I think: UH-OH, SOMETHING IS DEEPLY WRONG HERE... GROOVY IS UNSTABLE!
For no other reason than because in Java, the only time you would see a ClassFormatError is when your compiler has a bug in it, or if you are trying to run some non-class file through a JVM.
For example, a too-long string literal run through javac produces the following compile-time error: "constant string too long". That feels like the error message from a stable, mature compiler / language. And maybe this is your point as well when you say: "ClassFormatErrors or VerifyErrors are errors and no exceptions".
My only point is that I think the perception of stability comes mainly from making sure that errors are caught up front and reasonable error messages are given, rather than producing an invalid class file and falling back on the JVM to throw a ClassFormatError. And (like many others) I want to see Groovy become perceived as stable in the market place so I can justify its use in my organization, etc.
I agree with you there is nothing to truly be afraid of from a technical standpoint (security, etc). The only thing to fear is fear itself