We Keep Coding

APT-generators stop working after update to Jakarta/Java17

I am working on a rather large project consisting of Spring and JavaEE-components. Right now, I am updating from javax to jakartaEE and also from Java 11 to 17. The build-tool is gradle with several modules, which depend on one another. I have already changed things to make the first modules compile and am now at the module containing the JPA entities.
Suddenly I find myself in a situation, where the metamodel is no longer created.
My basic assumption here is, that gradle itself is not participating in the generation of the Metamodel. Instead, the APT generators are handed over to javac which then recognizes them and executes them prior to compilation.
I have debugged the gradle execution and the processorpath option of javac contains the jpa-metamodel.jar as expected.
Therefore, I assume, I am rather looking at a Java than a Gradle problem.
I did a very simple POC project with the same Java/Hibernate versions and there it worked.
With this project, I was able to verify, that the metamodel-generator issues a log statement. This statement is also issued, if the source code does not compile. So, it seems to be an indicator whether the modelgen is working at all.
This log message is not written in my main project.
Also, next to the jpa-metamodel there are two other apt generators at work. Both show similar behavior, i.e. printing out a log line when working but not in my updated project.
This brings me to the assumption, that it is no problem with the jpa-metamodel-gen but rather with APT itself.
Where should I be looking next?
EDIT
I have done some more researching. Via gradle --debug I was able to extract the actual javac call. Executing that from console shows the same error.
I reduced the number of elements to be compiled. It seems that putting an actual entity on the list of things to be compiled the APT generator goes dormant. Putting only a MappedEntity supertype on the list will still leave the APT active. WTF?
EDIT2
I am currently on my way to a reproducable exmaple. I've cut through a lot of business-related libs and right now, what I have is a havac call, where -processorpath only mentions the jpamodelgen and -classpath only mentions hibernate core (both in Version 6.1.6).
In this constellation the modelgen does not work. As soon as I eliminate the hibernate-core, it works.
Next step: I'll strip down the entities.

All right, that was unexpected.
I condensed it down to a minimal example. Required for this issue to hit is a call similar to this one:
javac \
-processorpath hibernate-jpamodelgen-6.1.6.Final.jar\
-classpath hibernate-core-6.1.6.Final.jar\
BaseEntity.java
The additional condition, that triggers this issue is, that BaseEntity has to have a dysfunctional #Type annotation. #Type has changed its signature from Hibernate 5 to Hibernate 6 and my entities were not yet up to date.
Interestingly enough, neither a generell compile error nor a specific one with other annotations (I tried a broken spring-Repository one) will stop the modelgen from working (as won't the fact, that the processorpath is incomplete in the example).
I will report this as an issue to the hibernate project, as I believe, the modelgen should react more graceful in such a situation.
Reported as bug here:
https://hibernate.atlassian.net/browse/HHH-15946

How to debug project.clj to find which dependency is breaking my project compilation

I have just updated my system from Java 8 to the OpenJDK Java 11 version. I have one project that won't compile and I get the following error:
Java.lang.IllegalArgumentException: Must hint overloaded method:
toArray, compiling:(flatland/ordered/set.clj:19:1)
Exception in thread "main" java.lang.IllegalArgumentException: Must
hint overloaded method: toArray, compiling:
(flatland/ordered/set.clj:19:1)
From the looks of it, this error was fixed here: https://dev.clojure.org/jira/browse/CLJ-2374
So I update my project to clojure 1.10.0-RC3 and now I get this error:
Syntax error compiling deftype* at (flatland/ordered/set.clj:19:1).
Exception in thread "main" Syntax error compiling deftype* at
(flatland/ordered/set.clj:19:1).
Has anyone seen this error OR is there a way for me to expand Clojure's error messages to show me which dependency in my project is failing during compilation (could be multiple)?
I also noticed that I copied over the dependency list which was failing in my first project to a new project and the new project compiled. However, I didn't reference the dependencies or call functions from the deps list. Does Clojure bring in the dependencies/libraries and then reference the required dependencies from the libraries that are included in my project.clj?
EDIT***
I found that this is likely the error.
https://github.com/amalloy/ordered/pull/37

You already have an answer though I thought i'd leave my general process for this incase it's useful for folks who come along later:
turn of any auto AOT in my tooling so i can get a repl witout triggering the problem.
load namespaces one at a time till i find one that triggers the problem (this usually doesn't take long ;-)
comment out half the dependencies of that namespace and evaluate the ns form at the top of the file
do a binary search till i find the one or two that trigger it
load just that dependency in a scrap project.
... lots of effort ...
SUCCESS !

GWT Compiler : when is a compilation error fatal?

I'm trying to understand more about how GWT compilation works.
More specifically, I want to know how does GWT decide that a particular error is fatal, and the app compilation should fail because of it, and how does it decide that compilation is successful, even though there are compilation errors.
The reason I'm asking is that it's very difficult to distinguish legitimate errors in my log when doing a search, from ones that don't seem to cause any problem.
I'm talking about GWT 2.7 and GWT 2.8 (which I've seen they exhibit the same behavior).
Also, I'm using GWTP 1.5.3, if this is relevant somewhat.
A concrete example: I have this error in my logs:
Tracing compile failure path for type 'myApp.ClientModule'
Errors in 'file:/E:/data/.../myApp/ClientModule.java'
Line 24: No source code is available for type myApp.client.ServicesProvidersModuleGen; did you forget to inherit a required module?
Checked 1 dependencies for errors.
The error above does not make my app to fail compilation, and myApp works just fine (the class is something that registers some GIN bindings, which also work).
Why didn't GWT failed my compilation when it encountered that error?
Additionally, I also have other errors such as:
Errors in 'com/google/gwt/validation/client/impl/AbstractGwtSpecificValidator.java'
Line 102: No source code is available for type javax.validation.ValidationException; did you forget to inherit a required module?
Line 177: No source code is available for type javax.validation.ConstraintValidator<A,T>; did you forget to inherit a required module?
Line 153: No source code is available for type javax.validation.groups.Default; did you forget to inherit a required module?
Line 302: No source code is available for type javax.validation.ConstraintViolation<T>; did you forget to inherit a required module?
These errors also don't fail my compilation. Why?
Edit1: forgot to add.
I'm tempted to guess that compilation fails when the error is in something directly reachable from an entry point, and that compilation is OK when that code is not reachable.
However, I have the counter-example of code with annotations.
I have code that IS reachable from the entry point, and has annotations whose source code is not available, and yet the compilation succeeds (although this is the only exception that I could find so far).

Your analysis is good.
GWT will scan the entire classpath, ignoring everything not in the source path and "rebasing" super-sources. During that scan, it emits the kind of error you saw, but only when code will reach the missing sources (from entry points) the error will become fatal. Annotations are no exception, but code will never actually reach them as their just metadata (unless you implement an #interface, which Java allows). Annotations can be used by generators though, in which case they can fail the build.
Note that if you use -failOnError (or -strict, which is an alias), then all errors are fatal. You should aim for turning this on IMO.

Why does GWT compile errors won't break the maven build?

I'm building a GWT project in maven using gwt-maven-plugin.
Recently I noticed an error on a class, where some server code was called on a client class. At first I thought that something was wrong with the gwt compilation (not including this class). But then I notice that it was compiling that class and it was throwing the error on info log level.
[INFO] Tracing compile failure path for type 'com.mycompany.shared.IElement'
[INFO] Errors in 'jar:file:/Users/myuser/.m2/repository/com/mycompany/package/package-java/1.0.0-SNAPSHOT/package-java-1.0.0-SNAPSHOT-sources.jar!/com/mycompany/shared/IElement.java'
[INFO] Line 45: No source code is available for type com.mycompany.test.Tester; did you forget to inherit a required module?
Why this is only a info log?
Why this does not breaks the build?
Can I force the build to break upon this kind of errors?

Yes you can, and in fact you should! Its even likely that this option will be on by default in the future, as these sorts of 'recoverable' errors cause performance issues in the compiler as it keeps recovering and working around the missing code.
Using the maven plugin, you can simply set this flag to true. From http://mojo.codehaus.org/gwt-maven-plugin/compile-mojo.html#failOnError,
failOnError:
Fail compilation if any input file contains an error.
Can be set from command line using '-Dgwt.compiler.strict=true'.
In your plugin's <configuration> block, this looks like
<failOnError>true</failOnError>
(This used to be called <strict>, and in some of my own pom files, still lives that way...)

Eclipse 3.5+ - Annotation processor: Generated classes cannot be imported

I am using a 3rd party annotation processor for generating meta-data code (.java files) from the annotated classes in my project.
I have successfully configured the processor through Eclipse (Properties -> Java Compiler -> Annotation Processing) and the code generation works fine (code is automatically created and generated). Also, Eclipse successfully auto-completes the generated classes and their fields, without any errors. Let's say that I have a class "some.package.Foo" and that the generated meta-data class is "some.package.Foo_". By the help of auto-completion, I can get the following code in the Eclipse editor, without any errors:
import some.package.Foo_;
...
public class Test {
void test() {
Foo_.someField = null; // try to access a field from the generated class Foo_
}
}
However, as soon as I actually build the project (or just save the file since Build automatically is enabled), I get the error which tells that "some.package.Foo_" cannot be resolved.
It seems like Eclipse is generating and compiling the some.package.Foo_ at the same time, or more likely.
I found two temporary solutions (which are practically hindering the use of the annotation processor in the first place):
Before each build of that generated classes, right click on every generated file go to Properties and uncheck the "Derived" tick. After that, I do the cleanup of the project and the imports are fine - there are no more errors. However, if I do the cleanup one more time, the errors again show up, because the generation of the files causes the "Derived" tick to be checked again (automatically). So this is really annoying and time-consuming.
I also uncheck the "Derived" tick
from all those files, and this time
I uncheck the "Derived" tick from
the source folder and packages which
contain those files. Then I disable
the annotation processor, and then
do the cleanup. There are no more
import errors, even if I do another
cleanup, but there is no benefit of
using the annotation processor,
because if I was to change something
which would update the model, I need
to turn the annotation processor
back on, and repeat this tedious
procedure to turn it off, after it
has generated the new version of
those files.
Is this a bug in Eclipse? If yes, is there a better workaround or quick-fix than the two I have stated above? If not, what should I try to solve the problem?
I also tried rearranging the order of the libraries on the build path and it doesn't help.

I assume that you are generating sources in the last processor round. This is not recommended way and leads exactly to the problem that you had.
Explanation is here: http://code.google.com/p/acris/wiki/CodeGenerationPlatform_Pitfall_Rounds
So the my advise is to generate sources in regular processing rounds and final round should be used just for notification that processing is over or something like that.
Hopefully this helps you.

I have a similar problem, and the only thing I've found is that it's the imports specifically that don't work, but the references in the class itself do work. The workaround I've used is to use the FQCN in all cases where the generated class is needed (except when the generated class is in the same package, since then the import is obviously not needed).
So to use your example, I'd do:
public class Test {
void test() {
some.package.Foo_.someField = null; // try to access a field from the generated class Foo_
}
}
My only guess then is that the eclipse compiler is processing the imports before doing the annotation processing, which imho must be a bug in eclipse.
I know this question is over a year old, so I'd be interested to know if you've found any other way to fix it.

We were experiencing a similar problem and apparently just solved it, so thought of sharing it at SO, in case it helps someone.
We are using:
Eclipse Indigo (Build id: 20120216-1857)
m2e Connector for maven
openJPA for static metamodel class generation
Our problem:
Say, we have a package named com.abc.xyz and an entity class in there named OurEntity. When we build the projects (JPA, EJB, EAR etc. all together with an mvn clean at the beginning) the metamodel classes get generated. And also get appropriately packaged within the PU jar. But when we try to import the generated metamodel class com.abc.xyz.OurEntity_, Eclipse cannot resolve it. OP apparently got past this point:-). Maven build failed, saying it could not resolve that class. Not much help from google except for a few bug reports such as this one: https://bugs.eclipse.org/bugs/show_bug.cgi?id=350378
That bug report said importing the whole package as opposed to the single class helped. So, tried that, but with no benefit. It also said (and so did David Heitzman) that using the fully qualified class name worked for them. That did not work either.
The solution:
Added the PU jar to Eclipse build path for the project that needed to use the metamodel classes. All of a sudden all the red underlines went away (not a surprise). But the fear was there might be two PUs in the same ear. But maven automagically took care of that.

As this rather old question got some attention without pointing to the very probable eclipse bug the OP was specifically asking for, I'd like to complement the above answers with a pointer to the eclipse bug tracker:
Cannot resolve import for generated class IF processing annotations with parameters referencing constants
The workarounds include
doing a wildcard import of the package defining the generated classes (i.e. import some.package.*;)
using the fully qualified name of your generated class, i.e. referring to some.package.Foo in your code and not using an import
switch to a newer Eclipse. This specific eclipse bug is resolved with Eclipse version 4.4 (aka Luna).