Message-ID: <1927264014.2681.1419700346644.JavaMail.firstname.lastname@example.org> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_2680_1902018287.1419700346643" ------=_Part_2680_1902018287.1419700346643 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Currently, Groovy is not able to run properly on Google's Android mobile= platform out of the box. A couple years ago, a first GSoC project (nicknam= ed DiscoBot), started porting Groovy to Android, using Groovy 1.7, but perf= ormance wasn't there (20s to startup a simple Hello World). The goal of thi= s GSoC project is to work with the Groovy core team and the past contributo= rs of the DiscoBot project, towards the goal of making any Groovy program t= o run on the Android platform well, so that apps for such mobile phone can = be written fully in Groovy.
It will be interesting to investigate what modifications can be brought = to Groovy to make it support Android in a more straightforward manner, how = we can leverage the recently introduced static compilation capabilities, an= d also see how Groovy builders and other features can help further streamli= ne the development of Android applications using Groovy.
Possible mentors: Jochen Theodorou or Guillaume Laforge, or one of the c= ontributors of DiscoBot
As of today, Groovy 2 still uses Antlr v2 for its grammar. The original = grammar was based off of the Java grammar itself. But we would like to crea= te a dedicated grammar for Groovy with the latest version of Antlr, ie. wit= h version 4. Antlr v4 has evolved nicely and makes it easier to evolve gram= mars, without the painful work of rule disambiguation. So the idea is to de= velop a clean room implementation of the Groovy grammar for the upcoming ve= rsions of Groovy, that would be able to also cover new syntax elements, lik= e the support of Java 8 lambda syntax, or the type annotation JSR, and we'd= also take the opportunity to tackle things that we haven't covered so far,= like JavaDoc comments in the resulting AST.
Possible mentor: Jochen Theodorou
The idea would be to have Groovy support generators, lazy evaluations, .= .. See for example: http://blog.bloidonia.c= om/post/22117894718/groovy-stream-a-lazy-generator-class-for-groovy
It is also important to take a look at what APIs are being written in JD= K 8 because most of the APIs written for the new lambdas are specifically l= azy.
Possible mentor: Paul King
As we are overhauling our documentation, the Groovy project is intereste= d into having documentation that is fully tested and always up-to-date with= our codebase. With those objectives in mind, a little tool has been create= d to provide a solution for having "executable documentation": Do= kspek (https://github.com/glaforge/dokspek). This tool ta= kes wiki pages in entry, extracts Groovy code snippets from the content, to= run those snippets as JUnit tests, and then resulting in HTML documentatio= n and tests that are passing as part of our test harness.
We'd like to further improve this tool and put it in place in the Groovy= codebase. Additional refinements can be brought, like having nice table of= content, indexing of concepts, PDF and HTML documentation generation, etc.=
Project: Groovy / DokSpek
Possible mentor: Guillaume Laforge