commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: Prepare commons RDF to JDK 9
Date Fri, 09 Mar 2018 00:33:38 GMT
I almost pooped myself on that one Ralph :-) Good one!

Gary

On Thu, Mar 8, 2018, 17:19 Ralph Goers <ralph.goers@dslextreme.com> wrote:

>
>
> > On Mar 8, 2018, at 5:17 PM, Ralph Goers <ralph.goers@dslextreme.com>
> wrote:
> >
> >
> >
> >> On Mar 8, 2018, at 4:08 PM, Gilles <gilles@harfang.homelinux.org>
> wrote:
> >>
> >> On Thu, 8 Mar 2018 15:09:18 -0700, Ralph Goers wrote:
> >>>> On Mar 8, 2018, at 11:06 AM, Gilles <gilles@harfang.homelinux.org>
> wrote:
> >>>>
> >>>> On Thu, 8 Mar 2018 11:01:08 -0700, Gary Gregory wrote:
> >>>>> On Thu, Mar 8, 2018 at 10:58 AM, Gilles <
> gilles@harfang.homelinux.org>
> >>>>> wrote:
> >>>>>
> >>>>>> On Thu, 8 Mar 2018 10:48:28 -0700, Gary Gregory wrote:
> >>>>>>
> >>>>>>> On Thu, Mar 8, 2018 at 10:29 AM, Gilles <
> gilles@harfang.homelinux.org>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>> On Thu, 8 Mar 2018 10:09:22 -0700, Gary Gregory wrote:
> >>>>>>>>
> >>>>>>>> On Thu, Mar 8, 2018 at 10:01 AM, ajs6f <ajs6f@apache.org>
wrote:
> >>>>>>>>>
> >>>>>>>>>> On Mar 8, 2018, at 8:33 AM, Gilles <
> gilles@harfang.homelinux.org>
> >>>>>>>>
> >>>>>>>>> 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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message