groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cédric Champeau <cedric.champ...@gmail.com>
Subject Re: Loading groovy as a Jigsaw auto-module
Date Sun, 03 Dec 2017 18:20:23 GMT
If it's only in 2.5, then there's no reason to put automatic module name in
2.5 either, because you wouldn't be able to use it. My understanding is
that it only blows up for Extensions because it thinks it's a class name,
but it's not. I think the JDK only tries to validate, but doesn't load
(which makes sense). So probably it shouldn't fail there, maybe just warn.

2017-12-03 19:17 GMT+01:00 Andres Almiray <aalmiray@gmail.com>:

> Right. My gut feeling tells me META-INF/services should be used as
> intended, this would mean breaking compatibility by moving existing files
> that are not service providers, as noted by Cedric. This change should be
> made in the 3.x branch and beyond IMHO.
> But it's also true we don't know the exact reason why
> META-INF/services/org.codehaus.groovy.source.Extensions is causing
> trouble and not the other files.
>
> Cheers,
> Andres
>
> -------------------------------------------
> Java Champion; Groovy Enthusiast
> JCP EC Associate Seat
> http://andresalmiray.com
> http://www.linkedin.com/in/aalmiray
> --
> What goes up, must come down. Ask any system administrator.
> There are 10 types of people in the world: Those who understand binary,
> and those who don't.
> To understand recursion, we must first understand recursion.
>
> On Sun, Dec 3, 2017 at 12:13 PM, Cédric Champeau <
> cedric.champeau@gmail.com> wrote:
>
>> So my understanding is that because this file is found in
>> META-INF/services, the JDK interprets its contents as being a service class
>> name provider, which is it not. We have quite a few files in there which
>> are "Groovy services" but nothing related to "Java services":
>>
>> META-INF/services/javax.script.ScriptEngineFactory: references the JSR
>> 223 class name. Service in the JDK semantics.
>> META-INF/services/org.apache.groovy.plugin.GroovyRunner : not quite sure
>> why it's there, seems rather new to me, and references a real class
>> (TestNgRunner)
>> META-INF/services/org.codehaus.groovy.runtime.ExtensionModule : Groovy's
>> extension module file. Doesn't reference services but it's more a
>> properties file referencing other class names
>> META-INF/services/org.codehaus.groovy.source.Extensions : possible
>> Groovy compiler extension file names listed here. Not a service.
>> META-INF/services/org.codehaus.groovy.transform.ASTTransformation : a
>> list of class names, which are not JDK services either.
>>
>> So I have no clue why the JDK needs to read all those files and make sure
>> the service classes exist. But it would be a breaking change to move those
>> files somewhere else.
>>
>>
>> 2017-12-03 19:01 GMT+01:00 Cédric Champeau <cedric.champeau@gmail.com>:
>>
>>> This file is used by Groovy internally, there's no reason for the JDK to
>>> interpret its contents since it has only a meaning for Groovy. In short, it
>>> declares the list of extensions recognized by the Groovy compiler. That it
>>> prevents loading as a module is rather strange.
>>>
>>> 2017-12-03 16:37 GMT+01:00 Ceki Gulcu <ceki@qos.ch>:
>>>
>>>> Hi all,
>>>>
>>>> Referring to a discussion on the maven users list [1], it appears that
>>>> removing the file META-INF/services/org.codehaus.groovy.source.Extensions
>>>> from groovy-2.4.13.jar allows Java 9 to successfully load groovy-2.4.13.jar
>>>> as an auto-module.
>>>>
>>>> The org.codehaus.groovy.source.Extensions file contains the lone word
>>>> "groovy" instead of a fully qualified class name.
>>>>
>>>> Please advise.
>>>>
>>>> Best regards,
>>>>
>>>> --
>>>> Ceki Gülcü
>>>>
>>>> [1] http://markmail.org/message/obdyvuv24kqpxm6v
>>>>
>>>
>>>
>>
>

Mime
View raw message