javac pretty printer probable bugs

[Crazy Java]

Good to know.


Yes, I was kind of misusing the pretty printer to get job done. But it
seems it will be straightforward for my needs to implement my own pretty
printer.


Thanks for responses,
Martin

2012/1/29 Jonathan Gibbons <jonathan.gibbons at oracle.com>

> **
> 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
>
>
>
> 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>
>
>>  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/67207dd7/attachment.html