The Former Weblog of Peter Ahé

6362178: (JSR 269) APT creates MirroredTypeException eagerly, causing error for Class value() return type.
6391995: (javac) REGRESSION: removal of "rvalue conversion" causes problems
6392998: (javac) REGRESSION/CONFORMANCE: Mustang compiler throws AssertionError (beta2-b71 and higher)
6393539: (javac) CONFORMANCE: no compiler error if method in annotation type is override-equivalent to clone(), etc.
6397934: (javac) tools/javac/T6351767.java fails to get NPE
6399361: (javac) CONFORMANCE: @Override specification and compiler inconsistent
6403459: (javac) JavacProcessingEnvironment should know if parser errors occurred
6403468: (JSR 269) processors raising errors doesn't result in nonzero exit code
6420668: (JSR 269) AbstractProcessor should check initialization status before running methods
6425544: (javac) REGRESSION: NPE in com.sun.tools.javac.util.DefaultFileManager.java:272

Thanks to Brad, Joe, Jon, Scott, Tim, and Wei.

The build cycle is normally a week. However, due to JavaOne, build 85 (b85) was two weeks. Normally, my team only integrates on odd numbered builds but we made an exception with b86 to get more stuff included in beta 2.

Let me provide some details on the noteworthy changes. Joe has fixed a lot of problems with error handling during annotation processing in the compiler. For example, printing an error message will now result in a non-zero exit code from the compiler. Previously, there were situations where that might not happen. At the same time, he ensured that parser errors are fatal (no amount of annotation processing will fix a parser error). This should ease the job of enforcing extralinguistic constraints when using processors as compiler extensions.

As I described before JavaOne, there are some problems with @Override. These have been fixed by revising the specification and the compiler. You can now use @Override in more places.

Finally, I would like to mention that we have made a great improvement for cross-platform compatibility. Previously, all packages in rt.jar are visible at compile time. However, many of the packages in that file are Sun proprietary unsupported implementation details. Some come to mistakenly rely on this which can cause problems when upgrading from one version of Sun's JDK to another (as we don't make any guarantees). Also, it can cause problems when running on other vendors' platforms as they might not have these classes.

To address this problem, undocumented packages (that are new in Mustang) will not be visible at compile time. For example, while the package sun.reflect.misc is in rt.jar, javac will not be able to see it. Later we hope to emit warnings for packages that are undocumented but visible because of legacy from older releases. For example, the package sun.io will remain visible but use of it may lead to a warning.

To hide these packages, javac will not be reading rt.jar anymore. Instead it will read a symbol file (in some unsupported unspecified format: we are planning on adding a real module system in Dolphin). This symbol file idea was pioneered by Tom Ball to speed up compilation (and save memory). However, while this helps in scenarios like app servers, Jackpot, and NetBeans, it may not do much for regular batch compilations. Once we have done some profiling of the file manager in javac, I hope it will be much faster than the Tiger version.