As to the new features of Java 8, Parrot provides the same syntax but the backend is based on the existing groovy runtime. The approach can make some differences between Groovy and Java 8. Whether these differences are allowed or not depends on GLS. Like the inner class behaves a bit differently with Java's(http://groovy-lang.org/differences.html#_inner_classes), lambda expression of Groovy can also have its own features and can be a bit different with lambda expression of Java. If most of us do not like the Groovy version of lambda expression(though it's much more powerful), IMO the best way to make Groovy behave same with Java is to study how to generate bytecode for LambdaExpression on the parrot branch(https://github.com/apache/groovy/blob/parrot/src/main/org/codehaus/groovy/ast/expr/LambdaExpression.java).
Cheers, Daniel.Sun 在 2017年2月2日 下午6:59，"paulk_asert [via Groovy]" <ml-node+s329449n5738403...@n5.nabble.com>写道：<br type="attri This thread has kind of gone into debate mode but I guess for the record I would be -1 on any releases having parrot that weren't marked as "experimental" or "incubating" until we thrash out future plans for dealing with Java 8 features (default methods on interfaces/"real" lambda expressions). I don't think we need to wait until those plans are finalised but we should know whether we'd support them down the track and plan accordingly. And I'd be +1 on getting out such "experimental"/"incubating" releases soon. I am +1 on getting 2.4.9 and a 2.5.0-beta out soon. I am hoping to have my review of macros finished by the end of next week but it would be good for at least one other person to review. I would also not be against upping the semantic versioning ante and renaming 2.5 to 3.0. If we did this renaming, I'd be keen to have an easy way to use parrot (an experimental/incubating version of the backport jar?). If after more experimentation we find no significant breaking changes, it could be merged into a 3.1, otherwise we should release a 4.0 with that. The jigsaw breaking changes would become 5.0 then I guess. Cheers, Paul. On Tue, Jan 31, 2017 at 6:37 PM, Cédric Champeau <[hidden email]</user/SendEmail.jtp?type=node&node=5738403&i=0>> wrote: > Hi guys, > > There are multiple conversations going on for weeks, and I think they are > going nowhere. We could discuss for months what's the best plan for Groovy, > without releasing anything. Here are the challenges that are waiting for us: > > 1. release a version of Groovy that integrates Groovy macros > 2. upgrade the minimal runtime required for Groovy to 1.7, which is required > to smoothly transition to higher requirements (and also, make our devs lives > easier) > 3. upgrade the minimal runtime required for Groovy to 1.8, allowing us to > drop the old call site caching and use indy Groovy everywhere > 4. integrate Parrot, which replaces the use of Antlr2 with Antlr4 > 5. compatibility with Jigsaw, aka "Groovy as a module" > > I would like to propose the following plan: > > - Groovy 2.5: integrates 1 and 2, to be released ASAP, we've been waiting > for this for too long > - Groovy 2.6: integrate 4, implying backporting Parrot to Java 7 > - Groovy 3.0: integrate 3 and 5. The only version with necessary breaking > changes (we have no choice here) > > This plan is, I think, a good compromise for all the requirements we have: > backwards compatibility, and making progress and not having too many > branches. An alternative would be to keep Parrot on Java 8, but as some of > us have said, this is incompatible with a soonish release. The drawback is > that Parrot has the risk of being a breaking change (it is, typically if > people implicitly depend on the old parser, which would be bad), so there's > a risk of not following semantic versioning. > > - [ ] YES, I approve the roadmap above > - [ ] NO, I do not approve the roadmap abobe beause... > - [ ] I don't mind, or this goes beyond what I can think of > > This vote is open for 72h, ending 9:30am CET, on Feb 3rd, 2017. > ________________________________ If you reply to this email, your message will be added to the discussion below: http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738403.html To unsubscribe from [VOTE] Apache Groovy Roadmap, click here<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5738250&code=cmVhbGJsdWVzdW5AaG90bWFpbC5jb218NTczODI1MHwxMTQ2MjE4MjI1>. NAML<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> -- View this message in context: http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738406.html Sent from the Groovy Dev mailing list archive at Nabble.com.
