The Former Weblog of Peter Ahé

I have been on vacation and not been able to keep up with the information about compiler fixes, so here is an update on the last few builds:

In JDK 6 b92-b96, these compiler (related) fixes were or will be included:

b92

6267067: (javac) Improve List.reverse for singletons
6341866: (JSR 269) Source files loaded from source path are not subject to annotation processing
6344074: (JSR 269) Messager.printNotice() writes to stderr, and documentation does not say where it should write.
6351336: (javac) com.sun.tools.javac.util.List shouldn't extend java.util.AbstractList
6389198: (javac) com.sun.tools.javac.util.List.equals() violates java.util.List.equals() contract
6392177: (JSR 269) JSR269: Support creating package-info.java files
6394683: (javac) need to resolve different file-type precedence semantics for javac and 269
6431930: (JSR 269) TypeElement.getQualifiedName should specify behavior on nested classes
6443693: (javac) tools/javac/Paths/Diagnostics.sh provokes bad error message

b95

6330997: (javac) Javac should accept future class file versions
6449798: (JSR 269) Update JSR 269 to pre Final Draft v0.81

b96

6399404: (JSR 269) jsr 269 Elements.getPackageElement("").getQualifiedName() works inproperly
6413876: (javac) REGRESSION javac -d /directory/ creates destination directories
6423972: (JSR 269) getBounds() returns the list with one TypeMirror representing java.lang.Object
6442883: (javac) Add warning similar to JSR 269 visitor warnings
6449122: (javac) javac process is failing on Mustang integration compile
6453386: (JSR 269) Update JSR 269 to Proposed Final Draft v0.83
6453971: (javac) javadoc bug in StandardJavaFileManager

Thanks to Joe, Jon, Scott, and Wei.

Let me go through the highlights.

Jon cleaned up the linked list implementation in javac reducing the memory footprint and made it conform to java.util.List specification.

Wei added a feature that allows the compiler in JDK 6 to accept class files generated by the next version (JDK 7). Although the class file format is not yet defined, it turns out that the compiler should be able to read future class files as long as we do not add any new constant pool tags (the compiler doesn't read byte codes). Since we haven't added constant pool tags in years and generally work hard to keep class file format changes backwards compatible, the compiler should have no problem reading future class file versions. Such class files may contain features that the compiler does not understand and it will cause a warning. This is no different from when your PDF reader warns about new file versions may contain feature it does not know how to display properly.

You may ask: what's the point? and that is a valid question. After we shipped JDK 5.0, we noticed that a lot of customers had a hard time getting their JSP servers running on the new release. This was because we had changed the class file version used in rt.jar (I mentioned this in my b83 write-up).

Finally, I completed the symbol file feature I mentioned in my b86 write-up. The compiler will now emit a warning if you, for example, access members of the package sun.io. This warning cannot be suppressed, you are really not supposed to use them