ElementAnnotationUtil.getLocationTypeADT: invalid location [WILDCARD] for type: String; #2173
Comments
|
Expieriencing the same on one of my private repos. The last class to be printed by the |
|
I think I have the same bug, stack trace below. This is a central 1000-line class in my project so I can't easily cut it down. Some notes:
|
|
Since 2.5.7 (November Release) I get a bunch of them. i.E. it's probably related to #979 To see how to get there: do No chance to get it working! You'll either get a warning about NonNull vs Nullable, or (if you add the NonNull annotation) you'll get the |
|
@bmhm Thanks for the test case. I'm unfortunately unable to reproduce the problem. import java.util.Collection;
import java.util.Collections;
import java.util.Objects;
import java.util.stream.Collectors;
import org.checkerframework.checker.nullness.qual.NonNull;
class Issue2173 {
void foo() {
Collection<?> mycollection = Collections.singletonList((String) null);
mycollection.stream()
.filter(Objects::nonNull)
.filter(item -> item instanceof String)
.map(item -> (@NonNull String) item)
.collect(Collectors.toSet());
}
}When I run the current Nullness Checker I get: What do I need to change to reproduce the |
|
Ooh, something just came to my mind! Please try the IBM j9 (please find it bundled with liberty profile on wasdev) and the successor openjdk-openj9 available from adoptopenjdk.net. That might be the reason. |
|
Also regarding your example: what's wrong with the cast? |
|
Regarding the JDK: I don't have any experience with j9 yet. Let me try that and see. Regarding the warning from the cast: because of #979 we infer |
|
I tried OpenJ9 and still can't reproduce the issue. I even built a version of our annotated Can you try again to reproduce the issue with a small example? |
|
I'll try. Thanks for looking into it. |
|
I tried my very best, but I still was not able to reproduce it. I took the maven module into a new project and the error was gone. I then tried to check all maven plugin versions, but with no luck. Sorry… |
|
I've managed to attach a debugger to the compiler when the problem occurred. I have a method like this in class ImportManager: When this method is called from class View, the Except that Window doesn't have a type argument, hence the error. Not to mention that Window probably shouldn't be interacting with the @Localized checker? None of the other annotations have TYPE_ARGUMENT in them. I'll keep digging, I guess the remaining questions are: (a) how did this invalid location get there, and (b) how come a rebuild will fix it, but I can reproduce it reliably in this state until I rebuild. It feels like it may relate to pulling information out of already-compiled class files versus pulling it out of source code in the same compilation? |
|
Now that I know where the issue lies, I've been able to produce a reasonably minimal example. I have two classes which I put in an IntelliJ project, running the Nullness checker: And a second: If I Rebuild the project, everything is always fine. If I then make a trivial modification to View (e.g. add a blank line) and Build Project, I always get the error. The culprit seems to be a combination of that messy stream code in ImporterManager, coupled with building View separately to ImporterManager. I hope that helps you pinpoint the issue. I couldn't reproduce this with Maven because Maven seems to always build all classes from a module at once, and the separate compilation seems to be crucial here. I don't think IntelliJ is relevant other than that it builds only the modified classes, leaving the existing up-to-date classes out of it. |
|
Thanks very much for the reproducible test case! This is extremely helpful. These commands reproduce the problem from the command line for me: export JAVA_HOME=$HOME/java/jdk1.8.0_122-b02
cd ~/tmp/issue2173/
javacheck -processor nullness -cp .:${JAVA_HOME}/jre/lib/ext/jfxrt.jar ImporterManager.java
touch View.java
javacheck -processor nullness -cp .:${JAVA_HOME}/jre/lib/ext/jfxrt.jar View.java |
|
I have committed a test case in branch |
|
@twistedsquare @bmhm Java 8 stored this type annotation with method I'm adding the test case here: https://github.com/eisop/checker-framework/pull/23/files So once #1224 is fixed and we move to a Java 9 compiler, we can close this bug. |
|
@wmdietl you referenced a java 9 issue, but this issue is about java 8. Does this mean you're giving up on java 8 support? :( |
|
The eisop version of the Checker Framework uses a Java 9 javac, but can still be executed with a Java 8 JVM. |
|
Hello @wmdietl I was able to reproduce it in another repository: I use checker 2.8.1. You can check out that specific commit, remove the skips in the main |
|
Got another one. This commit: This is the two commits (one push) that broke the build: |
|
@bmhm Did you try whether you run into the same problem with |
|
@wmdietl you can check out the current master branch yourself whenever you like. However, it does not work with java 8: |
|
Can you please try to reproduce this problem using the Java 8 compiler, version 211 or later? |
|
No, does not work.
@mernst I think we got a new error (no such method). Please be so kind and check out the project yourself and compile using: |
|
This issue is open for almost a year, is a critical blocker, and still exists in 2.9.0. :( // Edit: wanted to mention that there is a reproducible build error in comment #2173 (comment) |
|
We are planning to make a 3.0 release in August, which will build on the Java 9 compiler. |
|
@wmdietl PRETTY PLEASE test versions yourself if there is an easy setup. I mean, come on, this issue is rated "crash" and "critical", and you haven't even looked into it. The only thing you did is sit there and wait for those having problems to do YOUR work. I'd be happy to test it the next time you say "Works for me" or "here's a junit test which I think proves that this issues has been resolved". For the sake of progress, here's the new stack trace: Just to make sure you read it, here's a quote from above:
I really don't know what else to do. I supplied tons of information, yet you do not even dare to try the new version yourself on this issue. :( Sorry for ranting, but I do not have the feeling that you have any interest in working on this issue because you haven't even bothered to issue two commands (which are: |
|
I know that the eisop version works, because I tested the test case for this issue there: |
|
@wmdietl have you tried Java 8 compiler? |
|
Starting at version 3.0 the Checker Framework builds on a Java 9 javac. So there is no way in testing on a Java 8 compiler. If you want to stay on a Java 8 JVM, you can simply use the error-prone javac as a dependency: |
This really should be at the very top of the documentation, with a better example and the correct errorprone-javac version. |
At the top of what documentation? We will highlight this in the transition notes, but otherwise why would this be at the very top? What's wrong with that errorprone-javac version? |
|
The link you provided uses
To clarifiy: What the documentation should mentionThat said, the documentation should mention:
Really, this is not trivial. I sincerely hope you do agree that this setup should be mentioned prominently in the documentation. |
|
Sigh, this does not seem to work either. Trying with: <arg>-Xbootclasspath/p:${org.checkerframework:jdk8:jar}</arg>
<arg>
-Xbootclasspath/p:${settings.localRepository}/com/google/errorprone/javac/${errorprone.javac.version}/javac-${errorprone.javac.version}.jar
</arg>Checker yields I'm not using their JDK8. I think they must go in the same argument: <arg>-Xbootclasspath/p:${settings.localRepository}/com/google/errorprone/javac/${errorprone.javac.version}/javac-${errorprone.javac.version}.jar,${org.checkerframework:jdk8:jar}</arg>… but I still get this message:
Can you please help, @wmdietl ? |
|
Ok, just tried the errorprone-javac 9 to make sure it's not my fault. The following example will lead to:
<arg>-Xbootclasspath/p:${org.checkerframework:jdk8:jar}</arg>
<arg>-Xbootclasspath/p:${settings.localRepository}/com/google/errorprone/javac/${errorprone.javac.version}/javac-${errorprone.javac.version}.jar</arg>The following example will lead to checker not complaining, but the very same compilation error:
<arg>-Xbootclasspath/p:${settings.localRepository}/com/google/errorprone/javac/${errorprone.javac.version}/javac-${errorprone.javac.version}.jar</arg>
<arg>-Xbootclasspath/p:${org.checkerframework:jdk8:jar}</arg>That said, checker framework seems broken for Java 8. I get that it is the fault of the broken java 8 compiler, but nontheless, you are just posting ideas what may work, and sadly they don't seem to work for me (and others).
Not working, unless the example you showed me is doing something in the background I am not aware of :( Or maybe the warning "You do not seem to be using the distributed annotated JDK" is wrong with the first setup? |
|
@bmhm
Checker Framework version 3.x will continue supporting Java 8. If you continue to use Java 8, only change you have to make when switching to version 3.x is error-prone's javac for compilation. Also, @wmdietl suggested you try Checker Framework 3.0.0-b2(beta version) for which
This is not mentioned in documentation because Checker Framework 3.x is still in beta and will be in transition notes as pointed out by @wmdietl. Also, there is no problem with the version of error-prone javac as the example is compiling successfully using Java 8 and above.
The example referred by @wmdietl is compiling successfully using JDK 8 and above. The warning "You do not seem to be using the distributed annotated JDK" is issued if you don't use Since #2173 error is solved in Java 9 as shown in eisop#23 it will be solved when Checker Framework 3.x is ready for release and you use Java 9+. The problem right now is we don't have an annotated-JDK for Java 9+ which is needed for |
|
@the1derer thanks for the clarification. If I understand correctly:
Thanks for working on this. Sorry for adding a lot of comments on this issue, but I really cannot believe that I am the only user with this issue. In fact, I saw this issue on multiple projects I contribute to. |
The bug exists in 2.9.0 ( this version only supports Java 8) but using version 3.0.0-b2 with Java 9+ bug is not present.
No, you don't need to fiddle with errorprone. But you do need to make changes if/when you decide to use Checker Framework 3.x |
|
When you say this bug is not present, can you help me to set checker up in a java 8 project? I am still confused when to use errorprone. I am using JDK 8 and want to switch to checker 3.0.0-b2. I understand that in this case I need to add errorprone. I did this as seen in your example, but I still have the following dependency added: Anyway, when I pull in errorprone for maven-compiler-plugin, add the
Config posted a few time above.
Which bug in which configuration? I tried both java 8 with checker 2.9.0 and Java 8 with errorprone and checker 3.0.0 and have this bug. But let me ask you a question. This issue was opened when the 2.5-series was active, the 2.5.5 artifact of checker-qual was just released before this issue was opened. I wonder: do you plan to make a backport of this fix? 3.0.0 must have breaking changes according to the version. 4 minor versions and a whole year have passed. |
|
@wmdietl @the1derer Thanks for your updates. I updated zchunk-java according to your example. Please check out: https://github.com/zchunk/zchunk-java/tree/0bcc4320632d408b4493ef6a26927479a2e92ab1 It will run into the same issue. |
|
We decided that since malformed Java 8 bytecode might be on the classpath of a checker, the Checker Framework must ignore those annotations rather than crashing. This change will be in today's release, 2.10.0. |
|
Thank you sooooooo much!! Great! 😃 |
|
We are happy to help. Thanks for reporting the issue and trying fixes; we appreciate it. Please let us know of any other problems you encounter. We will help as best we can, given that we are not paid to maintain the project. |
|
@mernst I want to say sorry for all the fuzz in this thread to the whole team. The discussion was very confusing, and we often didn't understand correctly what the others were writing. We talked about different combinations of javac versions, checker versions, with or without errorprone, etc. which were really confusing at times. Turns out everything came out well for everyone I think -- which is a great achievement for a great library/tool! :-) … and yes, 2.10.0 works nicely so far! |
|
@bmhm Figuring out build problems is my least favorite part of the project. |
Bug report copied from message by William Shackleford https://groups.google.com/d/msg/checker-framework-dev/jrllYpfH1GQ/nTmnDJ1vAQAJ
I have a maven project that I have integrated checker-framework into that
has started failing with the message:
(The same message is repeated 10 times.)
Unfortunately I don't see where in my code the issue is and the project is too large to paste/attach to a bug report.
If someone has time they may be able to reproduce the problem by checking out and building the project with:
For me mvn -version produces:
In case I make changes in the future and you need to reproduce the problem
the current latest commit is 64cfb6dd871a106bb49360afdebd3e5e5de95d3c
The text was updated successfully, but these errors were encountered: