This message was deleted.

What is reachable and what is not is defined by the Java compiler. Gradle doesn’t do anything special here. So whatever is on the compile classpath is reachable (if javac allows it). So to answer

Question: are other types in the same package reachable from the type’s AST?

They are reachable, since they are probably on the compile classpath. BUT: incremental compilation might not work correctly, if you will reach them and try to do some decision based on that. Example: Java sources:

a/A.java with @MyAnnotation that create a class AList, with a list of all classes in the package
a/B.java

So when we do first compilation and we reach other types, everything works ok, because Gradle does full recompilation:

1. a/A.java is compiled to a/A.class
2. a/B.java is compiled to b/B.class
3. a/A.java generates a/AList.java with content below
4. a/AList.java is compiled to a/AList.class

package a;

class AList {

    public List<String> getClasses() {
       return Arrays.asList("a.A", "a.B");
    }
}

All good. But what happens when we delete a/B.java? Gradle doesn’t know that A, AList and B are related. So A won’t be passed to the compiler on incremental compilation and a/AList.java wont’ be updated. And due to that AList.getClasses() will still return

Arrays.asList("a.A", "a.B")

. That is a silent failure/bug the docs is talking about.

What I was thinking could happen during an incremental compilation of `A.java`: if you called

PackageElement.getEnclosedElements()

for `A`'s corresponding

PackageElement

, it may only be guaranteed to return the top-level types in the package that

A

depends on (including transitive dependencies), not all the top-level types in the package. But now it seems like you can see all the top-level types in the package, even during an incremental compilation. Depending on that information, however, can introduce subtle bugs.

On a related note, I did find a unique edge case where incremental compilation misses an error.

Yes, there are these subtle corner cases indeed.