https://github.com/bartoszmajsak/groovy-classloading

Strange behaviour when using Groovy 2.0
https://github.com/bartoszmajsak/groovy-classloading

Last synced: 26 days ago
JSON representation

Strange behaviour when using Groovy 2.0

• Host: GitHub
• URL: https://github.com/bartoszmajsak/groovy-classloading
• Owner: bartoszmajsak
• Created: 2013-03-12T19:23:38.000Z (over 11 years ago)
• Default Branch: master
• Last Pushed: 2013-03-14T19:54:02.000Z (over 11 years ago)
• Last Synced: 2023-03-14T04:25:22.514Z (over 1 year ago)
• Language: Java
• Size: 5.34 MB
• Stars: 0
• Watchers: 1
• Forks: 0
• Open Issues: 0
• Metadata Files:
  • Readme: README.md

Awesome Lists containing this project

README

        
### TL;DR : It's not a bug! It's a feature - http://bugs.sun.com/view_bug.do?bug_id=4761949

Following project demonstrates a problem (?) with classloading in Groovy 2.0.

Invoking `groovyClassLoader.getResource("groovy")` returns `null`, but when using Groovy 1.8 it returns URL to the jar file from classpath (groovy-all).

Interesting thing is that `groovy-all-2.0.4` which is used in the failing example has similar structure to the 1.8 version.

 * Use `mvn clean package` to run against Groovy 1.8 (tests will pass)

 * Use `mvn clean package -Pgroovy20` to run against Groovy 2.0 (one test will fail)

```

mvn -version

Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100)

Maven home: /usr/local/apache-maven/apache-maven-3.0.3

Java version: 1.7.0_15, vendor: Oracle Corporation

Java home: /usr/lib/jvm/java-7-openjdk-amd64/jre

Default locale: en_US, platform encoding: UTF-8

OS name: "linux", version: "3.2.0-38-generic", arch: "amd64", family: "unix"

```

The same behaviour under JDK6 from Oracle.

If you use repackaged JAR included in this repositry (i.e. by using `` for dependency in Maven) this test will pass.

### Evaluation

I came across this behaviour while working on Groovy 2.0 support for Spock Test Runner. First I thought that there is some essential difference in the MANIFEST file. But after repacking (`jar xvf` and then `jar cvf`) including the same manifest file the test was passing. Here's the isolated problem shared as mvn project on github.

Interestingly enough those two JARs are identical in terms of the content (at least based on what `pkgdiff` is showing), but they were still different in the size. Then I tried `zipinfo`, and here's when I saw the real problem. Original groovy JAR was packaged without the directory entries, and therefore, according to [this bug evaluation from Sun](http://bugs.sun.com/view_bug.do?bug_id=4761949) the JAR is not found through the `classLoader.getResource()` call. To quote:

> In general, Class.getResource() is intended to access file based resources (on the filesystem, or from jar files or wherever..) It is not specified

what the effect of accessing a directory entry is, and therefore this behavior can not be expected to be the same across different URL schemes.