Prepare commons to JDK 9

classic Classic list List threaded Threaded
33 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Prepare commons RDF to JDK 9

Ralph Goers


> On Mar 8, 2018, at 4:08 PM, Gilles <[hidden email]> wrote:
>
> On Thu, 8 Mar 2018 15:09:18 -0700, Ralph Goers wrote:
>>> On Mar 8, 2018, at 11:06 AM, Gilles <[hidden email]> wrote:
>>>
>>> On Thu, 8 Mar 2018 11:01:08 -0700, Gary Gregory wrote:
>>>> On Thu, Mar 8, 2018 at 10:58 AM, Gilles <[hidden email]>
>>>> wrote:
>>>>
>>>>> On Thu, 8 Mar 2018 10:48:28 -0700, Gary Gregory wrote:
>>>>>
>>>>>> On Thu, Mar 8, 2018 at 10:29 AM, Gilles <[hidden email]>
>>>>>> wrote:
>>>>>>
>>>>>> On Thu, 8 Mar 2018 10:09:22 -0700, Gary Gregory wrote:
>>>>>>>
>>>>>>> On Thu, Mar 8, 2018 at 10:01 AM, ajs6f <[hidden email]> wrote:
>>>>>>>>
>>>>>>>> > On Mar 8, 2018, at 8:33 AM, Gilles <[hidden email]>
>>>>>>>
>>>>>>>> given component and see if we want to only depend on java.base or create
>>>>>>>> Maven modules to compartmentalize dependencies.
>>>>>>>>
>>>>>>>>
>>>>>>> Then these modules can define "module-info" files, and an actual
>>>>>>> build will prove that the dependencies are as expected.
>>>>>>>
>>>>>>>
>>>>>> As Ralph as pointed out, you cannot generate a module-info file without
>>>>>> also using an MR Jar unless you also want to make Java 9 your base line.
>>>>>>
>>>>>
>>>>> Did you see, a few lines above: "[...] assuming JDK 9+ [...]"? ;-)
>>>>>
>>>>> Related note: Java 9 is the target for compiling
>>>>> "commons-rng-examples" (maven module)
>>>>> in "Commons RNG" because one of the examples is composed of
>>>>> JPMS modules (with "module-info" files) that depend on the
>>>>> "official" artefacts (targeting Java 6) that declare an
>>>>> "automatic module name" in the manifest.
>>>>>
>>>>
>>>> Right now
>>>> https://git-wip-us.apache.org/repos/asf?p=commons-rdf.git;a=blob;f=pom.xml;h=06cc58c19b79af5cdf2f3d29d9a743c8adb2b548;hb=HEAD
>>>> shows Java 8 as the target.
>>>>
>>>> Are you taking about changing that to Java 9?
>>>>
>>>> I'll that choice to the Common RDF community but it seems that this would
>>>> exclude a lot of users.
>>>
>>> As for "Commons RNG", the purpose may just be to prove (by
>>> usage) that the maven modules are also JPMS modules.
>>
>>
>> I am so confused. I am not sure what the goal is.  Let me put it this
>> way. Log4j 2 2.x supports Java 7+. We added support for Java 9 by
>> introducing a multi-release jar.  Android developers can not use any
>> version of Log4j since we did that. What I am saying is that if you
>> turn any jar into a multi-release jar it will no longer be usable in
>> Android and there is no way around it until Android Studio is fixed.
>> The problem is that the android tool inspects every class file in the
>> jar even if it is located under META-INF and it dies if it sees a Java
>> 9 class.
>>
>> Ralph
>
> I've asked on this list about leveraging the new features of
> JDK 9 in the upcoming release of [RNG].  When it came to
> multi-release JAR, I trusted Gary's expedite answer ("Don't
> do it") based, as yours, on experience.  So, no issue.
>
> Yet I also wanted to ensure that the maven modules were
> JPMS-compliant: Would the declared "Automatic-Module-Name"
> behave as expected on JDK 9?
> No answer for that one.  So I resorted to create a "dummy"
> application (see "commons-rng-examples/examples-jpms").
> I guess the same could be done for [RDF] unless there is a
> smarter way. ;-)

We have not run into any problems with adding the Automatic-Module-Name header to the manifest.

Ralph



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Prepare commons RDF to JDK 9

Ralph Goers


> On Mar 8, 2018, at 5:17 PM, Ralph Goers <[hidden email]> wrote:
>
>
>
>> On Mar 8, 2018, at 4:08 PM, Gilles <[hidden email]> wrote:
>>
>> On Thu, 8 Mar 2018 15:09:18 -0700, Ralph Goers wrote:
>>>> On Mar 8, 2018, at 11:06 AM, Gilles <[hidden email]> wrote:
>>>>
>>>> On Thu, 8 Mar 2018 11:01:08 -0700, Gary Gregory wrote:
>>>>> On Thu, Mar 8, 2018 at 10:58 AM, Gilles <[hidden email]>
>>>>> wrote:
>>>>>
>>>>>> On Thu, 8 Mar 2018 10:48:28 -0700, Gary Gregory wrote:
>>>>>>
>>>>>>> On Thu, Mar 8, 2018 at 10:29 AM, Gilles <[hidden email]>
>>>>>>> wrote:
>>>>>>>
>>>>>>> On Thu, 8 Mar 2018 10:09:22 -0700, Gary Gregory wrote:
>>>>>>>>
>>>>>>>> On Thu, Mar 8, 2018 at 10:01 AM, ajs6f <[hidden email]> wrote:
>>>>>>>>>
>>>>>>>>>> On Mar 8, 2018, at 8:33 AM, Gilles <[hidden email]>
>>>>>>>>
>>>>>>>>> given component and see if we want to only depend on java.base or create
>>>>>>>>> Maven modules to compartmentalize dependencies.
>>>>>>>>>
>>>>>>>>>
>>>>>>>> Then these modules can define "module-info" files, and an actual
>>>>>>>> build will prove that the dependencies are as expected.
>>>>>>>>
>>>>>>>>
>>>>>>> As Ralph as pointed out, you cannot generate a module-info file without
>>>>>>> also using an MR Jar unless you also want to make Java 9 your base line.
>>>>>>>
>>>>>>
>>>>>> Did you see, a few lines above: "[...] assuming JDK 9+ [...]"? ;-)
>>>>>>
>>>>>> Related note: Java 9 is the target for compiling
>>>>>> "commons-rng-examples" (maven module)
>>>>>> in "Commons RNG" because one of the examples is composed of
>>>>>> JPMS modules (with "module-info" files) that depend on the
>>>>>> "official" artefacts (targeting Java 6) that declare an
>>>>>> "automatic module name" in the manifest.
>>>>>>
>>>>>
>>>>> Right now
>>>>> https://git-wip-us.apache.org/repos/asf?p=commons-rdf.git;a=blob;f=pom.xml;h=06cc58c19b79af5cdf2f3d29d9a743c8adb2b548;hb=HEAD
>>>>> shows Java 8 as the target.
>>>>>
>>>>> Are you taking about changing that to Java 9?
>>>>>
>>>>> I'll that choice to the Common RDF community but it seems that this would
>>>>> exclude a lot of users.
>>>>
>>>> As for "Commons RNG", the purpose may just be to prove (by
>>>> usage) that the maven modules are also JPMS modules.
>>>
>>>
>>> I am so confused. I am not sure what the goal is.  Let me put it this
>>> way. Log4j 2 2.x supports Java 7+. We added support for Java 9 by
>>> introducing a multi-release jar.  Android developers can not use any
>>> version of Log4j since we did that. What I am saying is that if you
>>> turn any jar into a multi-release jar it will no longer be usable in
>>> Android and there is no way around it until Android Studio is fixed.
>>> The problem is that the android tool inspects every class file in the
>>> jar even if it is located under META-INF and it dies if it sees a Java
>>> 9 class.
>>>
>>> Ralph
>>
>> I've asked on this list about leveraging the new features of
>> JDK 9 in the upcoming release of [RNG].  When it came to
>> multi-release JAR, I trusted Gary's expedite answer ("Don't
>> do it") based, as yours, on experience.  So, no issue.
>>
>> Yet I also wanted to ensure that the maven modules were
>> JPMS-compliant: Would the declared "Automatic-Module-Name"
>> behave as expected on JDK 9?
>> No answer for that one.  So I resorted to create a "dummy"
>> application (see "commons-rng-examples/examples-jpms").
>> I guess the same could be done for [RDF] unless there is a
>> smarter way. ;-)
>
> We have not run into any problems with adding the Automatic-Module-Name header to the manifest.
>

I should have also added that maybe it would be a good idea to make all the Commons jars multi-release. That might generate enough complaints to get Google to fix the issue.

I am not serious ;-)

Ralph

Reply | Threaded
Open this post in threaded view
|

Re: Prepare commons RDF to JDK 9

Gilles Sadowski
In reply to this post by Ralph Goers
On Thu, 8 Mar 2018 17:17:40 -0700, Ralph Goers wrote:

>> On Mar 8, 2018, at 4:08 PM, Gilles <[hidden email]>
>> wrote:
>>
>> On Thu, 8 Mar 2018 15:09:18 -0700, Ralph Goers wrote:
>>>> On Mar 8, 2018, at 11:06 AM, Gilles <[hidden email]>
>>>> wrote:
>>>>
>>>> On Thu, 8 Mar 2018 11:01:08 -0700, Gary Gregory wrote:
>>>>> On Thu, Mar 8, 2018 at 10:58 AM, Gilles
>>>>> <[hidden email]>
>>>>> wrote:
>>>>>
>>>>>> On Thu, 8 Mar 2018 10:48:28 -0700, Gary Gregory wrote:
>>>>>>
>>>>>>> On Thu, Mar 8, 2018 at 10:29 AM, Gilles
>>>>>>> <[hidden email]>
>>>>>>> wrote:
>>>>>>>
>>>>>>> On Thu, 8 Mar 2018 10:09:22 -0700, Gary Gregory wrote:
>>>>>>>>
>>>>>>>> On Thu, Mar 8, 2018 at 10:01 AM, ajs6f <[hidden email]>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> > On Mar 8, 2018, at 8:33 AM, Gilles
>>>>>>>>> <[hidden email]>
>>>>>>>>
>>>>>>>>> given component and see if we want to only depend on
>>>>>>>>> java.base or create
>>>>>>>>> Maven modules to compartmentalize dependencies.
>>>>>>>>>
>>>>>>>>>
>>>>>>>> Then these modules can define "module-info" files, and an
>>>>>>>> actual
>>>>>>>> build will prove that the dependencies are as expected.
>>>>>>>>
>>>>>>>>
>>>>>>> As Ralph as pointed out, you cannot generate a module-info file
>>>>>>> without
>>>>>>> also using an MR Jar unless you also want to make Java 9 your
>>>>>>> base line.
>>>>>>>
>>>>>>
>>>>>> Did you see, a few lines above: "[...] assuming JDK 9+ [...]"?
>>>>>> ;-)
>>>>>>
>>>>>> Related note: Java 9 is the target for compiling
>>>>>> "commons-rng-examples" (maven module)
>>>>>> in "Commons RNG" because one of the examples is composed of
>>>>>> JPMS modules (with "module-info" files) that depend on the
>>>>>> "official" artefacts (targeting Java 6) that declare an
>>>>>> "automatic module name" in the manifest.
>>>>>>
>>>>>
>>>>> Right now
>>>>>
>>>>> https://git-wip-us.apache.org/repos/asf?p=commons-rdf.git;a=blob;f=pom.xml;h=06cc58c19b79af5cdf2f3d29d9a743c8adb2b548;hb=HEAD
>>>>> shows Java 8 as the target.
>>>>>
>>>>> Are you taking about changing that to Java 9?
>>>>>
>>>>> I'll that choice to the Common RDF community but it seems that
>>>>> this would
>>>>> exclude a lot of users.
>>>>
>>>> As for "Commons RNG", the purpose may just be to prove (by
>>>> usage) that the maven modules are also JPMS modules.
>>>
>>>
>>> I am so confused. I am not sure what the goal is.  Let me put it
>>> this
>>> way. Log4j 2 2.x supports Java 7+. We added support for Java 9 by
>>> introducing a multi-release jar.  Android developers can not use
>>> any
>>> version of Log4j since we did that. What I am saying is that if you
>>> turn any jar into a multi-release jar it will no longer be usable
>>> in
>>> Android and there is no way around it until Android Studio is
>>> fixed.
>>> The problem is that the android tool inspects every class file in
>>> the
>>> jar even if it is located under META-INF and it dies if it sees a
>>> Java
>>> 9 class.
>>>
>>> Ralph
>>
>> I've asked on this list about leveraging the new features of
>> JDK 9 in the upcoming release of [RNG].  When it came to
>> multi-release JAR, I trusted Gary's expedite answer ("Don't
>> do it") based, as yours, on experience.  So, no issue.
>>
>> Yet I also wanted to ensure that the maven modules were
>> JPMS-compliant: Would the declared "Automatic-Module-Name"
>> behave as expected on JDK 9?
>> No answer for that one.  So I resorted to create a "dummy"
>> application (see "commons-rng-examples/examples-jpms").
>> I guess the same could be done for [RDF] unless there is a
>> smarter way. ;-)
>
> We have not run into any problems with adding the
> Automatic-Module-Name header to the manifest.

