Details
-
Bug
-
Status: Closed
-
Minor
-
Resolution: Fixed
-
1.8.4
-
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.