On 26.11.2015 13:58, Remi Forax wrote:
------------------------------------------------------------------------
*De: *"Cédric Champeau" <[email protected]>
*À: *[email protected]
*Envoyé: *Jeudi 26 Novembre 2015 13:49:18
*Objet: *Re: challenges through Java modules (aka jigsaw)
You can have breaking changes in the way the classes are seen
from Java (and jigsaw) without having breaking changes when you
use these classes from Groovy.
By example, you can introduce a way to create type aliases to
Groovy, given that, you can move Java classes around and keep
the same references in the Groovy code.
This would work only if a library is recompiled against the latest
Groovy version (and even more true if you use @CompileStatic),
whereas the idea of backwards compatibility is *not* to recompile
everything. That is to say, take Groovy N+1 and it is capable of
running classes compiled with Groovy N.
The translation of types can appear at runtime if the type aliases are
known by the groovy class loader.
I think you only need re-compilation if you use @CompileStatic.
You mean loading of foo.bar.X is requested, but instead the classloader
gives out bar.foo.Y? I guess that works even under classloader
constraints....
Problem is that there are different environments to consider.
Precompiled and executed from Java for example means to have an
environment without a classloader under our control. Your suggestion
would not work there. If the script is not precompiled, then there is
always a GroovyClassLoader involved we can use, yes.... Even though
RootLoader would be the better place imho, but RootLoader too is not
always there. But maybe a tool operating on the bytecode can be used for
the precompiled cases. So I agree with Remi and we should not exclude
this idea prematurely.
Also about groovy-all, you can create a module groovy-all that
will require all other modules, no ?
Yes, but that's not the purpose of this module today. It's more for
guys who are too lazy to precisely determine all their Groovy module
dependencies and prefer to use groovy-all instead of groovy + "find
all modules that I use". Note that the simplification that I give is
recent, because a few releases ago, groovy-all contained repackaged
ASM classes, whereas groovy.jar did not. Now both have repackaged
classes, making it much more consistent and even less useful to use
groovy-all.
I really see even less problems with groovy-all compared to the non-all
groovy jar for normal java. Android is different... but that could do
with a special jar
if it's only packaging, you just have to create a module-info.class that
will concatenate all the module-info.class of all other modules, you may
need ASM for that :)
actually gradle may even have that, or will have that (using asm then of
course).
bye Jochen
