When I have ....generateSources(JavaFileObjects.forSourceString("HelloWorld", "public class HelloWorld { }\n")); I get an error (see below), this is true even if I use forResource(String) for a file I used in the source list to ASSERT.about(javaSources()).that(...). Everything else works, it seems to be some sort of configuration issue.

ERROR!
java.lang.NoClassDefFoundError: com/sun/tools/javac/api/JavacTool
    at com.google.testing.compile.Compilation.parse(Compilation.java:86)
    at com.google.testing.compile.JavaSourcesSubject$SuccessfulCompilationBuilder.generatesSources(JavaSourcesSubject.java:255)
    at com.imminentmeals.prestige.codegen.TestController.testControllerForPresentationWithProtocol(TestController.java:167)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:601)
    at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
    at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
    at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
    at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
    at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
    at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
    at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
    at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
    at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
    at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
    at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
    at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
    at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
    at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:35)
    at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:115)
    at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:97)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:601)
    at org.apache.maven.surefire.booter.ProviderFactory$ClassLoaderProxy.invoke(ProviderFactory.java:103)
    at $Proxy0.invoke(Unknown Source)
    at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:150)
    at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcess(SurefireStarter.java:91)
    at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:69)
Caused by: java.lang.ClassNotFoundException: com.sun.tools.javac.api.JavacTool
    at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
    at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:423)
    at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
    ... 32 more

Add Compilation.classLoader() method (and an overloaded version that takes a parent classloader). The returned ClassLoader is useful for loading generated classes and resources.

I have a code in my annotation processor and it works fine when I compile sources using this annotation processor (with Maven, for example). Simplified version of code looks like this:

try {
    FileObject fileObject = filer.getResource(StandardLocation.SOURCE_PATH, "org.example", "MyMapper.java");
    String content = fileObject.getCharContent(false).toString();
} catch (IOException e) {
    // ...
}

When I try to test my code using compile-testing, it fails on the first line with error:

java.io.FileNotFoundException: org.example/MyMapper.java

If I change the location from StandardLocation.SOURCE_PATH to StandardLocation.SOURCE_OUTPUT), then Filer will successfully return FileObject in the first line, but then the code will fail in the second line, where I try to read the contents of FileObject:

java.io.FileNotFoundException

FileNotFound without any message.

I have a small repro in this branch - https://github.com/jbreathe/corgi/tree/ct-issue. You can find test itself here. And class where Filer used here (getFileObject and readAllLines methods).

Version of Java is 14.

Maybe the second one is a known issue? And about the first one - can I read FileObject using StandardLocation.SOURCE_PATH?

UPD: to be more clear - I'm trying to read a file that is passed to "Compiler#compile". See test for more details.

I don't know if I am doing something wrong but this seems odd to me.

To reproduce this:

@Test
public void testMap() {
    final JavaFileObject actualSource = JavaFileObjects.forSourceString("test/MapTest", Joiner.on('\n').join(
        "package test;",

        "import nsmodelextractor.Extract;",

        "import java.util.Map;",
        "import java.lang.String;",
        "import java.lang.Integer;",

        "public class MapTest {",
            "@Extract Map<String, Integer> map = null;",
        "}")
    );

    assertAbout(javaSource()).that(actualSource).compilesWithoutError();
}

The extract annotations looks like this

@Retention(CLASS)
@Target(FIELD)
public @interface Extract {
    String name() default "";
}

I also tried it without any imports. However I keep on getting

Unknown variable type java.util.Map<java.lang.String,java.lang.Integer> for declared

I'm using com.google.testing.compile:compile-testing:0.7

I was running this project for the first time and got a NPE....

So I grab the sources and figure out was a really simple fix, and didn't hurt add a polished message

I'm thinking of something on the order of

ASSERT.about(javaSources()).that(source)
    .compileswithoutError().and()
    .generatesSourceAtPath("path").containingSnippets("some valid snippet").and()
    .generatesSourceAtPath("path").containingMethods(
        "method signature1", 
        "method signature2").and()
    .generatesSourceAtPath("path").containingFields(
        "String foo", 
        "private Blah blah").and()
     ...

Doesn't have to be exactly like this, and the snippets version could stand in for all the rest. But it would be nice to ask things about the generated output while testing.

Hello,

i generate Java Files with Lombok Annotations from my own Annotation Processor, when testing i get the following compile error : "is not abstract and does not override abstract method".

