Future of 'type-annotations/type-annotations' forest

Thu May 8 19:54:56 UTC 2014

Alex, all,

thanks for this update.

Type annotations in the jdk9 repo are currently broken for serious
use. On Feb 7 I identified the invalid re-ordering performed in
ClassReader:

http://mail.openjdk.java.net/pipermail/type-annotations-dev/2014-February/001592.html

This problem still exists in jdk9 - the problematic changeset wasn't
rolled back, nor was the fix applied. I have fixed this problem in
type-annotations.
I was waiting to hear an update on this before pursuing the other
outstanding changes.

You say that after the new changes type-annotations will be seriously
out of date. I don't see why this would be the case. I'm currently
keeping type-annotations in sync with jdk9, making sure that the
Checker Framework correctly works with type-annotations. Once these
further refactorings go into jdk9, they should be easy to pull into
type-annotations.

I agree with the goal of retiring the type-annotations repositories,
but do not see any urgency from these upcoming refactorings. I would
rather have a working jdk9 before removing type-annotations.

As to the differences between the jdk9 and type-annotations repos:

- jdk9, jdk9/corba, jdk9/hotspot, jdk9/jaxp, jdk9/jaxws only differ in
the .hgtags file, were we marked when the type-annotations clones
split off.
- jdk9/jdk differs in .hgtags and contains two typo fixes in
  - java/lang/reflect/Field.java (whitespace fix about closing bracket)
  - java/lang/reflect/Modifier.java (spelling error)
- jdk9/nashorn doesn't differ at all

All the interesting changes are against jdk9/langtools:

- com/sun/tools/javac/code/TypeAnnotationPosition.java:
  I added a "copy" method to make it possible to create an updated
TAP. Alternatively, constructors that give a new TAP with a changed
location would be possible. A mechanism like this is required to allow
the Checker Framework to build TAPs for defaulted locations.

  One issue I run into is making the Checker Framework work with both
JDK 8 and JDK 9 - the APIs for things like TAP changed significantly
and I now need to access many things reflectively to correctly access
the right API. One simple change I made was to make field
"exception_index" public to allow direct access from JDK 8 and JDK 9.
As the upcoming changes will require further changes in the Checker
Framework, making this change is not necessary.

- com/sun/tools/javac/code/TypeAnnotations.java: initializes an
Options object that is unused. I removed that code.

- com/sun/tools/javac/comp/Check.java: the call to Assert.checkNonNull
always constructs a toString of an annotation - this was slow and
annoying when debugging some problems. Other uses of Assert also use
simple error messages, so I adapted this one.

- com/sun/tools/javac/jvm/ClassReader.java: the jdk 9 code incorrectly
reads the location of type annotations, which results in a compiler
crash. type-annotations fixed this.

- com/sun/tools/javac/model/JavacTypes.java: this change improves an
exception message. This message is only created when throwing an
exception, so the argument I have for the change to "Check" above
doesn't apply.

- com/sun/tools/javac/parser/Scanner.java: remove an unused import

- com/sun/tools/javac/util/RichDiagnosticFormatter.java: fix typo in javadoc

- All changes below javax, e.g.
javax/annotation/processing/Messager.java and
javax/lang/model/element/Element.java, remove unused imports only.

- test/tools/javac/annotations/typeAnnotations/classfile/T8008762.java:
fixes to whitespace

- test/tools/javac/annotations/typeAnnotations/failures/AnnotatedImport.java
is being ignored in jdk9, even though it is working. Same for
AnnotatedPackage1 and CantAnnotateStaticClass3.

- test/tools/javac/annotations/typeAnnotations/referenceinfos/Fields.java
and MethodReturns.java contain test cases for old-style arrays after
the identifier/method signature.

- test/tools/javac/lib/DPrinter.java uses an incorrect method and
doesn't work as is; fixed in type-annotations.

- test/tools/javac/processing/model/type/BasicAnnoTests.java uses
DPrinter and type-annotations makes the test compile - the problem
itself is still not fixed, but that is one of the improvements that
Eric was working on. Therefore, it would be good to enable this test
and see whether all problems are fixed now.

How should I go about getting these changes into jdk9/jdk and jdk9/langtools?
Is it enough to send the above descriptions to compiler-dev and point
interested reviewers to a diff between the two repos? Should I attach
a diff?

Cheers,
cu, WMD.

On Mon, May 5, 2014 at 6:58 PM, Alex Buckley <alex.buckley at oracle.com> wrote:
> Werner, all,
>
> Due to bug fixing and other cleanup for JDK 8u20 and JDK 9 [1], Oracle
> engineers have been working on patches to the implementation of type
> annotations [2][3][4]. The patches will be sent for review on compiler-dev
> soon. Once they go into the jdk8u/jdk8u forest or jdk9/dev forest, the
> type-annotations/type-annotations forest will be significantly out of date
> and should no longer be used for new contributions. As I indicated in
> January:
>
> --
> From now on, bug fixes to javac's handling of type annotations should be
> sent as patches to the compiler-dev list, just like fixes to any other area
> of javac. Depending on the nature of the bug in JBS, the patch would target
> either the repositories of the JDK 8 Updates Project or the repositories of
> the JDK 9 Project.
> --
>
> I looked at the type-annotation-dev archives and identified four threads
> that discuss changes in the type-annotations/type-annotations forest but
> which is intended for the jdk8u/jdk8u or jdk9/dev forests:
>
> - type-annotations based on JDK 9? (Jan 2014)
> - Webrev for making parts of TypeAnnotationPosition immutable (Feb 2014)
> - Invalid reordering in ClassReader (Feb 2014)
> - Changes in type-annotations repository (Mar 2014)
>
> It will not be straightforward to port these changes into jdk8u/jdk8u or
> jdk9/dev after the patches I mentioned at the start of this mail have been
> applied.
>
> Werner, I think it would be best if you mailed compiler-dev with a summary
> of your changes as soon as possible. Then, if they are still applicable,
> individual patches can be discussed and sponsored into the appropriate jdk*
> forest.
>
> Alex
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8027181
> [2] https://bugs.openjdk.java.net/browse/JDK-8040327
> [3] https://bugs.openjdk.java.net/browse/JDK-8027262
> [4] https://bugs.openjdk.java.net/browse/JDK-8027188

-- 
http://www.google.com/profiles/wdietl