Closed GoogleCodeExporter closed 9 years ago
Original comment by michael.ernst@gmail.com
on 15 Apr 2014 at 6:45
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
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
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
Thanks, makes sense
Original comment by trask.st...@gmail.com
on 1 Jun 2014 at 5:49
Original comment by jtha...@cs.washington.edu
on 3 Jun 2014 at 12:47
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
Original issue reported on code.google.com by
trask.st...@gmail.com
on 8 Apr 2014 at 7:26Attachments: