Weld
  1. Weld
  2. WELD-1074

Using `new Weld()` fails with java.lang.IncompatibleClassChangeError when Guava on classpath?

    Details

    • Similar Issues:
      Show 10 results 

      Description

      I am running Weld in a vanilla JVM using `new Weld()` (having been blocked in AS 7 by https://community.jboss.org/thread/154405).

      I am getting the error shown below. I presume Weld is doing some special classloading that causes it to pick up Guava from somewhere other than the head of the classpath? My question/bug is:

      • is the classloading behaviour documented; are there things that a user must not do?
      • is this error caused by me having Guava ahead of the weld jar on the classpath, and if so can such errors be avoided in weld? Or is it just always necessary to avoid having Weld dependencies ahead of


      I have built Weld myself from master (1.1.6-SNAPSHOT, git commit 282f830) so have the version with guava dependency 11.0.2.
      (Thanks Ales for fixing that one!)


      (note I also put in an extra catch block into BeanDeployer so that it would tell me which class it was trying to load when it got this error).

      org.jboss.weld.resources.spi.ResourceLoadingException: Error loading class com.google.common.collect.StandardTable$ColumnMap
      at org.jboss.weld.resources.ClassTransformer.loadClass(ClassTransformer.java:167)
      at org.jboss.weld.bootstrap.BeanDeployer.addClass(BeanDeployer.java:88)
      at org.jboss.weld.bootstrap.BeanDeployer.addClasses(BeanDeployer.java:118)
      at org.jboss.weld.bootstrap.BeanDeployment.createBeans(BeanDeployment.java:171)
      at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:336)
      at org.jboss.weld.environment.se.Weld.initialize(Weld.java:86)
      at net.ezbrokerage.launcher.EzBrokerageLauncher.<init>(EzBrokerageLauncher.java:31)
      at net.ezbrokerage.launcher.MontereyVenueLauncher.<init>(MontereyVenueLauncher.java:45)
      at net.ezbrokerage.launcher.MontereyVenueLauncher.main(MontereyVenueLauncher.java:86)
      Caused by: java.lang.reflect.GenericSignatureFormatError
      at sun.reflect.generics.parser.SignatureParser.error(SignatureParser.java:103)
      at sun.reflect.generics.parser.SignatureParser.parseSimpleClassTypeSignature(SignatureParser.java:262)
      at sun.reflect.generics.parser.SignatureParser.parseClassTypeSignatureSuffix(SignatureParser.java:270)
      at sun.reflect.generics.parser.SignatureParser.parseClassTypeSignature(SignatureParser.java:244)
      at sun.reflect.generics.parser.SignatureParser.parseFieldTypeSignature(SignatureParser.java:228)
      at sun.reflect.generics.parser.SignatureParser.parseTypeSignature(SignatureParser.java:359)
      at sun.reflect.generics.parser.SignatureParser.parseTypeSig(SignatureParser.java:157)
      at sun.reflect.generics.repository.FieldRepository.parse(FieldRepository.java:34)
      at sun.reflect.generics.repository.FieldRepository.parse(FieldRepository.java:24)
      at sun.reflect.generics.repository.AbstractRepository.<init>(AbstractRepository.java:56)
      at sun.reflect.generics.repository.FieldRepository.<init>(FieldRepository.java:30)
      at sun.reflect.generics.repository.FieldRepository.make(FieldRepository.java:48)
      at java.lang.reflect.Field.getGenericInfo(Field.java:85)
      at java.lang.reflect.Field.getGenericType(Field.java:223)
      at org.jboss.weld.introspector.jlr.WeldFieldImpl.of(WeldFieldImpl.java:52)
      at org.jboss.weld.introspector.jlr.WeldClassImpl.<init>(WeldClassImpl.java:155)
      at org.jboss.weld.introspector.jlr.WeldClassImpl.of(WeldClassImpl.java:119)
      at org.jboss.weld.resources.ClassTransformer$TransformTypeToWeldClass.apply(ClassTransformer.java:59)
      at org.jboss.weld.resources.ClassTransformer$TransformTypeToWeldClass.apply(ClassTransformer.java:50)
      at com.google.common.collect.ComputingConcurrentHashMap$ComputingValueReference.compute(ComputingConcurrentHashMap.java:355)
      at com.google.common.collect.ComputingConcurrentHashMap$ComputingSegment.compute(ComputingConcurrentHashMap.java:184)
      at com.google.common.collect.ComputingConcurrentHashMap$ComputingSegment.getOrCompute(ComputingConcurrentHashMap.java:153)
      at com.google.common.collect.ComputingConcurrentHashMap.getOrCompute(ComputingConcurrentHashMap.java:69)
      at com.google.common.collect.ComputingConcurrentHashMap$ComputingMapAdapter.get(ComputingConcurrentHashMap.java:393)
      at org.jboss.weld.resources.ClassTransformer.loadClass(ClassTransformer.java:163)
      ... 8 more
      Exception in thread "main" java.lang.IncompatibleClassChangeError: Implementing class
      at java.lang.ClassLoader.defineClass1(Native Method)
      at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631)
      at java.lang.ClassLoader.defineClass(ClassLoader.java:615)
      at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
      at java.net.URLClassLoader.defineClass(URLClassLoader.java:283)
      at java.net.URLClassLoader.access$000(URLClassLoader.java:58)
      at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
      at java.security.AccessController.doPrivileged(Native Method)
      at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
      at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
      at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
      at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
      at java.lang.ClassLoader.defineClass1(Native Method)
      at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631)

      at java.lang.ClassLoader.defineClass(ClassLoader.java:615)
      at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
      at java.net.URLClassLoader.defineClass(URLClassLoader.java:283)
      at java.net.URLClassLoader.access$000(URLClassLoader.java:58)
      at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
      at java.security.AccessController.doPrivileged(Native Method)
      at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
      at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
      at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
      at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
      at org.jboss.weld.environment.se.discovery.url.WeldSEResourceLoader.classForName(WeldSEResourceLoader.java:40)
      at org.jboss.weld.bootstrap.BeanDeployer.addClass(BeanDeployer.java:78)
      at org.jboss.weld.bootstrap.BeanDeployer.addClasses(BeanDeployer.java:118)
      at org.jboss.weld.bootstrap.BeanDeployment.createBeans(BeanDeployment.java:171)
      at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:336)
      at org.jboss.weld.environment.se.Weld.initialize(Weld.java:86)
      at net.ezbrokerage.launcher.EzBrokerageLauncher.<init>(EzBrokerageLauncher.java:31)
      at net.ezbrokerage.launcher.MontereyVenueLauncher.<init>(MontereyVenueLauncher.java:45)
      at net.ezbrokerage.launcher.MontereyVenueLauncher.main(MontereyVenueLauncher.java:86)

        Activity

        Hide
        Ales Justin
        added a comment -

        Which weld-se jar are you using?

        As there is shaded SE and pure core SE jar.
        If shaded, then it could be an issue of dup classes perhaps?

        Any way to create some test for this?

        Show
        Ales Justin
        added a comment - Which weld-se jar are you using? As there is shaded SE and pure core SE jar. If shaded, then it could be an issue of dup classes perhaps? Any way to create some test for this?
        Hide
        Aled Sage
        added a comment -

        I had on my classpath: org/jboss/weld/se/weld-se/1.1.6-SNAPSHOT/weld-se-1.1.6-SNAPSHOT.jar and (later in the classpath) a shaded jar that also includes org.jboss.weld classes. Digging into this more, it looks like that shaded jar contains org/jboss/weld/se/weld-se/1.1.5.Final/weld-se-1.1.5.Final.jar and org/jboss/weld/weld-build-config/1.1.5.Final/weld-build-config-1.1.5.Final.jar. Note the different version number.

        I'm now using a classpath based on exactly what maven pulls in (by copying System.getProperty("java.class.path") from when I run it in my IDE), rather than using a hand crafted approximation. This makes the error go away. So your suggestion of dup classes sounds spot on.

        I'll experiment more to produce a test when I get a chance, but probably not in the next couple of days.

        Show
        Aled Sage
        added a comment - I had on my classpath: org/jboss/weld/se/weld-se/1.1.6-SNAPSHOT/weld-se-1.1.6-SNAPSHOT.jar and (later in the classpath) a shaded jar that also includes org.jboss.weld classes. Digging into this more, it looks like that shaded jar contains org/jboss/weld/se/weld-se/1.1.5.Final/weld-se-1.1.5.Final.jar and org/jboss/weld/weld-build-config/1.1.5.Final/weld-build-config-1.1.5.Final.jar. Note the different version number. I'm now using a classpath based on exactly what maven pulls in (by copying System.getProperty("java.class.path") from when I run it in my IDE), rather than using a hand crafted approximation. This makes the error go away. So your suggestion of dup classes sounds spot on. I'll experiment more to produce a test when I get a chance, but probably not in the next couple of days.
        Hide
        Ales Justin
        added a comment -

        From me: I doubt the classpath order has anything to do with this ...

        From Stuart: Like the first answer says, it means that you have code that was compiled against a different version of the class on the Class Path.

        I'll have a look, to sort out this versions.
        But imo, this is mostly your problem not a bug.

        Show
        Ales Justin
        added a comment - From me: I doubt the classpath order has anything to do with this ... http://stackoverflow.com/questions/1980452/what-causes-java-lang-incompatibleclasschangeerror From Stuart: Like the first answer says, it means that you have code that was compiled against a different version of the class on the Class Path. I'll have a look, to sort out this versions. But imo, this is mostly your problem not a bug.

          People

          • Assignee:
            Unassigned
            Reporter:
            Aled Sage
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: