Re: Loading groovy as a Jigsaw auto-module

Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Loading groovy as a Jigsaw auto-module

paulk_asert
Any objections if I look into moving the Extensions file from META-INF/services to META-INF/groovy (with a fallback to the current one). But not for 2.4.x.

Cheers, Paul.

On Mon, Dec 4, 2017 at 9:54 PM, Jochen Theodorou <[hidden email]> wrote:
Normally you specify what a provided service in module is. Thus the java compiler has no reason to look at random files in this directory. In fact the module info makes it very specific what to look for. That is why I doubt javac will have a problem, unless specified as not valid. And I have no indicator of the later.

As I said, the plugin afaik tries to create a module configuration for groovy. Tthat includes the services it provides or expects. Since this is automatic, the plugin has to do quite the opposite of javac and every file in there is potentially defining a service. And from that perspective it is quite understandable, that anything that is in those directories is supposed to be a service of some kind and thus should be exposed. The failure is just in acknowledging, that people do strange things from your individual pov. For others that strange thing might be the norm.

But as I said. We have to test if a module X depending on the groovy module can provide extension methods to groovy using the old mechanism or not. I suspect it cannot. I suspect a service provider structure will be required. And then we have to clean up META-INF/services as well.


Am 04.12.2017 um 10:44 schrieb Ceki Gulcu:

Jochen makes a good point regarding the source of the complaint being Maven rather than the JDK. However, Maven relies on JDK module support to know how to populate the classpath/modulepath prior to compilation. It essentially invokes java.lang.module.ModuleFinder.of(path).findAll().

Thus, I suspect that loading groovy-2.4.13,jar would fail anyway but Maven detects this condition before the java compiler has a chance to complain.


On 04.12.2017 10:28, Cédric Champeau wrote:
Oh thanks for the clarification, Jochen, I didn't realize the problem was with Maven itself. I think Maven over-interprets the spec. It's not because you find a file in `META-INF/services` that it *must* be a service descriptor.

Now for the extension mechanism, for sure we need to check what it means for us.

2017-12-04 10:23 GMT+01:00 Jochen Theodorou <[hidden email] <mailto:[hidden email]>>:

    Just to clarify things... This is a maven plugin complaining, not
    JDK9, as I see it. Afaik the plugin tries to create a module
    configuration for groovy and cannot interpret the services provided
    in those directories. JDK9 would not care, unless you say your
    module is providing a certain service.

    And I want to add two more points: The extension mechanism is
    unlikely to work as intended on JDK9. If you want to provide a
    service across modules you are now forced to use the very doubtful
    ServiceProvider infrastructure. And one module to read a file from
    another module was at least till late stages of JDK9 not possible. I
    am not sure what the latest state here was. Maybe I did interpret
    something wrong - writing a test for this would be easy.

    But if I am right, this would mean our extension mechanism must
    become a SPI structure to enable other modules to provide extension
    modules.

    Am 03.12.2017 um 19:01 schrieb Cédric Champeau:

        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 <[hidden email]
        <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>>:

             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
        <http://markmail.org/message/obdyvuv24kqpxm6v>
             <http://markmail.org/message/obdyvuv24kqpxm6v
        <http://markmail.org/message/obdyvuv24kqpxm6v>>




Reply | Threaded
Open this post in threaded view
|

Re: Loading groovy as a Jigsaw auto-module

Jochen Theodorou

Am 14.02.2018 um 03:34 schrieb Paul King:
> Any objections if I look into moving the Extensions file from
> META-INF/services to META-INF/groovy (with a fallback to the current
> one). But not for 2.4.x.

in the meantime I know that META-INF/services has been reserved for the
normal purposes and everything else is indeed not valid. You can find
this in some javadoc comment on some class... somewhere. I can look for
it again if you want to (of course that is java9+ only)

I still think a groovy library as module will not be able to expose its
extension methods this way, which means we will most probably not even
be able to keep the file and will have to move to a SPI structure... but
moving to META-INF/groovy is probably a good first step

bye Jochen
Reply | Threaded
Open this post in threaded view
|

Re: Loading groovy as a Jigsaw auto-module

paulk_asert
After moving the Extensions file, it looks like the only other file in Cédric's list that causes Java 9's ModuleFinder a problem is Groovy's extension module file:
META-INF/services/org.codehaus.groovy.runtime.ExtensionModule

I'll also see what is involved in moving that (with a fallback to the current location).

Cheers, Paul.

On Thu, Feb 15, 2018 at 3:49 AM, Jochen Theodorou <[hidden email]> wrote:

Am 14.02.2018 um 03:34 schrieb Paul King:
Any objections if I look into moving the Extensions file from META-INF/services to META-INF/groovy (with a fallback to the current one). But not for 2.4.x.

in the meantime I know that META-INF/services has been reserved for the normal purposes and everything else is indeed not valid. You can find this in some javadoc comment on some class... somewhere. I can look for it again if you want to (of course that is java9+ only)

I still think a groovy library as module will not be able to expose its extension methods this way, which means we will most probably not even be able to keep the file and will have to move to a SPI structure... but moving to META-INF/groovy is probably a good first step

bye Jochen

Reply | Threaded
Open this post in threaded view
|

Re: Loading groovy as a Jigsaw auto-module

Jochen Theodorou
Hi,

Everything in META-INF/service has to move, unless it is following the
SPI structure.

But just us moving will not allow Groovy libraries to define extension
methods sadly.

Am 22.02.2018 um 10:56 schrieb Paul King:

> After moving the Extensions file, it looks like the only other file in
> Cédric's list that causes Java 9's ModuleFinder a problem is Groovy's
> extension module file:
> META-INF/services/org.codehaus.groovy.runtime.ExtensionModule
>
> I'll also see what is involved in moving that (with a fallback to the
> current location).
>
> Cheers, Paul.
>
> On Thu, Feb 15, 2018 at 3:49 AM, Jochen Theodorou <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>
>     Am 14.02.2018 um 03:34 schrieb Paul King:
>
>         Any objections if I look into moving the Extensions file from
>         META-INF/services to META-INF/groovy (with a fallback to the
>         current one). But not for 2.4.x.
>
>
>     in the meantime I know that META-INF/services has been reserved for
>     the normal purposes and everything else is indeed not valid. You can
>     find this in some javadoc comment on some class... somewhere. I can
>     look for it again if you want to (of course that is java9+ only)
>
>     I still think a groovy library as module will not be able to expose
>     its extension methods this way, which means we will most probably
>     not even be able to keep the file and will have to move to a SPI
>     structure... but moving to META-INF/groovy is probably a good first step
>
>     bye Jochen
>
>