Test Case

    void process() {
        ReleationProcessor releationProcessor = new ReleationProcessor();
        Compilation compilation = javac()
                .withProcessors(releationProcessor)
                .compile(JavaFileObjects.forResource("TestFile.java"));
        CompilationSubject.assertThat(compilation).succeeded();

Generated File from Annotation Processor

@Setter
@Getter
public final class Testing implements Model {
  private String targetType;
}

On my normal build everything works fine. Is there some way to ignore the compile error or add an option for Lombok Annotations.

Ty Mom0

As you already probably know, Guava is notoriously known for causing conflicts because of its aggressive pruning policy. And well, that's exactly the blocker for me.

As I briefly mentioned in https://github.com/google/compile-testing/issues/124, the last released version of compile-testing pulls Guava 20.0 which is incompatible with Neo4j (that pulls Guava 18.0).

Would you consider releasing an extra artefact that inlines Guava (or removing Guava altogether but that's probably not that easy).

If I have a generated source with a compile error, it is difficult to understand what the error is from the error message alone since there is no easy way to compare to the actual source.

It would be nice if the error message dumped a copy of the source file annotated with the compile errors. In general having easier access to the generated sources would make iterative test development easier.

Add an ability to pass in compiler configuration options (say, to configure annotation processors' flags).

Created by MOE: http://code.google.com/p/moe-java MOE_MIGRATED_REVID=85151739

Due to subtle issues iwth java6/java7 and the com.sun.tools.javac.api crap, NoSuchMethodErrors are being thrown when deployed artifact is being used with any Java6 API.

java.lang.NoSuchMethodError: com.sun.tools.javac.api.JavacTool.getStandardFileManager(Ljavax/tools/DiagnosticListener;Ljava/util/Locale;Ljava/nio/charset/Charset;)Lcom/sun/tools/javac/file/JavacFileManager;
    at com.google.testing.compile.Compilation.compile(Compilation.java:60)
    at com.google.testing.compile.JavaSourcesSubject$CompilationClause.compilesWithoutError(JavaSourcesSubject.java:89)
    at my.tests..MyTest.testFoo(MyTest.java:75)
        ...

Not sure why - the API doesn't SEEM to have changed between versions, though I might have missed it. The call in question might need to be made reflectively in order to try one, then the other. But we should build it in 6 so it can be used in 6, and deploy from that build, OR we should decide that Java6 is not supported and document it.

In InMemoryJavaFileManager the method uriForJavaFileObject() is defined as such:

private static URI uriForJavaFileObject(Location location, String className, Kind kind) {
return URI.create(
    "mem:///" + location.getName() + '/' + className.replace('.', '/') + kind.extension);
}

EXPECTED: This method works for any Location object.

ACTUAL:

This breaks when using modules.

When the JavacTask runs validate() on the arguments in JavacTaskImpl.prepareCompiler(), if a module has been found, the CLASS_OUTPUT location will be determined by asking the JavaFileManager for the location for that module

fm.getLocationForModule(StandardLocation.CLASS_OUTPUT, moduleName)

This will lead to Locations.OutputLocationHandler.getLocationForModule(moduleName) being called, which returns a Location of type Locations.ModuleLocationHandler with the name set to location.getName() + "[" + name + "]" eg. "CLASS_OUTPUT[foo]" if the module name is "foo".

@Override
Location getLocationForModule(String name) {
    if (moduleTable == null) {
        moduleTable = new ModuleTable();
    }
    ModuleLocationHandler l = moduleTable.get(name);
    if (l == null) {
        Path out = outputDir.resolve(name);
        l = new ModuleLocationHandler(this, location.getName() + "[" + name + "]",
                name, Collections.singletonList(out), true);
        moduleTable.add(l);
    }
    return l;
}

The validate() method will then call getJavaFileForInput() using this location, which calls the InMemoryJavaFileManager.uriForJavaFileObject() method.

Due to location.getName returning "CLASS_OUTPUT[foo]", URL.create will throw the following exception:

java.lang.IllegalArgumentException: Illegal character in path

It gives index 19, which is the square opening bracket [ in mem:///CLASS_OUTPUT[test]/....

This makes it not possible to directly use location.getName() in the uriForJavaFileObject() method for any given Location object, without encoding this name in some form, before passing it along to URL.create()

SOLUTION: Encode the location name in some way, so that illegal URI characters won't be passed along to the URL.create() method.

VERSIONS USED: compile-testing: 0.19 JDK: AZUL-17 version 17.0.4.1

From a previous discussion, I was invited to fix checkstyle currently not working properly. This PR is my take on that. What it does:

• pom.xl:
  • make checkstyle plugin work again
  • fix warning about required maven version
• fixes 13 errors reported by checkstyle plugin
• adds a maven wrapper to the project.

TODO: run checkstyle in CI, this is left up for you.

JDK 16 will change the default for the --illegal-access flag from permit to deny. This means that, by default, compile-testing tests will fail with messages like this:

class com.google.testing.compile.Parser (in unnamed module @0x4114d843) cannot access class
com.sun.tools.javac.api.JavacTool (in module jdk.compiler) because module jdk.compiler does not export
com.sun.tools.javac.api to unnamed module @0x4114d843

That can be worked around either by explicitly specifying, on the command line of the JVM running the tests, either --illegal-access=permit or --add-opens=jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED. We should document that, and perhaps later find a way to make it unnecessary.

I am trying to use this library to unit test a javac plugin.

The plugin works fine when compilation is done through javac directly:

javac src/test/resources/HelloWorld.java -Xplugin:SamplePlugin -cp 'target/classes/'

But the following unit test fails:

/**
 * Fails, while it shouldn't. The error message:
 * error: plug-in not found: SamplePlugin
 * No files were generated.
 *   at [email protected]/sample.SampleTest.withPlugin(SampleTest.java:48)
 */
@Test
public void withPlugin() {
	Compilation compilation = Compiler.javac()
			.withOptions("-Xplugin:SamplePlugin")
			.withClasspath(List.of(new File("target/classes")))
			.compile(JavaFileObjects.forResource("HelloWorld.java"));
	CompilationSubject.assertThat(compilation).succeeded();
}

The classpath itself is correct, as demonstrated by these unit tests:

/**
 * The compilation fails due to {@code sample.SampleClass} not being available.
 */
@Test
public void withoutClasspath() {
	Compilation compilation = Compiler.javac()
			.compile(JavaFileObjects.forResource("HelloWorld.java"));
	CompilationSubject.assertThat(compilation).failed();
}

/**
 * Compilation succeeds.
 */
@Test
public void withoutPlugin() {
	Compilation compilation = Compiler.javac()
			.withClasspath(List.of(new File("target/classes")))
			.compile(JavaFileObjects.forResource("HelloWorld.java"));
	CompilationSubject.assertThat(compilation).succeeded();
}

I have uploaded this minimalistic sample Maven project to help the confirmation and the reproduction of this issue: Sample.zip

If a matching file is found but the content just doesn't match, generatesFiles() will report that no matching file was found. While maybe technically correct if "matching" in this case includes the content, it's misleading in practice since the target file name was found and the content mismatch is the interesting bit.