groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jochen Theodorou <blackd...@gmx.org>
Subject Re: Towards a better compiler
Date Sun, 09 Apr 2017 10:20:58 GMT
On 09.04.2017 11:53, Cédric Champeau wrote:
[...]
> There
> are hundreds of places where we use hash sets/maps, with objects that do
> not implement equals/hashcode, for example (and since those structures
> are mutable, we're very lucky because the default hashcode uses the
> system one, which is immutable).

if we use a set without equals and hashcode, then I guess a list would 
be better. For the maps it really depends.

>[...] In particular, we at Groovy offer AST
> transformations, which is similar, but not equivalent, to what
> annotation processors are for javac. The problem is that Groovy only has
> a single compile classpath, which includes both the "compiler plugins"
> (AST transformations) and implementation dependencies of the project we
> compile. So we're effectively mixing things that shouldn't be mixed:
>
> - annotations for AST transformations should be on the compile classpath
> - implementation of the AST transformations should be on the AST
> transformations path (compiler classpath)

internally this is separated with the transform loader. Just made no 
sense so far to extend that to FileSystemCompiler. Is Gradle going to 
use FileSystemcompiler now? Because before it did afaik not and could 
have had this already. This is also the reason

> If we don't do this, we cannot be as smart as what we do in the Java
> world, and compute what is relevant in terms of ABI (application binary
> interface). So any change to the classpath, needs to be considered a
> breaking change and we need to recompile everything. This makes the
> implementation of a Groovy incremental compiler effectively impossible.

That means in an incremental compilation scenario the classpath changes? 
The source set I expect to change, yes, but why the compile classpath? 
Would be nice if you could describe this a bit in more detail.

> Furthermore, it prevents the AST transform implementors to use the
> libraries they want as dependencies, without leaking them to the user
> compile classpath (imagine an AST xform which uses Guava 18, while the
> user wants Guava 17 on his classpath). In practice, the implementation
> dependencies of the AST xform are only required at compile time, not
> runtime, so they should be separate.

here I can agree again.. the main problem I think is the groovy runtime 
itself. Is a Closure on the compile classpath identical with one on the 
compiler classpath? Does it make sense to have a transform let´s say use 
Groovy 2.0 for the implementation on a Groovy 2.5 source?

> In short, I vote for the adoption of a new `-compilerpath` where we
> would put everything that affects the compiler itself, and live
> `--classpath` for the user space. Doing this would let tools like Gradle
> be much smarter about what they can do.
>
> [1] https://docs.gradle.org/3.5-rc-3/release-notes.html
> [2] https://issues.apache.org/jira/browse/GROOVY-8142
> [3] https://issues.apache.org/jira/browse/GROOVY-8148
> [4] https://blog.gradle.org/incremental-compiler-avoidance

sure... the identity question determines the complexity of the change 
though. And how Gradle would use it as well of course

bye Jochen


Mime
View raw message