groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jochen Theodorou <>
Subject Re: Towards a better compiler
Date Fri, 21 Apr 2017 20:02:12 GMT
On 21.04.2017 19:46, Cédric Champeau wrote:
> The fact is that the compiler, for a
> specific set of sources + compile classpath, should always produce the
> same output. Especially on the same machine. If it doesn't, then the
> compiler is not predictable. It's a bug that needs to be fixed. It has
> nothing to do with Gradle, and *all* users would benefit from this.

I am curious. How does a user exactly benefit from it outside of a build 
tool like gradle?

Also I doubt we can be 100% reproducible as long as we use reflection 
somewhere, simple because reflection is not stable. Only because of the 
great contribution from intellij to be able read class files directly 
without reflection in the compiler we have the ability for *most* 
classes to have a stable result depending on the occurrence in bytecode. 
But for for example the Groovy classes directly known by the compiler 
like Closure, this won´t be the case.

100% stability is not achievable simply by using linked maps and sets.

> Gradle is an important use case because it currently defeats our
> caching, but it's not the only one. IDE indexing is another example.
> It's a serious issue, and we need to consider this a serious bug.

indexing? you mean idea? It does extensive indexing all the time... for 
minutes... without groovy

> BTW, we don't need to _sort_. We need to make sure that for the same
> input, we have the same output.

once you include reflection here... Those cases you could solve by 
sorting though.

> Especially, order of interfaces in
> declaration type matter (and they are reproducible today), We *must not*
> reorder them, or it would change semantics (typically for traits). I
> have fixed the bugs we, in the Gradle team, have identified, but my
> email was there to mention that we should take better care of this,
> because we do a pretty bad job at checking that the behavior of the
> compiler is deterministic.

well, that was no real option for a long time and no target till now. 
But if you say your fixes are enough for gradle, then your tests should 
ensure this stays. And then we don´t do a bad job at it anymore, do we?

> Regarding AST transformations classpath, I had actually forgotten that
> Gradle integrates directly with the compiler, so can use the 2 different
> "classpath". But AFAIK, our CLI doesn't. This should be easy to fix.

easy fix? depends... first of all... what will you gain from that? Since 
I have no idea where you get an advantage from those things outside a 
build tool that goes beyond something like make and ant, I fail to see 
the advantage

Granted, something like groovydoc gets an advantage, but honestly I do 
not see why there it should be done without sorting to achieve a 
somewhat stable output. And of course that sorting can very well happen 
in the doc tool

bye Jochen

View raw message