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... @Cents(10)mg *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 Hi Jochen, > To me this means: to be able to compile like Java, you have to be > able > 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 ;-) Cheers, Daniel.Sun -- Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
