Roaster: JavaClassSource.getMethods/getMethod returns empty methods

[lrr]

Hello together.

I'm trying to add code to existing methods like this:

final JavaClassSource source = javaResource.getJavaType();
MethodSource<JavaClassSource> method = source.getMethod(...);
String body=method.getBody();
...
method.setBody(body+codeToAdd);

I try this for 6 different methods. 3 of them are empty, when I call method.getBody(). Also when I print source.getMethods, 3 of them are empty. But when I print source.toString(), all the methods contain the expected code.

[gastaldi]

Hi Leonardo,

Are you using Roaster2.20.1.Final? I remember seeing this behavior in older versions when the body is not a compilable Java code.

Can you reproduce it in a test case?

[lrr]

Hello George.

Thanks for your fast response.

Yes I use org.jboss.forge.addon:core 3.7.2.Final which provides Roaster 2.20.1.Final. I tried to reproduce it in a test, but to do so I had to add

<dependency>
  <groupId>org.jboss.forge.roaster</groupId>
  <artifactId>roaster-api</artifactId>
  <version>${version.roaster}</version>
</dependency>
<dependency>
  <groupId>org.jboss.forge.roaster</groupId>
  <artifactId>roaster-jdt</artifactId>
  <version>${version.roaster}</version>
  <scope>runtime</scope>
</dependency>

else I got the error:

java.lang.IllegalStateException: No instances of [org.jboss.forge.roaster.spi.JavaParser] were found on the classpath.

After I added these dependencies, the test was successful, but without the empty body issue and I couldn't run my plugin in the forge ui anymore:

java.lang.reflect.InvocationTargetException

        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)

        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

        at java.lang.reflect.Method.invoke(Method.java:498)

        at org.jboss.forge.furnace.proxy.ClassLoaderInterceptor$1.call(ClassLoaderInterceptor.java:87)

        at org.jboss.forge.furnace.util.ClassLoaders.executeIn(ClassLoaders.java:42)

        at org.jboss.forge.furnace.proxy.ClassLoaderInterceptor.invoke(ClassLoaderInterceptor.java:103)

        at de.forge.domaintype.NewDomainTypeUICommand_$$_javassist_5edefd33-5fc1-4e62-8c3b-cc9eb0deccef.execute(NewDomainTypeUICommand_$$_javassist_5edefd33-5fc1-4e62-8c3b-cc9eb0deccef.java)

        at org.jboss.forge.addon.ui.impl.controller.SingleCommandControllerImpl.execute(SingleCommandControllerImpl.java:94)

        at org.jboss.forge.addon.shell.aesh.CommandAdapter.execute(CommandAdapter.java:97)

        at org.jboss.forge.addon.shell.aesh.ForgeCommandContainer.executeCommand(ForgeCommandContainer.java:88)

        at org.jboss.aesh.console.AeshConsoleImpl$AeshConsoleCallbackImpl.execute(AeshConsoleImpl.java:311)

        at org.jboss.aesh.console.AeshProcess.run(AeshProcess.java:53)

        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)

        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)

        at java.lang.Thread.run(Thread.java:745)

Caused by: java.lang.LinkageError: loader constraint violation: when resolving interface method "org.jboss.forge.addon.parser.java.facets.JavaSourceFacet.saveJavaSource(Lorg/jboss/forge/roaster/model/source/JavaSource;)Lorg/jboss/forge/addon/parser/java/resources/JavaResource;" the class loader (instance of org/jboss/modules/ModuleClassLoader) of the current class, de/forge/task/GenerateJavaFileTask, and the class loader (instance of org/jboss/modules/ModuleClassLoader) for the method's defining class, org/jboss/forge/addon/parser/java/facets/JavaSourceFacet, have different Class objects for the type org/jboss/forge/roaster/model/source/JavaSource used in the signature

[gastaldi]

That's because your test is not running inside a Furnace container. You need to add the @RunWith(Arquillian.class) annotation to your test class to avoid these errors.

Btw, You don't need to use Forge to use Roaster. The roaster libraries alone should be enough to attempt to reproduce your issue

[lrr]

I found the problem now:

The problem is, that if you have syntax errors in the method you want to read, the return of the JavaClassSource.getBody method will be empty without any error message or logging.