Additional JDK Nullable annotations

[GoogleCodeExporter]

Attached are the additional @Nullable annotations I have needed in JDK classes 
(ClassLoader, Thread, ClassFileTransformer, Socket, DatabaseMetaData, 
PreparedStatement, Enumeration).  The stub file works great, there is no issue 
here, just wanted to pass these along in case they make sense to add to the 
annotated jdk that ships with checker-framework.

Original issue reported on code.google.com by trask.st...@gmail.com on 8 Apr 2014 at 7:26

Attachments:

• jdk.astub

[GoogleCodeExporter]

Original comment by michael.ernst@gmail.com on 15 Apr 2014 at 6:45

[GoogleCodeExporter]

Thanks for the additional annotations.  I have incorporated them (along with 
other additional library annotations) into the Checker Framework's distributed 
JDK; see this changeset:
https://code.google.com/p/checker-framework/source/detail?r=c9a023cdfadf4312cd90
8cec95d78d6b3bb3c14a

I made a few changes to your proposed annotations, based on the available 
documentation.

In one case this was because your annotation seemed too strict.  In method 
ClassFileTransformer.transform, I made classBeingRedefined nullable whereas you 
required it to be non-null.

In other cases, it was because your annotations seemed too lenient.
In ClassLoader.definePackage, I left implVendor as non-null.
In ClassFileTransformer.transform, I left protectionDomain as non-null.
In DatabaseMetaData.getPrimaryKeys and DatabaseMetaData.getIndexInfo, I left 
table as non-null
In PreparedStatement.setString and setObject, I left x as non-null.

Finally, in Enumeration, you seemed to be annotating an old, non-parameterized 
version of the class; I retained the JDK version that has a type parameter and 
is more precise than the annotation you proposed.

For all of the above cases, I worked from Oracle's documentation.
If I missed something and any of the annotations needs to be changed, please 
let me know.

And, please continue providing library annotations, which will help all users.  
Thanks again!

Original comment by michael.ernst@gmail.com on 26 May 2014 at 8:29

• Changed state: Pushed

[GoogleCodeExporter]

In ClassLoader.definePackage, it seems ok to pass null implVendor. It's hard to 
find any documentation on this. The best I can offer is that there are a lot of 
github projects (including mine) that pass null implVendor: 
https://github.com/search?p=2&q=definePackage+packageName+null&ref=searchresults
&type=Code

In ClassFileTransformer.transform, null protectionDomain is passed in when 
transforming jdk classes. Again, no doc that I could find explains this, but I 
created a small example to demonstrate: 
https://gist.github.com/trask/d47133aef3b662b6548b

In PreparedStatement.setString and setObject, it seems ok to pass null x. I 
actually found supporting doc for this one, see JDBC 4.1 Spec 13.2.2.4 "If a 
Java null is passed to any of the setter methods that take a Java object, the 
parameter will be set to JDBC NULL".

Original comment by trask.st...@gmail.com on 27 May 2014 at 7:07

[GoogleCodeExporter]

Trask-

Thanks for the documentation about PreparedStatement.setString and setObject.  
I have put @Nullable annotations on them.  (We are in code freeze, so I cannot 
push that to the repository until after the June 2 release.)

For the other two, I am quite reluctant to add annotations based on what 
happens to work today rather than on a specification.  If the JDK 
implementation changes in the future, then the annotations may be incorrect.  I 
have contacted engineers at Oracle in an attempt to get the behavior 
documented.  When they respond, I am happy to update the Checker Framework's 
library annotations.

Original comment by michael.ernst@gmail.com on 1 Jun 2014 at 2:20

[GoogleCodeExporter]

Thanks, makes sense

Original comment by trask.st...@gmail.com on 1 Jun 2014 at 5:49

[GoogleCodeExporter]

Original comment by jtha...@cs.washington.edu on 3 Jun 2014 at 12:47

• Changed state: Fixed

[GoogleCodeExporter]

Hi Michael,

Another possibly implementation specific behavior I've noticed with 
ClassFileTransformer.transform() is that the JVM passes null className when 
MethodHandles are constructed.

See example at https://gist.github.com/trask/bee81e153cf17e1e945a

Even if this is implementation specific behavior, doesn't it seem safer to mark 
the questionable ClassFileTransformer.transform() parameters as @Nullable since 
this is a method you implement, as opposed to a method you call?

Thanks, Trask

Original comment by trask.st...@gmail.com on 13 Jun 2014 at 8:13