groovy

Class that extends ClassLoader compiled with JDK 1.5 fails to run on JDK 1.6 with IncompatibleClassChangeError

Details

  • Type: Sub-task Sub-task
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: 1.8.0
  • Fix Version/s: None
  • Component/s: None
  • Labels:
    None
  • Number of attachments :
    0

Description

We have a class loader like this:

class ParentOnlyClassLoader extends ClassLoader{

    ParentOnlyClassLoader(ClassLoader parent) {
        super(parent)
    }

    @Override protected Class<?> findClass(String name) {
        parent.findClass(name)
    }

}

When this class is compiled with JDK 1.5 then executed in JDK 1.6 you get the error:

java.lang.IncompatibleClassChangeError: the number of constructors during runtime and compile time for java.lang.ClassLoader do not match. Expected 2 but got 3
	at org.grails.plugins.tomcat.ParentOnlyClassLoader.<init>(ParentOnlyClassLoader.groovy:28)
	at org

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
blackdrag blackdrag added a comment -

the important part is not so much waht exact constructors there are in ParentOnlyClassLoader, but what there is in java.lang.ClassLoader. As it seems, at elast on some JDKs, there is an additional private constructor that wrongly gets included here. If we fix that part, then all code compiled with 1.8.0 and before may have a problem. Also it is no final solution. Should the parent class gain a new non-private constructor, for example because of refactoring, this problem will reappear

Show
blackdrag blackdrag added a comment - the important part is not so much waht exact constructors there are in ParentOnlyClassLoader, but what there is in java.lang.ClassLoader. As it seems, at elast on some JDKs, there is an additional private constructor that wrongly gets included here. If we fix that part, then all code compiled with 1.8.0 and before may have a problem. Also it is no final solution. Should the parent class gain a new non-private constructor, for example because of refactoring, this problem will reappear
Hide
Permalink
Jason Anderson added a comment -

This occurs also with code compiled in JDK 6 when running in JDK 7. Groovy 1.8.2

eg. make a Groovy class that extends from Throwable or Exception, and try to run it on JDK 7 and it will get the constructors/runtime error. JDK 7 added some additional protected constructors.

Show
Jason Anderson added a comment - This occurs also with code compiled in JDK 6 when running in JDK 7. Groovy 1.8.2 eg. make a Groovy class that extends from Throwable or Exception, and try to run it on JDK 7 and it will get the constructors/runtime error. JDK 7 added some additional protected constructors.
Hide
Permalink
David Moshal added a comment -

Just ran into this with Groovy 1.8.6 / JDK 7 / OSX

Show
David Moshal added a comment - Just ran into this with Groovy 1.8.6 / JDK 7 / OSX
Hide
Permalink
Pascal Schumacher added a comment -

Reading blackdrags comments I guess this should be closed.

Show
Pascal Schumacher added a comment - Reading blackdrags comments I guess this should be closed.
Hide
Permalink
blackdrag blackdrag added a comment -

Thanks for digging this one out, it will save me the trouble to find it later again.
I do intend to create a new solution for this in which the available constructors are stored as MethodType[] and are given to the runtime to choose from those, instead of the runtime available list of constructors. Possibly I let the runtime filter out the signatures that don't exist anymore. That way there is a good chance a problem like described in the issue here will not appear again

Show
blackdrag blackdrag added a comment - Thanks for digging this one out, it will save me the trouble to find it later again. I do intend to create a new solution for this in which the available constructors are stored as MethodType[] and are given to the runtime to choose from those, instead of the runtime available list of constructors. Possibly I let the runtime filter out the signatures that don't exist anymore. That way there is a good chance a problem like described in the issue here will not appear again

People

  • Assignee:
    Unassigned
    Reporter:
    Graeme Rocher
Vote (4)
Watch (7)

Dates

  • Created:
    Updated: