You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@groovy.apache.org by Ceki Gulcu <ce...@qos.ch> on 2017/12/03 15:37:55 UTC
Loading groovy as a Jigsaw auto-module
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
Re: Loading groovy as a Jigsaw auto-module
Posted by Jochen Theodorou <bl...@gmx.org>.
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 <blackdrag@gmx.org
> <ma...@gmx.org>> 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
>
>
Re: Loading groovy as a Jigsaw auto-module
Posted by Paul King <pa...@asert.com.au>.
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 <bl...@gmx.org> 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
>
Re: Loading groovy as a Jigsaw auto-module
Posted by Jochen Theodorou <bl...@gmx.org>.
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
Re: Loading groovy as a Jigsaw auto-module
Posted by Paul King <pa...@asert.com.au>.
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 <bl...@gmx.org> 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 <blackdrag@gmx.org <mailto:
>>> blackdrag@gmx.org>>:
>>>
>>> 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 <ceki@qos.ch
>>> <ma...@qos.ch> <mailto:ceki@qos.ch <ma...@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
>>> <http://markmail.org/message/obdyvuv24kqpxm6v>
>>> <http://markmail.org/message/obdyvuv24kqpxm6v
>>> <http://markmail.org/message/obdyvuv24kqpxm6v>>
>>>
>>>
>>>
>>>
Re: Loading groovy as a Jigsaw auto-module
Posted by Jochen Theodorou <bl...@gmx.org>.
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 <blackdrag@gmx.org
>> <ma...@gmx.org>>:
>>
>> 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 <ceki@qos.ch
>> <ma...@qos.ch> <mailto:ceki@qos.ch <ma...@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
>> <http://markmail.org/message/obdyvuv24kqpxm6v>
>> <http://markmail.org/message/obdyvuv24kqpxm6v
>> <http://markmail.org/message/obdyvuv24kqpxm6v>>
>>
>>
>>
Re: Loading groovy as a Jigsaw auto-module
Posted by Ceki Gulcu <ce...@qos.ch>.
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 <blackdrag@gmx.org
> <ma...@gmx.org>>:
>
> 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 <ceki@qos.ch
> <ma...@qos.ch> <mailto:ceki@qos.ch <ma...@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
> <http://markmail.org/message/obdyvuv24kqpxm6v>
> <http://markmail.org/message/obdyvuv24kqpxm6v
> <http://markmail.org/message/obdyvuv24kqpxm6v>>
>
>
>
Re: Loading groovy as a Jigsaw auto-module
Posted by Cédric Champeau <ce...@gmail.com>.
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 <bl...@gmx.org>:
> 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 <ceki@qos.ch <ma...@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
>> <http://markmail.org/message/obdyvuv24kqpxm6v>
>>
>>
>>
Re: Loading groovy as a Jigsaw auto-module
Posted by Jochen Theodorou <bl...@gmx.org>.
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 <ceki@qos.ch <ma...@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
> <http://markmail.org/message/obdyvuv24kqpxm6v>
>
>
Re: Loading groovy as a Jigsaw auto-module
Posted by Andres Almiray <aa...@gmail.com>.
Yes. But. The current content breaks the expected semantics of the
ServiceLoader mechanism.
That is, a line in a file such as META-INF/services/com.acme.Foo, is
expected to be
- a fully classified classname
- with no-args constructor
- that implements (if the filename denotes an interface) or extends (if
the filename denotes a class) the target type.
Per these rules the content of
META-INF/services/org.codehaus.groovy.source.Extensions
is wrong.
Given that this metadata file is to be used by the Groovy compiler alone it
would be better to use a different path/naming convention that does not
clash with existing Java conventions, something like
META-INF/groovy/org.codehaus.groovy.source.Extensions
Unless I missed something this should work, shouldn't it?
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:01 PM, Cédric Champeau <ce...@gmail.com>
wrote:
> 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 <ce...@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
>>
>
>
Re: Loading groovy as a Jigsaw auto-module
Posted by Cédric Champeau <ce...@gmail.com>.
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 <aa...@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 <ce...@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 <ce...@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
>>>>
>>>
>>>
>>
>
Re: Loading groovy as a Jigsaw auto-module
Posted by Cédric Champeau <ce...@gmail.com>.
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 <aa...@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 <ce...@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 <ce...@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
>>>>
>>>
>>>
>>
>
Re: Loading groovy as a Jigsaw auto-module
Posted by Andres Almiray <aa...@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 <ce...@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 <ce...@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 <ce...@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
>>>
>>
>>
>
Re: Loading groovy as a Jigsaw auto-module
Posted by Andres Almiray <aa...@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 <ce...@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 <ce...@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 <ce...@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
>>>
>>
>>
>
Re: Loading groovy as a Jigsaw auto-module
Posted by Cédric Champeau <ce...@gmail.com>.
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 <ce...@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 <ce...@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
>>
>
>
Re: Loading groovy as a Jigsaw auto-module
Posted by Cédric Champeau <ce...@gmail.com>.
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 <ce...@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 <ce...@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
>>
>
>
Re: Loading groovy as a Jigsaw auto-module
Posted by Cédric Champeau <ce...@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 <ce...@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
>