I'm quite sure there is no harm in adding entries.
It doesn't imply that they are correct (cf. recent
issue with the typo in an "OSGi" entry).

What I mean is checking the compilation, using the
"module-path", of an application/other modules that
depend on the automatic modules.

Gilles


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Prepare commons RDF to JDK 9

garydgregory
In reply to this post by Ralph Goers
I almost pooped myself on that one Ralph :-) Good one!

Gary

On Thu, Mar 8, 2018, 17:19 Ralph Goers <[hidden email]> wrote:

>
>
> > On Mar 8, 2018, at 5:17 PM, Ralph Goers <[hidden email]>
> wrote:
> >
> >
> >
> >> On Mar 8, 2018, at 4:08 PM, Gilles <[hidden email]>
> wrote:
> >>
> >> On Thu, 8 Mar 2018 15:09:18 -0700, Ralph Goers wrote:
> >>>> On Mar 8, 2018, at 11:06 AM, Gilles <[hidden email]>
> wrote:
> >>>>
> >>>> On Thu, 8 Mar 2018 11:01:08 -0700, Gary Gregory wrote:
> >>>>> On Thu, Mar 8, 2018 at 10:58 AM, Gilles <
> [hidden email]>
> >>>>> wrote:
> >>>>>
> >>>>>> On Thu, 8 Mar 2018 10:48:28 -0700, Gary Gregory wrote:
> >>>>>>
> >>>>>>> On Thu, Mar 8, 2018 at 10:29 AM, Gilles <
> [hidden email]>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>> On Thu, 8 Mar 2018 10:09:22 -0700, Gary Gregory wrote:
> >>>>>>>>
> >>>>>>>> On Thu, Mar 8, 2018 at 10:01 AM, ajs6f <[hidden email]> wrote:
> >>>>>>>>>
> >>>>>>>>>> On Mar 8, 2018, at 8:33 AM, Gilles <
> [hidden email]>
> >>>>>>>>
> >>>>>>>>> given component and see if we want to only depend on java.base
> or create
> >>>>>>>>> Maven modules to compartmentalize dependencies.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>> Then these modules can define "module-info" files, and an actual
> >>>>>>>> build will prove that the dependencies are as expected.
> >>>>>>>>
> >>>>>>>>
> >>>>>>> As Ralph as pointed out, you cannot generate a module-info file
> without
> >>>>>>> also using an MR Jar unless you also want to make Java 9 your base
> line.
> >>>>>>>
> >>>>>>
> >>>>>> Did you see, a few lines above: "[...] assuming JDK 9+ [...]"? ;-)
> >>>>>>
> >>>>>> Related note: Java 9 is the target for compiling
> >>>>>> "commons-rng-examples" (maven module)
> >>>>>> in "Commons RNG" because one of the examples is composed of
> >>>>>> JPMS modules (with "module-info" files) that depend on the
> >>>>>> "official" artefacts (targeting Java 6) that declare an
> >>>>>> "automatic module name" in the manifest.
> >>>>>>
> >>>>>
> >>>>> Right now
> >>>>>
> https://git-wip-us.apache.org/repos/asf?p=commons-rdf.git;a=blob;f=pom.xml;h=06cc58c19b79af5cdf2f3d29d9a743c8adb2b548;hb=HEAD
> >>>>> shows Java 8 as the target.
> >>>>>
> >>>>> Are you taking about changing that to Java 9?
> >>>>>
> >>>>> I'll that choice to the Common RDF community but it seems that this
> would
> >>>>> exclude a lot of users.
> >>>>
> >>>> As for "Commons RNG", the purpose may just be to prove (by
> >>>> usage) that the maven modules are also JPMS modules.
> >>>
> >>>
> >>> I am so confused. I am not sure what the goal is.  Let me put it this
> >>> way. Log4j 2 2.x supports Java 7+. We added support for Java 9 by
> >>> introducing a multi-release jar.  Android developers can not use any
> >>> version of Log4j since we did that. What I am saying is that if you
> >>> turn any jar into a multi-release jar it will no longer be usable in
> >>> Android and there is no way around it until Android Studio is fixed.
> >>> The problem is that the android tool inspects every class file in the
> >>> jar even if it is located under META-INF and it dies if it sees a Java
> >>> 9 class.
> >>>
> >>> Ralph
> >>
> >> I've asked on this list about leveraging the new features of
> >> JDK 9 in the upcoming release of [RNG].  When it came to
> >> multi-release JAR, I trusted Gary's expedite answer ("Don't
> >> do it") based, as yours, on experience.  So, no issue.
> >>
> >> Yet I also wanted to ensure that the maven modules were
> >> JPMS-compliant: Would the declared "Automatic-Module-Name"
> >> behave as expected on JDK 9?
> >> No answer for that one.  So I resorted to create a "dummy"
> >> application (see "commons-rng-examples/examples-jpms").
> >> I guess the same could be done for [RDF] unless there is a
> >> smarter way. ;-)
> >
> > We have not run into any problems with adding the Automatic-Module-Name
> header to the manifest.
> >
>
> I should have also added that maybe it would be a good idea to make all
> the Commons jars multi-release. That might generate enough complaints to
> get Google to fix the issue.
>
> I am not serious ;-)
>
> Ralph
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Prepare commons RDF to JDK 9

