6393408: (javac) javac uses a poor hashing algorithm for names
6400383: (javac) directory foo.java on javac command line causes javac to crash
6404756: (javac) javac mishandles deprecation warnings on some elements marked deprecated
6410706: (javac) CONFORMANCE Mandatory warnings in Tree API
6412669: (javac) should be able to get SourcePositions from 269 world
6413576: (javac) Fix javadoc warnings in public source files
6414633: (javac) JSR 269: Only the first processor message at a source location is reported
6423583: (javac) LiteralTree.getValue() should return Boolean for Kind.BOOLEAN_LITERAL literals.
6424358: (javac) Synthesized static enum method values() is final
6429213: (javac) AnnotationTree JLS reference is wrong
6429613: (javac) tools/javac/Paths/Diagnostics.sh fails: bad files in extdirs doesn't cause an error
6431435: (javac) Tree API: source files loaded implicitly from source path
6431879: (javac) TreePathScanner.scan(CompilationUnitTree tree, P p) overloading forces use of most specific type
6433651: (javac) Document Tree API in Mustang
6439406: (javac) test tools/javac/api/6431435/T6431435.java fails because of issues with "empty" packages
Thanks to Jon, Tim, and java.net contributor "tackline". I have been working on getting JSR 199 ready for Public Review and it was posted yesterday on jcp.org. At the same time, the Public Review Ballot of JSR 269 was approved.
UPDATE: I got this list wrong yesterday. Normally, Tim integrate everything we have included in our group workspace before every other Monday at 10pm into the Master workspace on the following Friday. The time between Monday and Friday is used for testing to ensure that the Master remains good. Although the Master is never supposed to be broken, something fell through the cracks and Tim had to restart the testing and integrate on a later date. So there are more fixes in b89 than I expected (also, I had included old fixes in the list).
Tackline noticed that the hashing algorithm used on javac's internal name table leads to poor bucket distribution. In degenerate cases, this causes severe performance penalties but tackline proposed to use the same hashing algorithm used in java.lang.String. Actually, the hash code algorithm used in the compiler is from an older version of java.lang.String. Jon demonstrated that not only did the change improve the distribution when compiling the JDK it also reduced compile time by roughly 2%.
Looks likes "it's all growed up now" [ObKateBushQuote]! Good news.
BTW, I meant to ask you at an earlier point... There were rumours that static optimisers/obfuscators such as ProGuard make some code run *slower* with HotSpot as the transformations, whilest correct and apparently beneficial, confuse the (heuristuc) analysis done at JVM run-time which is tested to work well with the output of javac as-is.
And indeed, does HotSpot work "best" with javac-produced code (eg vs Jikes or EDT)? (Remember all that fuss years ago when javac avoided producing code that tickled a bug in the JVM and caused a crash, whereas Jikes produced the code and got blamed.)
Rgds
Damon
Posted by Damon Hart-Davis on June 21, 2006 at 05:24 AM PDT #