javac pretty printer probable bugs

Crazy Java crazyjavahacking at gmail.com
Sun Jan 29 06:07:49 PST 2012


It looks like the Enum problem should alreadz be fixed according to bug
6902720 (http://hg.openjdk.java.net/jdk7/tl/langtools/rev/b1bb8164a9bd,
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6902720), but it is not.

2012/1/29 Rémi Forax <forax at univ-mlv.fr>

> On 01/29/2012 01:40 PM, Crazy Java wrote:
>
>> Hi,
>> as part of the javac AST Visualizer project, I have some difficulties
>> with javac's pretty printer. The problem is the fact, that I am doing
>> double compilation (after first compilation I get the textual
>> representation of produced AST and that is in fact used for visualization
>> purposes). Double compilation is needed because I want to visualize all the
>> compiler sugar (default constructor, effectively final variables in ARM,
>> code generated for enum, ...).
>> The problem is that javac's pretty printer (I guess it is pretty printer)
>> after calling CompilationUnitTree.toString() produces in some specific
>> situations code that is not able to compile:
>> 1.) it transforms
>> public class FullClassUsage {
>>    {
>>        new <Object> ArrayList<String>(10) {
>>            {
>>                add("123");
>>            }
>>        };
>>    }
>> }
>> into
>> public class FullClassUsage {
>>
>>    public FullClassUsage() {
>>        super();
>>    }
>>    {
>>        new <Object>ArrayList<String>(10){
>>
>>            (int x0) {
>>                super(x0);
>>            }
>>            {
>>                add("123");
>>            }
>>        };
>>    }
>> }
>> the (int x0) is the problem.
>> 2.) when using together with enum types it transforms:
>> public enum SimpleEnum {
>>    ENUM_CONSTANT_1,
>>    ENUM_CONSTANT_2
>> }
>> into
>> public enum SimpleEnum {
>>    /*public static final*/ ENUM_CONSTANT_1 /* = new SimpleEnum() */,
>>    /*public static final*/ ENUM_CONSTANT_2 /* = new SimpleEnum() */;
>>
>>    private SimpleEnum() {
>>        super();
>>    }
>> }
>> that is really weird. Not only it generates comments ??? but also a super
>> call causing the code not to compile. I would also assume that it will
>> generate all the enum type code (constructors with n+2 arguments, valueOf()
>> factory method, extending java.lang.Enum, ...).
>> Is there any reason why it produces that weird code?
>>
>
> Java language != bytecode,
> at the end javac will generate bytecodes and there are a lot of things
> that are allowed
> in bytecode that are not allowed in Java.
>
> The pretty printer is something used to debug and not something that will
> generate fully compatible Java code
> because some de-sugared code are only valid in bytecode but not in Java.
>
>
>  Is there any better way to get the Textual representation of
>> CompilationUnitTree (using pretty printer) that will compile in both of
>> these examples ?
>>
>
> write your own :)
>
>  //Martin
>>
>
> Rémi
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20120129/387e7031/attachment.html 


More information about the compiler-dev mailing list