Search

Categories

Links

Referers

b85 compiler fixes

May 08 2006, 11:01:04 PM PDT »Java»Compiler Comments [8]
In Mustang b85, these compiler (related) fixes will be included:

6276307: (javac) javac consumes too much memory generating stackmap in extreme cases
6308351: (javac) Apt causes NullPointerException running on a Simplified Chinese test case
6346251: (JSR 269) JSR269 should provide a method to get the binary name for an element
6356636: (javac) Compiler fails to read signatures of inner classes with non-generic outer instance leading to crash
6382700: (javac) Default compile policy in javac causes footprint issues
6384510: (javac) improper handling of wildcard captures
6397652: (javac) REGRESSION: javac compilation failure when imported class with $ sign in the name
6400872: (javac) REGRESSION: Java Compiler cannot find jar files referenced by other
6405099: (javac) Compiler crashes when javac encounters /usr/jdk/packges/lib/ext with no 777 permissions
6408241: (JSR 269) Elements.getTypeElement(String s) does not return null for non-existing classes
6409829: (javac) JSR 199: enforce the use of valid package and class names in get{Java,}FileFor{Input,Output}
6410643: (javac) JSR 199: The method JavaCompilerTool.run fails to handle null arguments
6411073: (javac) JSR 199: questions not answered by the specification
6411310: (javac) JSR 199: FileObject should support user-friendly names via getName()
6411312: (javac) JSR 199: ForwardingFileManager should be generic, by analogy with ForwardingFileObject
6411379: (javac) NPE from JavacTrees.getPath
6412308: (javac) JSR 199: javax.tools.JavaFileManager.getFileForOutput: spec is the same as for getFileForInput
6412656: (javac) JSR 199: pass annotation processor instances to compiler
6413452: (javac) DefaultFileManager may throw "could not create parent directories" in concurrent execution
6413633: (javac) JSR 199: file manager requirements
6415780: (javac) JSR 199: javax.tools.JavaFileManager.getClassLoader always fails
6417282: (javac) JSR 199: default is not system
6418694: (javac) JSR 199: JavaFileManager.hasLocation(Location)
6419915: (javac) FindBugs: 419 "bugs" in javac
6419935: (javac) JSR 199: Forwarding{FileObject,JavaFileManager}.equals() functionality isn't specified
6420409: (javac) JSR 199: StandardFileManager: cannot set CLASS_PATH location
6420464: (javac) JSR 199: JavaFileObject.isNameCompatible throws unspecified exception (IllegalArgumentException)

Thanks to Joe, Jon, Scott, and Wei.

I mentioned that Joe managed to sneak in a few extra fixes in b83:

5009037: (JSR 269) document differences between source and class file views of a declaration
6376102: (JSR 269) Update JSR 269 to Public Review Draft v0.67
6401101: (JSR 269) SourceVersion must fully specify the platform version

Also, I previously mentioned the change from -target 5 to -target 6: I have just verified that the change is in our workspace, hopefully it will stay fixed this time ;-)

Wei brought down the memory consumption of javac when generating stack maps (-target 6). Also worth mentioning to those that prefer to stick with Tiger: Nishant has ported my cast fixes to 5.0u8. Finally, I'm happy to report that I got the wildcard bug nailed this time.

Post a Comment:
Comments are closed for this entry.
Comments:

I hope it's ok to ask here, but what is the status of compiler bug 4689050? Will it ever be fixed, is it not important enough, are people afraid a fix will break code relying on the bug?

Posted by Bas de Bakker on May 09, 2006 at 12:08 AM PDT #

4689050 is not a compiler bug. I'm not up to speed on this issue. Apparently we couldn't change the compiler so we may have to update the specification. I think this is why we have a specification bug.

Posted by Peter von der Ahe on May 09, 2006 at 12:34 AM PDT #

Hi Peter, I have found a small bug in the compiler. When you create a class with a method, which has more than 52092 parameters, you will get StackOverflowError. Here is the output on my Windows box (Mustang b82):

The system is out of resources.
Consult the following stack trace for details.
java.lang.StackOverflowError
at com.sun.tools.javac.code.Type.map(Type.java:117)


To create a class with such method you can use the following program:

import java.io.*;

/**
* @author Andrej Golovnin
* @version 1.0
*/
public class T65365 {

private static final int NUMBER_OF_PARAMETERS = 52093;

public static void main(String[] argv) throws IOException {
PrintWriter out = new PrintWriter("Bug" + NUMBER_OF_PARAMETERS + ".java");
out.println("public class Bug" + NUMBER_OF_PARAMETERS + " {\n");
out.println(" public static void tooManyParameters(");
for (int i = 0; i < NUMBER_OF_PARAMETERS;) {
out.printf(" int i%1$05d, int i%2$05d, int i%3$05d, int i%4$05d", i++, i++, i++, i++);
out.print(i < NUMBER_OF_PARAMETERS ? ",\n" : ")\n");
}
out.println(" { System.out.println(\"You will never see this message!\"); }");
out.println();
out.println("}\n");
out.close();
}

}


This bug is not very important, so don't invest to much time.

Posted by Andrej Golovnin on May 09, 2006 at 12:58 AM PDT #

I'm not even sure this is a bug ;-)

However, you should file a bug report as the compiler suggests.

Posted by Peter von der Ahe on May 09, 2006 at 01:42 AM PDT #

Hi, Do you have any idea when 1.5.0_07 or _08 are due to be released? Not your area (!) but I'm crossing my fingers that a couple of ugly CMS GC bugs (by my unfounded deduction) in _06 have been fixed that cause SIGBUS in the VM, and I can't see any _07+ release info anywhere! BTW, looking forward to giving Mustang a whirl with ProGuard and pack200 and JWS "Real Soon Now" to see just how small my "useful" JWS apps get, eg my 3D viewer (gallery.hd.org/3D) only needs ~40kB of pack.gz; I am hoping that the new class-file format will knock off a chunk more! Rgds Damon

Posted by Damon Hart-Davis on May 09, 2006 at 03:52 AM PDT #

I'm not really familiar with the schedules for 5.0u7 or 5.0u8 (too busy focusing on Mustang and JavaOne). If you have a the ID of the GC bug, you should be able to see if it is targeted for a 5.0 update release.

Regarding class file format: the new class file format (version 50/-target 6) will not help bring the download size down compared to version 49/-target 5.

Posted by Peter von der Ahe on May 09, 2006 at 04:40 AM PDT #

Oooh looks like I gotta grab me build 85! Keep up the great work guys!

Posted by Surya on May 09, 2006 at 10:20 AM PDT #

Great work !!

Posted by Herve Girod on May 10, 2006 at 12:03 PM PDT #

Java is a trademark of Sun Microsystems, Inc.
Copyright © 2006,2007 Peter von der Ahé