groovy.lang.GroovyRuntimeException: Conflicting module versions. Module [groovy-all is loaded in version 2.1.8 and you are trying to load version 2.1.9

8. December, 2014

If you see this error while running the code from Eclipse, check the .classpath file for this line:

<classpathentry exported="true" kind="con" path="GROOVY_SUPPORT"/>

In this case, Eclipse adds version 2.1.8 to the classpath and Maven adds 2.1.9. At runtime, Groovy detects both versions and aborts since this will cause subtle bugs.

Solution: Delete the line above in the .classpath file.

If you see a line which contains GROOVY_DSL_SUPPORT, then you can leave that in – the Groovy plugin will use the JARs which Maven adds to the classpath.

Leave a Comment » | Software | Tagged: , , , | Permalink
Posted by digulla

Precompiling Custom JARs

24. June, 2009

Java 5 precompiles the rt.jar to a file with the JIT when you start it the first time. This is mostly to improve startup times; it takes only a few moments and is much more efficient than running the JIT when a class has been used more than N times. Next time the class is requested, the VM skips the bytecode loading and directly pulls in the precompiled binary which is already optimized for your CPU.

My idea is to open this process for custom JARs. Any big Java app loads heaps of external JARs and that takes time – often a lot of time. JARs would need to supply a special META-INF file which contains a UUID or a checksum from which the VM can conclude whether the JAR has changed or not.

The first time the JAR shows up in the classpath, the JIT precompiler would convert it, save the result in the cache. Next time, the META-INF file would be read, and the bytecode would be ignored. I’ll open a enhancement request in OpenJDK 7. If you like the idea, please support it.

Leave a Comment » | Software | Tagged: , , , , | Permalink
Posted by digulla

%d bloggers like this: