Checker not working on Java 7 about maven-hello-world

[mernst]

@pdurbin The current Checker Framework release (version 1.9.8) includes new Maven instructions that are supposed to work with both Java 7 and Java 8 (though you do have to edit your Maven build file to switch between Java 7 and Java 8). Can you check whether they work for you and this issue can be closed?
Thanks!

[pdurbin]

I'm not quite ready to move different project from Java 7 to Java 8 so I enabled Checker in a branch for now: pdurbin/addressbookmvc@0839841

[renatoathaydes]

I had a look and it seems to me the jdk7 Maven artifact was compiled with Java 8, therefore it won't work if you compile your project with Java 7.

The error I got here was this:

[ERROR] error: InvocationTargetException when invoking constructor for class
 org.checkerframework.checker.nullness.KeyForVisitor; Underlying cause: 
InvocationTargetException when invoking constructor for class
 org.checkerframework.checker.nullness.KeyForAnnotatedTypeFactory; 

Underlying cause: com.sun.tools.javac.code.Symbol$CompletionFailure: 
class file for java.util.TimeZone$DisplayNames not found; 
invoke the compiler with -AprintErrorStack to see the stack trace.

Could you guys please make sure you compile the jdk7 jar with a Java 7 compiler?

[renatoathaydes]

Sorry, it seems it was ME who was using Java 8's javac :(

Anyway, I got to try to compile the code using javac rather than Maven and got the root error:

An annotation processor threw an uncaught exception.
Consult the following stack trace for details.
java.lang.NoSuchMethodError: com.sun.source.util.JavacTask.instance(Ljavax/annotation/processing/ProcessingEnvironment;)Lcom/sun/source/util/JavacTask;
    at org.checkerframework.javacutil.AbstractTypeProcessor.init(AbstractTypeProcessor.java:119)
    at org.checkerframework.framework.source.SourceChecker.init(SourceChecker.java:393)
    at com.sun.tools.javac.processing.JavacProcessingEnvironment$ProcessorState.<init>(JavacProcessingEnvironment.java:517)
    at com.sun.tools.javac.processing.JavacProcessingEnvironment$DiscoveredProcessors$ProcessorStateIterator.next(JavacProcessingEnvironment.java:614)
    at com.sun.tools.javac.processing.JavacProcessingEnvironment.discoverAndRunProcs(JavacProcessingEnvironment.java:707)
    at com.sun.tools.javac.processing.JavacProcessingEnvironment.access$1700(JavacProcessingEnvironment.java:97)
    at com.sun.tools.javac.processing.JavacProcessingEnvironment$Round.run(JavacProcessingEnvironment.java:1029)
    at com.sun.tools.javac.processing.JavacProcessingEnvironment.doProcessing(JavacProcessingEnvironment.java:1163)
    at com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler.java:1108)
    at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:824)
    at com.sun.tools.javac.main.Main.compile(Main.java:439)
    at com.sun.tools.javac.main.Main.compile(Main.java:353)
    at com.sun.tools.javac.main.Main.compile(Main.java:342)
    at com.sun.tools.javac.main.Main.compile(Main.java:333)
    at com.sun.tools.javac.Main.compile(Main.java:76)
    at com.sun.tools.javac.Main.main(Main.java:61)

Clearly, the error is at AbstractTypeProcessor.java:119. It's trying to use some method that does not exist in the Oracle VM (as of version 1.7.0_80).

[renatoathaydes]

Here's the culprit:

https://github.com/typetools/checker-framework/blob/master/javacutil/src/org/checkerframework/javacutil/AbstractTypeProcessor.java#L119

The method does exist in OpenJDK 8's code:

http://www.grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8u40-b25/com/sun/source/util/JavacTask.java#JavacTask.instance%28javax.annotation.processing.ProcessingEnvironment%29

But not in Java 7:

http://www.grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/7u40-b43/com/sun/source/util/JavacTask.java#JavacTask

I confirmed with IntelliJ that Oracle's source also does not contain this method in Java 7.

This is therefore a bug in the Checker Framework. Please submit a bug with them.

[renatoathaydes]

My whole session, just in case you find it hard to reproduce:

renato@renato ~/programming/java/checker-maven-demo $ javac -version
javac 1.7.0_80
renato@renato ~/programming/java/checker-maven-demo $ javac -classpath /home/renato/programming/java/checker-maven-demo/target/classes:/home/renato/.m2/repository/org/checkerframework/checker/1.9.3/checker-1.9.3.jar:/home/renato/.m2/repository/org/checkerframework/checker-qual/1.9.3/checker-qual-1.9.3.jar:/home/renato/.m2/repository/org/checkerframework/jdk7/1.9.3/jdk7-1.9.3.jar: -sourcepath /home/renato/programming/java/checker-maven-demo/src/main/java:/home/renato/programming/java/checker-maven-demo/target/generated-sources/annotations: /home/renato/programming/java/checker-maven-demo/src/main/java/com/athaydes/checkerframework/NullnessExample.java -s /home/renato/programming/java/checker-maven-demo/target/generated-sources/annotations -processor org.checkerframework.checker.nullness.NullnessChecker -g -target 1.7 -source 1.7 -Xbootclasspath/p:/home/renato/.m2/repository/org/checkerframework/jdk7/1.9.3/jdk7-1.9.3.jar

[pdurbin]

@renatoathaydes good sleuthing. For now I left a comment for @wmdietl typetools/checker-framework@1737b00#commitcomment-12843853

This how I'm able to reproduce the bug... by compiling the application with the javac from Java 7: JAVA_HOME=/usr/lib/jvm/java-7-openjdk-amd64 mvn package

I just pushed a branch to test from (uses Java 7 instead of Java 8): https://github.com/pdurbin/maven-hello-world/commits/java7checker

[wmdietl]

Hi Philip, Renato,
I added a comment to your question:

typetools/checker-framework@1737b00#commitcomment-12844274

You should be able to use a Java 7 JVM, but you will need to use a Java 8 javac, either jsr308-langtools or the OpenJDK 8 javac.
cu, WMD.

[pdurbin]

@wmdietl thanks! It would probably be much more straightforward for your potential users to tell them that they must use Java 8. I find "Requirement: You must have JDK 7 or later installed" at http://types.cs.washington.edu/checker-framework/current/checker-framework-manual.html#installation a little misleading. Here's the line in question:

https://github.com/typetools/checker-framework/blob/checker-framework-1.9.3/checker/manual/introduction.tex#L197

I believe you that jsr308-langtools (whatever that is) helps Checker work with Java 7 but if I'd humbly suggest changing the line above to suggest that new users start with Java 8 since Java 7 is EOL these days anyway.

[wmdietl]

There are still many of our users that depend on Java 7. If you follow the instructions you cite, you can successfully and without hassle use the Checker Framework with Java 7.
jsr308-langtools is distributed with the Checker Framework release and used by all distributed scripts.
If you want to not use jsr308-langtools you need to change your configuration and use a Java 8 javac instead.

[pdurbin]

@wmdietl already the section about Maven indicates that Java 8 should be used. Or at least it suggests it with 1.8 specified for the maven-compiler-plugin: http://types.cs.washington.edu/checker-framework/current/checker-framework-manual.html#maven . The Maven section doesn't say anything about Java 7 or jsr308-langtools (though the Ant section mentions "Set the jsr308javac property".)

Anyway, it seems like a hassle to use Checker with Java 7 and Maven. That's fine. We should all be upgrading to Java 8 anyway! :)

[renatoathaydes]

Using the Checker Framework as it stands is a hassle with Java 7 or Java 8, which explains why it is not being widely used (can't find any blog posts, questions about it on StackOverflow etc.). It's a pitty.

To succeed, Checker should be and behave just like an annotation processor which does some static checks at compile-time, and that's what I was trying to use it as (and succeeded for the most part, but it was a hassle for sure). I will not use some unknown, slow compiler on my code. I want the nullness checks to be optional. We have lots of legacy modules which we will not use nullness checks on. I don't want to manually download and install what is basically a Java library as in pre-Maven times. And most people won't do that either, I'd think. Because that shouldn't be necessary.

A little more focus on convenience would go a long way.

[wmdietl]

@pdurbin @renatoathaydes @mernst @JonathanBurke
I'm sorry to hear that you're running into such troubles using the Checker Framework.

The Checker Framework is an annotation processor and using it as such is possible. We provide scripts to make usage as convenient as possible, for the users we hear from.
If you have concrete suggestions for what can be improved - either in documentation, scripts, or examples, do let us know.

jsr308-langtools is a clone of Java 8u javac - it is not "some unknown, slow compiler". The slowdown is purely due to the checks the Checker Framework performs as an annotation processor. The reason to have jsr308-langtools is to support our existing users that require Java 7 compatibility - by providing support for the new type annotation syntax in comments.

The nullness checks are completely optional. Can you elaborate why you think they are not?

[pdurbin]

No trouble with Java 8 and Maven! Checker is great! I've been trying to explain it to people: http://irclog.greptilian.com/sourcefu/2015-08-31#i_135262 :)

[mernst]

Cool, I'm glad it is working for you. Lots of folks report similar success.

I'm hoping that Renato can explain how he came about his mistaken beliefs, so that we can improve the documentation and so that he can be successful too. Thanks in advance, Renato, for helping us help you.

[renatoathaydes]

Well, I created the project which makes Maven and Java8 work well together (this is a fork of that). The guide in the current documentation tells me I have to download Checker, when that really shouldn't be the case, and I have an open PR which changes the guide to make it easier (though not easy still) for people.

My beliefs are not mistaken in any way, it is a hassle to use Checker. My colleagues think I'm crazy for even trying. IF you don't see that, then you seem to be the one with mistaken beliefs.

Using an annotation processor should consist of:

• add the dependencies in the pom
• add the instruction adding the annotation processor in the compiler configuration

My PR almost achieves that... we still need to go through hoops to get the annotated JDK's path given to the compiler (which is more a fault of Maven than Checker, admittedly)

If you want to help me, merge my PR, fix the problems you guys raised with it (really minor ones but I've been too busy lately) and try to make it even easier by not requiring the annotated JDK path (I've already suggested in another thread you should use stubs instead, but I was dismissed), please.

EDIT

I've been trying to help you make your project attractive to professional developers who would otherwise just ignore your project as soon as they see how it relies on installation of local files and relative paths to find things to be used. Any non-academic/non-single-person project will have a build that runs on dozens of machines where you can't just install things that are not part of the toolchain and use relative paths to connect them. If you, like me, think the Checker Framework can be useful for professionals, and is not just an academic exercise, try to accept my criticism constructively. I don't need help with anything, I have everything I need working beautifully, as always :) I don't benefit in any way by pointing out issues I see with Checker and solutions to try to make it better. But I do so anyway because I believe it's worth it in this case. If you think what you're doing is perfect and anyone criticising obviously has mistaken beliefs, then good luck with that attitude, but I hope that's not the case.

[pdurbin]

I do hope that @mernst and @wmdietl appreciate where @renatoathaydes is coming from. I really appreciate the work he's done in typetools/checker-framework#461 and https://github.com/renatoathaydes/checker-maven-demo . It has inspired me to play with Checker more. Perhaps some day I'll try to introduce it to my team.

@mernst maybe you can elaborate on what you mean by "mistaken beliefs."

[mernst]

Renato, we do appreciate all your help and the effort you have put in. I've said it before and I will say it again: Thanks!

I completely accept that the Maven integration must be improved because it is currently a hassle to use. We appreciate your help with it. As you point out, some of the problems are due to Maven itself, some due to our requirement to support Java 7, and some due to the current poor status of our existing Maven support.

I agree that in principle all Java users ought to move to Java 8, but we have many commercial users who are stuck on Java 7 and any solution needs to work for them too. That's why we cannot accept a solution that only works for Java 8. Our roadmap has us requiring Java 8 in April 2016.

The beliefs I was referring to were "I will not use some unknown, slow compiler on my code. I want the nullness checks to be optional." Werner specifically asked about both of these, but I didn't see an answer to his questions. For example, could you tell us why you believe the nullness checks are not optional, so that we can improve the documentation?

Thanks again for your help.

[pdurbin]

@mernst thanks for your kind words about @renatoathaydes and clarifying which questions are unanswered.