It seems Daniel has a point here: Knowing the whole landscape of bugs in the
static compiler cannot be a bad thing in itself, right ? And it might prohibit
fixing one bug reported by a Groovy user through a quick fix, when it is
actually part of a bigger problem.
I would however keep bugs found this way somehow distinguishable in Jira from
ones reported by users, since there will probably be some exotic/obscure edge
case bugs which no one really notices in practice, and which won 't be fixed
for some time.
The good news: In Groovy you have fallback to dynamic compilation, if static
for some reason fails, so unless the bug is in a really time critical part of
the code, you always* have a workable workaround at hand...
*except in the Minecraft Forge obfuscation case, of course ;;;-)
-------- Ursprüngliche Nachricht --------Von: Daniel Sun
<realblue...@hotmail.com> Datum: 08.04.18 13:18 (GMT+01:00) An:
d...@groovy.incubator.apache.org Betreff: Re: About the Phoenix plan for Groovy
> To me this means: to be able to compile like Java, you have to be
> to turn flow typing off.
Thanks for your reminding :-)
> You really want
> to go with bit-by-bit equality?
I do not care about how to generating same bytecode as Java's but I
want the same execution result. That's like the relationship between IBM's
J9 and Oracle's Hotspot. it is the backend of the compiler
As for the frontend, Groovy syntax is much complex than Java's, so I
plan to make Parrot parser support Java syntax as a dialect.
> I would include the OpenJDK in there, especially the tests for generics.
> And especially the tests for things that are supposed to *not* compile.
OK. I'll take into account it :-)
> 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
We always fix bugs but do not know when we will complete. The Phoenix
plan can make the target much more clear. The development process is similar
to Parrot parser, which parses the source code of grails, gradle, spock, geb
and groovy itself for test compatibility, so the quality of the Parrot
parser is assured ;-)
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html