Groovy
  1. Groovy
  2. GROOVY-5140

ASTTransformationCustomizer uses wrong classloader to find transformer class from annotation

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 1.8.4
    • Fix Version/s: 1.8.5, 2.0-beta-2
    • Component/s: Compiler
    • Labels:
      None

      Description

      ASTTransformationCustomizer.

      In this method:

          private static Class<ASTTransformation> findASTTranformationClass(Class<? extends Annotation> anAnnotationClass) {
              final GroovyASTTransformationClass annotation = anAnnotationClass.getAnnotation(GroovyASTTransformationClass)
              if (annotation==null) throw new IllegalArgumentException("Provided class doesn't look like an AST @interface")
      
              Class[] classes = annotation.classes()
              String[] classesAsStrings = annotation.value()
              if (classes.length+classesAsStrings.length>1) {
                  throw new IllegalArgumentException("AST transformation customizer doesn't support AST transforms with multiple classes")
              }
              return classes?classes[0]:Class.forName(classesAsStrings[0])
          }
      

      Class.forName has no classloader, which means it using the loader associated with ASTTransformationCustomizer, but when I use it from inside STS that loader is associated with the Eclipse/STS infrastructure and the transform isn't on its classpath (since it is part of the compiled project, not the compiler infrastructure).

      It would seem more logical/correct if Class.forName here should use an explicit classloader and pass it the classloader from the annotation instead. After all, I think the annotation class should refer to the transformer class, so the annotation's classloader should be able to find the transform class.

      On the other hand, there doesn't seem to be a logical connection between ASTTransformationCustomizer and some random transform class attached to a random annotation that guarantees the class can be found by the ASTTransformationCustomizer's classloader.

        Activity

        Kris De Volder created issue -
        Hide
        Paul King added a comment -

        add code tags

        Show
        Paul King added a comment - add code tags
        Paul King made changes -
        Field Original Value New Value
        Description ASTTransformationCustomizer.

        In this method:
            private static Class<ASTTransformation> findASTTranformationClass(Class<? extends Annotation> anAnnotationClass) {
                final GroovyASTTransformationClass annotation = anAnnotationClass.getAnnotation(GroovyASTTransformationClass)
                if (annotation==null) throw new IllegalArgumentException("Provided class doesn't look like an AST @interface")

                Class[] classes = annotation.classes()
                String[] classesAsStrings = annotation.value()
                if (classes.length+classesAsStrings.length>1) {
                    throw new IllegalArgumentException("AST transformation customizer doesn't support AST transforms with multiple classes")
                }
                return classes?classes[0]:Class.forName(classesAsStrings[0])
            }

        Class.forName has no classloader, which means it using the loader associated with ASTTransformationCustomizer, but when I use it from inside STS that loader is associated with the Eclipse/STS infrastructure and the transform isn't on its classpath (since it is part of the compiled project, not the compiler infrastructure).

        It would seem more logical/correct if Class.forName here should use an explicit classloader and pass it the classloader from the annotation instead. After all, I think the annotation class should refer to the transformer class, so the annotation's classloader should be able to find the transform class.

        On the other hand, there doesn't seem to be a logical connection between ASTTransformationCustomizer and some random transform class attached to a random annotation that guarantees the class can be found by the ASTTransformationCustomizer's classloader.
        ASTTransformationCustomizer.

        In this method:
        {code}
            private static Class<ASTTransformation> findASTTranformationClass(Class<? extends Annotation> anAnnotationClass) {
                final GroovyASTTransformationClass annotation = anAnnotationClass.getAnnotation(GroovyASTTransformationClass)
                if (annotation==null) throw new IllegalArgumentException("Provided class doesn't look like an AST @interface")

                Class[] classes = annotation.classes()
                String[] classesAsStrings = annotation.value()
                if (classes.length+classesAsStrings.length>1) {
                    throw new IllegalArgumentException("AST transformation customizer doesn't support AST transforms with multiple classes")
                }
                return classes?classes[0]:Class.forName(classesAsStrings[0])
            }
        {code}

        {{Class.forName}} has no classloader, which means it using the loader associated with {{ASTTransformationCustomizer}}, but when I use it from inside STS that loader is associated with the Eclipse/STS infrastructure and the transform isn't on its classpath (since it is part of the compiled project, not the compiler infrastructure).

        It would seem more logical/correct if {{Class.forName}} here should use an explicit classloader and pass it the classloader from the annotation instead. After all, I think the annotation class should refer to the transformer class, so the annotation's classloader should be able to find the transform class.

        On the other hand, there doesn't seem to be a logical connection between {{ASTTransformationCustomizer}} and some random transform class attached to a random annotation that guarantees the class can be found by the {{ASTTransformationCustomizer}}'s classloader.
        Cédric Champeau made changes -
        Assignee Cedric Champeau [ melix ]
        Cédric Champeau made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Fix Version/s 1.8.5 [ 18071 ]
        Resolution Fixed [ 1 ]
        Fix Version/s 2.0-beta-2 [ 18072 ]
        Paul King made changes -
        Status Resolved [ 5 ] Closed [ 6 ]
        Mark Thomas made changes -
        Project Import Sun Apr 05 13:32:57 UTC 2015 [ 1428240777691 ]
        Mark Thomas made changes -
        Workflow jira [ 12734064 ] Default workflow, editable Closed status [ 12745890 ]
        Mark Thomas made changes -
        Project Import Mon Apr 06 02:11:23 UTC 2015 [ 1428286283443 ]
        Mark Thomas made changes -
        Workflow jira [ 12973744 ] Default workflow, editable Closed status [ 12980901 ]
        Transition Time In Source Status Execution Times Last Executer Last Execution Date
        Open Open Resolved Resolved
        9h 8m 1 Cédric Champeau 24/Nov/11 03:10
        Resolved Resolved Closed Closed
        29d 23h 57m 1 Paul King 24/Dec/11 03:08

          People

          • Assignee:
            Cédric Champeau
            Reporter:
            Kris De Volder
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development