garydgregory
In reply to this post by Gilles Sadowski
That seems like a good pragmatic way about it.

Gary

On Thu, Mar 8, 2018, 16:08 Gilles <[hidden email]> wrote:

> On Thu, 8 Mar 2018 15:09:18 -0700, Ralph Goers wrote:
> >> On Mar 8, 2018, at 11:06 AM, Gilles <[hidden email]>
> >> wrote:
> >>
> >> On Thu, 8 Mar 2018 11:01:08 -0700, Gary Gregory wrote:
> >>> On Thu, Mar 8, 2018 at 10:58 AM, Gilles
> >>> <[hidden email]>
> >>> wrote:
> >>>
> >>>> On Thu, 8 Mar 2018 10:48:28 -0700, Gary Gregory wrote:
> >>>>
> >>>>> On Thu, Mar 8, 2018 at 10:29 AM, Gilles
> >>>>> <[hidden email]>
> >>>>> wrote:
> >>>>>
> >>>>> On Thu, 8 Mar 2018 10:09:22 -0700, Gary Gregory wrote:
> >>>>>>
> >>>>>> On Thu, Mar 8, 2018 at 10:01 AM, ajs6f <[hidden email]> wrote:
> >>>>>>>
> >>>>>>> > On Mar 8, 2018, at 8:33 AM, Gilles
> >>>>>>> <[hidden email]>
> >>>>>>
> >>>>>>> given component and see if we want to only depend on java.base
> >>>>>>> or create
> >>>>>>> Maven modules to compartmentalize dependencies.
> >>>>>>>
> >>>>>>>
> >>>>>> Then these modules can define "module-info" files, and an actual
> >>>>>> build will prove that the dependencies are as expected.
> >>>>>>
> >>>>>>
> >>>>> As Ralph as pointed out, you cannot generate a module-info file
> >>>>> without
> >>>>> also using an MR Jar unless you also want to make Java 9 your
> >>>>> base line.
> >>>>>
> >>>>
> >>>> Did you see, a few lines above: "[...] assuming JDK 9+ [...]"? ;-)
> >>>>
> >>>> Related note: Java 9 is the target for compiling
> >>>> "commons-rng-examples" (maven module)
> >>>> in "Commons RNG" because one of the examples is composed of
> >>>> JPMS modules (with "module-info" files) that depend on the
> >>>> "official" artefacts (targeting Java 6) that declare an
> >>>> "automatic module name" in the manifest.
> >>>>
> >>>
> >>> Right now
> >>>
> >>>
> https://git-wip-us.apache.org/repos/asf?p=commons-rdf.git;a=blob;f=pom.xml;h=06cc58c19b79af5cdf2f3d29d9a743c8adb2b548;hb=HEAD
> >>> shows Java 8 as the target.
> >>>
> >>> Are you taking about changing that to Java 9?
> >>>
> >>> I'll that choice to the Common RDF community but it seems that this
> >>> would
> >>> exclude a lot of users.
> >>
> >> As for "Commons RNG", the purpose may just be to prove (by
> >> usage) that the maven modules are also JPMS modules.
> >
> >
> > I am so confused. I am not sure what the goal is.  Let me put it this
> > way. Log4j 2 2.x supports Java 7+. We added support for Java 9 by
> > introducing a multi-release jar.  Android developers can not use any
> > version of Log4j since we did that. What I am saying is that if you
> > turn any jar into a multi-release jar it will no longer be usable in
> > Android and there is no way around it until Android Studio is fixed.
> > The problem is that the android tool inspects every class file in the
> > jar even if it is located under META-INF and it dies if it sees a
> > Java
> > 9 class.
> >
> > Ralph
>
> I've asked on this list about leveraging the new features of
> JDK 9 in the upcoming release of [RNG].  When it came to
> multi-release JAR, I trusted Gary's expedite answer ("Don't
> do it") based, as yours, on experience.  So, no issue.
>
> Yet I also wanted to ensure that the maven modules were
> JPMS-compliant: Would the declared "Automatic-Module-Name"
> behave as expected on JDK 9?
> No answer for that one.  So I resorted to create a "dummy"
> application (see "commons-rng-examples/examples-jpms").
> I guess the same could be done for [RDF] unless there is a
> smarter way. ;-)
>
> Gilles
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Prepare commons RDF to JDK 9

