javac pretty printer probable bugs

Rémi Forax forax at univ-mlv.fr
Sun Jan 29 08:45:51 PST 2012


On 01/29/2012 05:25 PM, Jonathan Gibbons wrote:
> Martin,
>
> The pretty printer is primarily a debugging aid, to accurately show 
> the contents of the syntax tree. To assist in that task, a more recent 
> development has been to try and make the output be compilable as well.
>
> The difficulty is that, despite first appearances, the AST is not a 
> direct, literal representation of the source text and some 
> transformations on the tree have already occurred by the time the 
> pretty printer gets invoked.
>
> The use of comments has been introduced as a way of showing the parts 
> of the AST which are present but which prevent compilation.   It would 
> seem you have found a couple of corner cases that need to be fixed.
>
> -- Jon

Jon,
how the pretty printer can represent "let" construct or bridge methods 
in Java ?

Rémi

>
>
> On 01/29/2012 06:07 AM, Crazy Java wrote:
>> 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 <mailto: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
>>
>>
>




More information about the compiler-dev mailing list