Re: [groovy-user] compiling in groovy without all jars in classpath
Am 01.07.2012 13:36, schrieb Wujek Srujek:
> Hi. I have the following case: WebApplication is a class in
> ApacheWicket, and it has a field of type javax.servlet.ServletContext.
> When I compile a class that extends WebApplication in Java, it compiles
> fine - I don't need the servlet classes in the classpath. However, the
> same can't be said about Groovy compilation - I get some exception in
> some transformation, whose root cause is a NoCassDefFoundError:
> javax.servlet.ServletContext (I hope this is enough info for you, if
> not, I can whip up some example to get the stacktrace).
> Why does Groovy require me to have all the classes in the classpath? I
> originally asked the question on the Gradle forum, as I am using it to
> build my project, and Peter Niederweiser mentioned that you are doing a
> lot of reflection and stuff. Could you please say something more about
> the nature of the issue? He mentioned you want to fix it in 2.x / 3.x -
> is that the case?
The compiler works entirely using reflection, when it comes to use other
classes. That for example means if your class references another class
in a private field (as type), our classloader does have to load it,
since that is how class loading works. If you parse the .class file, you
can skip such entries and thus save on classes you have to load, not to
mention that you don't involve the classloader at all. As a result you
can compile something in Java that does not compile in Groovy, since the
Groovy compiler requests additional classes.
And yes, we intend to change that finally - as long as the compilation
is done from the command line. I don't remember the exact target, but it
wil go into 2.x unless the change is too big, then it will be Groovy3.
Bte, there has already been a request like that in the past, but back
then I closed it as "won't fix". Back then it was not clear to me what
it means for some people, that for example use that stupid stripped down
J2EE libs, that are incomplete classes and thus will not pass the
verifier if loaded as a class. And that is the case if we compile in
Groovy. It may also improve the speed of the compiler a bit to do that
change, but that we will have to see after it is implemented.
To unsubscribe from this list, please visit: