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() == x.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
Thread.run(
() -> {
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
