groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jochen Theodorou <blackd...@gmx.org>
Subject Re: challenges through Java modules (aka jigsaw)
Date Thu, 26 Nov 2015 13:30:03 GMT
On 26.11.2015 13:58, Remi Forax wrote:
>
>
> ------------------------------------------------------------------------
>
>     *De: *"Cédric Champeau" <cedric.champeau@gmail.com>
>     *À: *dev@groovy.incubator.apache.org
>     *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

Mime
View raw message