Gilles Sadowski
In reply to this post by Ralph Goers
On Thu, 8 Mar 2018 17:19:05 -0700, Ralph Goers wrote:

>> On Mar 8, 2018, at 5:17 PM, Ralph Goers <[hidden email]>
>> wrote:
>>
>>
>>
>>> On Mar 8, 2018, at 4:08 PM, Gilles <[hidden email]>
>>> wrote:
>>>
>>> On Thu, 8 Mar 2018 15:09:18 -0700, Ralph Goers wrote:
>>>>> On Mar 8, 2018, at 11:06 AM, Gilles
>>>>> <[hidden email]> wrote:
>>>>>
>>>>> On Thu, 8 Mar 2018 11:01:08 -0700, Gary Gregory wrote:
>>>>>> On Thu, Mar 8, 2018 at 10:58 AM, Gilles
>>>>>> <[hidden email]>
>>>>>> wrote:
>>>>>>
>>>>>>> On Thu, 8 Mar 2018 10:48:28 -0700, Gary Gregory wrote:
>>>>>>>
>>>>>>>> On Thu, Mar 8, 2018 at 10:29 AM, Gilles
>>>>>>>> <[hidden email]>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> On Thu, 8 Mar 2018 10:09:22 -0700, Gary Gregory wrote:
>>>>>>>>>
>>>>>>>>> On Thu, Mar 8, 2018 at 10:01 AM, ajs6f <[hidden email]>
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> On Mar 8, 2018, at 8:33 AM, Gilles
>>>>>>>>>>> <[hidden email]>
>>>>>>>>>
>>>>>>>>>> given component and see if we want to only depend on
>>>>>>>>>> java.base or create
>>>>>>>>>> Maven modules to compartmentalize dependencies.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> Then these modules can define "module-info" files, and an
>>>>>>>>> actual
>>>>>>>>> build will prove that the dependencies are as expected.
>>>>>>>>>
>>>>>>>>>
>>>>>>>> As Ralph as pointed out, you cannot generate a module-info
>>>>>>>> file without
>>>>>>>> also using an MR Jar unless you also want to make Java 9 your
>>>>>>>> base line.
>>>>>>>>
>>>>>>>
>>>>>>> Did you see, a few lines above: "[...] assuming JDK 9+ [...]"?
>>>>>>> ;-)
>>>>>>>
>>>>>>> Related note: Java 9 is the target for compiling
>>>>>>> "commons-rng-examples" (maven module)
>>>>>>> in "Commons RNG" because one of the examples is composed of
>>>>>>> JPMS modules (with "module-info" files) that depend on the
>>>>>>> "official" artefacts (targeting Java 6) that declare an
>>>>>>> "automatic module name" in the manifest.
>>>>>>>
>>>>>>
>>>>>> Right now
>>>>>>
>>>>>> https://git-wip-us.apache.org/repos/asf?p=commons-rdf.git;a=blob;f=pom.xml;h=06cc58c19b79af5cdf2f3d29d9a743c8adb2b548;hb=HEAD
>>>>>> shows Java 8 as the target.
>>>>>>
>>>>>> Are you taking about changing that to Java 9?
>>>>>>
>>>>>> I'll that choice to the Common RDF community but it seems that
>>>>>> this would
>>>>>> exclude a lot of users.
>>>>>
>>>>> As for "Commons RNG", the purpose may just be to prove (by
>>>>> usage) that the maven modules are also JPMS modules.
>>>>
>>>>
>>>> I am so confused. I am not sure what the goal is.  Let me put it
>>>> this
>>>> way. Log4j 2 2.x supports Java 7+. We added support for Java 9 by
>>>> introducing a multi-release jar.  Android developers can not use
>>>> any
>>>> version of Log4j since we did that. What I am saying is that if
>>>> you
>>>> turn any jar into a multi-release jar it will no longer be usable
>>>> in
>>>> Android and there is no way around it until Android Studio is
>>>> fixed.
>>>> The problem is that the android tool inspects every class file in
>>>> the
>>>> jar even if it is located under META-INF and it dies if it sees a
>>>> Java
>>>> 9 class.
>>>>
>>>> Ralph
>>>
>>> I've asked on this list about leveraging the new features of
>>> JDK 9 in the upcoming release of [RNG].  When it came to
>>> multi-release JAR, I trusted Gary's expedite answer ("Don't
>>> do it") based, as yours, on experience.  So, no issue.
>>>
>>> Yet I also wanted to ensure that the maven modules were
>>> JPMS-compliant: Would the declared "Automatic-Module-Name"
>>> behave as expected on JDK 9?
>>> No answer for that one.  So I resorted to create a "dummy"
>>> application (see "commons-rng-examples/examples-jpms").
>>> I guess the same could be done for [RDF] unless there is a
>>> smarter way. ;-)
>>
>> We have not run into any problems with adding the
>> Automatic-Module-Name header to the manifest.
>>
>
> I should have also added that maybe it would be a good idea to make
> all the Commons jars multi-release. That might generate enough
> complaints to get Google to fix the issue.

