groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jochen Theodorou <>
Subject Re: About the Phoenix plan for Groovy
Date Sun, 08 Apr 2018 09:33:21 GMT
On 08.04.2018 03:58, Daniel Sun wrote:
> Hi all,
>        I have a plan named "Phoenix" to share. As we all know, STC is buggy,
> one of reasons is that STC lacks tests during development. So I make a plan
> to let STC mature enough:
> 1) Make the Parrot parser be able to parse pure Java source to Groovy AST;
> 2) Use STC to analyze the AST and generate the bytecode;
> 3) Run the existing tests of some famous Java projects, e.g. Spring,
> Hibernate, Guava, Hadoop, etc. ;
> 4) Check the test result. If all tests pass, our Phoenix plan is completed.
>      Another benefit of the plan is that we will have a brand new joint
> compiler, no stub generation is required :-)
>      Any thoughts?

basically a good idea.

Though flow typing will cause the bytecode to differ. Very simple example

class X {
   private int y
   int foo(){return 1}
   boolean test(Z z) {
     X x = z;
     return y == x.y && foo() ==
class Z extends X {
   int foo(){return 2}

In Java you can do this, in static Groovy the compiler may assign the 
type Z to x, thus y is not accessible.... Can be fixed of course. Next 
is that the compiler may generate a call to Z#foo instead of X#foo. And 
while in this example it arguable could be changed, once Z defines a 
more specific method, than X, that method is to be taken.

To me this means: to be able to compile like Java, you have to be able 
to turn flow typing off.

And then there is the question of when things are equal. You really want 
to go with bit-by-bit equality? What about the "implement GroovyObject" 
for example? And then we do a lot of storing results in local variables, 
that then are not used. And a lot of other quirks here and there.

And the Java compiler changes too. For example in
   () -> {
     println 1

the Java compiler does not create line number information for the second 
line, which already caused my some puzzling moment when debugging code. 
Recently there was a suggestion to change this. Just to illustrate that 
the bytecode will depend on the Java compiler version and there will be 
changes even in minor versions.

If you do not go by an automated version, you can obviously not just 
feed it a huge amount of Java code and compare. Reducing the bytecode 
test to the method calls and variable types may already do the trick, 
but the bytecode does not contain that much generics information itself.

I would include the OpenJDK in there, especially the tests for generics. 
And especially the tests for things that are supposed to *not* compile. 
Of course in those cases you cannot just compare the bytecode (as there 
is none)

Finally, not wanting to sound negative, but finding bugs is one thing, 
fixing them is another and we do not have a shortage on reported bugs 
for the static compiler

bye Jochen

View raw message