In the beginning of this thread, I wanted to suggest releasing
two sets of artefacts, one multi-release, and one not.

> I am not serious ;-)

Now I'm disappointed. :-}


Gilles


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Prepare commons RDF to JDK 9

Bernd Eckenfels
Hello,

any experience with compiling a JAR with old Java and only adding the module-info.jar with a new class Version? Would that allow to avoid the Need for Multi-Release JARs? (of Course it makes a ugly toolchain).

Gruss
Bernd
--
http://bernd.eckenfels.net

Reply | Threaded
Open this post in threaded view
|

Re: Prepare commons RDF to JDK 9

Ralph Goers


> On Mar 8, 2018, at 5:47 PM, Bernd Eckenfels <[hidden email]> wrote:
>
> Hello,
>
> any experience with compiling a JAR with old Java and only adding the module-info.jar with a new class Version? Would that allow to avoid the Need for Multi-Release JARs? (of Course it makes a ugly toolchain).

Log4j 2 has a few classes that take advantage of Java 9 and the log4j-api jar has a module-info.java file in it.  We had to create a separate module for those so they could compile with Java 9. We then copy them into the api jar before creating the jar. Yes, you could do that and not place the module-info.class file (or other classes compiled with Java 9) their “normal” locaions but then you would need some special way to detect that the classes are there to be able to take advantage of them.

That all is workable. However, I am pretty sure you could not include such a jar as an OSGi module and there are various other tools that will fail when they encounter the unknown class version.

Ralph



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Prepare commons RDF to JDK 9

Gilles Sadowski
In reply to this post by Bernd Eckenfels
On Fri, 9 Mar 2018 01:47:01 +0100, Bernd Eckenfels wrote:
> Hello,
>
> any experience with compiling a JAR with old Java and only adding the
> module-info.jar with a new class Version? Would that allow to avoid
> the Need for Multi-Release JARs? (of Course it makes a ugly
> toolchain).

IIUC, there must be a one-to-one relationship between
JAR and module; if so, that would seem to forbid your
scenario.

Regards,
Gilles

> Gruss
> Bernd


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Prepare commons RDF to JDK 9

Kamila Molina Orellana
Hi,

Sorry for causing the confusion. I mean to include a general subject since
I think commons would benefit from the results. However, I pointed out in
the content that the work'd be done over commons-rdf. Again, sorry for
that. :D

Regards,
~Kamila.

On Thu, Mar 8, 2018 at 8:23 PM, Gilles <[hidden email]> wrote:

> On Fri, 9 Mar 2018 01:47:01 +0100, Bernd Eckenfels wrote:
>
>> Hello,
>>
>> any experience with compiling a JAR with old Java and only adding the
>> module-info.jar with a new class Version? Would that allow to avoid
>> the Need for Multi-Release JARs? (of Course it makes a ugly
>> toolchain).
>>
>
> IIUC, there must be a one-to-one relationship between
> JAR and module; if so, that would seem to forbid your
> scenario.
>
> Regards,
> Gilles
>
> Gruss
>> Bernd
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Prepare commons to JDK 9

Jörg Schaible
In reply to this post by Ralph Goers
Hi Ralph,

On Wed, 07 Mar 2018 11:56:32 -0700 Ralph Goers wrote:

>> On Mar 7, 2018, at 2:47 AM, Stephen Colebourne <[hidden email]>
>> wrote:
>>
>> 1) Moving to Java 9 as a base would be a terrible choice. Java 9 is a
>> six-month release which is about to be replaced by Java 10, which will
>> then be replaced by Java 11. Thus, Java 8 is the only sensible baseline
>> right now.
>>
>> 2) Compiling a single jar file such that it works on Java 8 but has a
>> module-info.class for Java 9 using Maven is a right pain in the
>> backside. Most maven plugins cannot seamlessly handle it making the
>> pom.xml much more complex. Note that you do not need a multi-release
>> jar file to make it work. See
>> https://github.com/ThreeTen/threeten-extra/blob/master/pom.xml
>> <https://github.com/ThreeTen/threeten-extra/blob/master/pom.xml>
>
> Actually, you really do need to use a multi-release jar to include a
> module-info class file. Otherwise it may be sitting alongside of classes
> compiled for an earlier java release and various tools will fail because
> of it.

Not necessarily. XStream contains for more than a decade class files targeting different Java versions. Works
normally fine as long as nobody tries to load a class that cannot handled by the current runtime. Android has
its problems with it, but it has already problems with Java 8 ;-)

Cheers,
Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Prepare commons to JDK 9

Ralph Goers


> On Mar 12, 2018, at 9:27 AM, Jörg Schaible <[hidden email]> wrote:
>
> Hi Ralph,
>
> On Wed, 07 Mar 2018 11:56:32 -0700 Ralph Goers wrote:
>
>>> On Mar 7, 2018, at 2:47 AM, Stephen Colebourne <[hidden email]>
>>> wrote:
>>>
>>> 1) Moving to Java 9 as a base would be a terrible choice. Java 9 is a
>>> six-month release which is about to be replaced by Java 10, which will
>>> then be replaced by Java 11. Thus, Java 8 is the only sensible baseline
>>> right now.
>>>
>>> 2) Compiling a single jar file such that it works on Java 8 but has a
>>> module-info.class for Java 9 using Maven is a right pain in the
>>> backside. Most maven plugins cannot seamlessly handle it making the
>>> pom.xml much more complex. Note that you do not need a multi-release
>>> jar file to make it work. See
>>> https://github.com/ThreeTen/threeten-extra/blob/master/pom.xml
>>> <https://github.com/ThreeTen/threeten-extra/blob/master/pom.xml>
>>
>> Actually, you really do need to use a multi-release jar to include a
>> module-info class file. Otherwise it may be sitting alongside of classes
>> compiled for an earlier java release and various tools will fail because
>> of it.
>
> Not necessarily. XStream contains for more than a decade class files targeting different Java versions. Works
> normally fine as long as nobody tries to load a class that cannot handled by the current runtime. Android has
> its problems with it, but it has already problems with Java 8 ;-)

You statement just proved my point. “Works fine as long as …”.  So as soon as you want to support those various tools you have to stop doing that.

Ralph

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Prepare commons to JDK 9

Adam Soroka

> On Mar 12, 2018, at 1:13 PM, Ralph Goers <[hidden email]> wrote:
>
>
>
>> On Mar 12, 2018, at 9:27 AM, Jörg Schaible <[hidden email]> wrote:
>>
>> Hi Ralph,
>>
>> On Wed, 07 Mar 2018 11:56:32 -0700 Ralph Goers wrote:
>>>
>>> Actually, you really do need to use a multi-release jar to include a module-info class file. Otherwise it may be sitting alongside of classes compiled for an earlier java release and various tools will fail becaus of it.
>>
>> Not necessarily. XStream contains for more than a decade class files targeting different Java versions. Works  normally fine as long as nobody tries to load a class that cannot handled by the current runtime. Android has its problems with it, but it has already problems with Java 8 ;-)
>
> You statement just proved my point. “Works fine as long as …”.  So as soon as you want to support those various tools you have to stop doing that.
>
> Ralph

Is there actually a standard list of tools or other build apparatus that is to be supported by Commons releases? I can name lots and lots of tools that won't work with Java 7 or even earlier versions. Most of them don't matter at all. I'm not making a claim about any particular tool or toolchain (including Android), but a general point.

I'd like to understand when "if we try X, our artifacts won't work on Y" is a valid blocker for a Commons project. In this case, the project (as has been repeatedly explained) aims to do nothing more than understand the conditions for using X and how to meet them, so I don't see how Android's (or any other specific project's) problems are a blocker at all. If anything, concern with problems for Android usage should be assuaged by a project that will help turn up more data about those problems.

Adam Soroka ; [hidden email]
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

12