Quantcast

[infinispan-dev] All jars must go?

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[infinispan-dev] All jars must go?

Galder Zamarreño
Hi all,

As you might already know, there's been big debates about upcoming Java 9 module system.

Recently Stephen Colebourne, creator Joda time, posted his thoughts [1].

Stephen mentions some potential problems with all jars since no two modules should have same package. We know from past experience that using these jars as dependencies in Maven create all sorts of problems, but with the new JPMS they might not even work?

Have we tried all jars in Java 9? I'm wondering whether Stephen's problems with all jars are truly founded since Java offers no publishing itself. I mean, for that Stephen mentions to appear, you'd have to at runtime have an all jar and then individual jars, in which case it would fail. But as long as Maven does not enforce this in their repos, I think it's fine. If Maven starts enforcing this in the jars that are stored in Maven repos then yeah, we have a big problem.

Thoughts?

Cheers,

[1] http://blog.joda.org/2017/04/java-se-9-jpms-module-naming.html
--
Galder Zamarreño
Infinispan, Red Hat


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] All jars must go?

Sanne Grinovero-3
N.B. one problem many are not aware of is that - unlike with OSGi -
the restriction in Jigsaw also applies to private packages, e.g.
packages you're using within the jar but have no intention to "export"
make public.

So having this sorted out for OSGi doesn't mean that it will work fine
with Jigsaw.

I suspect we didn't test this, as far as I know we've only tested
running and compiling withing JDK9 but Infinispan itself is not
defining module descriptors; i.e. it's not modularized.

It's very likely that when we'll want to "modularize it" we'll have to
change APIs.

Thanks,
Sanne


On 4 May 2017 at 07:26, Galder Zamarreño <[hidden email]> wrote:

> Hi all,
>
> As you might already know, there's been big debates about upcoming Java 9 module system.
>
> Recently Stephen Colebourne, creator Joda time, posted his thoughts [1].
>
> Stephen mentions some potential problems with all jars since no two modules should have same package. We know from past experience that using these jars as dependencies in Maven create all sorts of problems, but with the new JPMS they might not even work?
>
> Have we tried all jars in Java 9? I'm wondering whether Stephen's problems with all jars are truly founded since Java offers no publishing itself. I mean, for that Stephen mentions to appear, you'd have to at runtime have an all jar and then individual jars, in which case it would fail. But as long as Maven does not enforce this in their repos, I think it's fine. If Maven starts enforcing this in the jars that are stored in Maven repos then yeah, we have a big problem.
>
> Thoughts?
>
> Cheers,
>
> [1] http://blog.joda.org/2017/04/java-se-9-jpms-module-naming.html
> --
> Galder Zamarreño
> Infinispan, Red Hat
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] All jars must go?

Dan Berindei
If it's just private packages, then we won't have to change the API ;)

Personally I'm more worried about how our externalizers for JDK
classes are going to work: it's going to be hard to say we support
Java 9 and at the same time ask users to add a bunch of --add-opens
[1] to their JVM arguments. I stopped updating the POM comment at some
point, but most other requirements for access to private JDK fields
seem to come from WildFly/Pax Exam.

[1]: https://github.com/infinispan/infinispan/blob/master/parent/pom.xml#L1614

Cheers
Dan


On Thu, May 4, 2017 at 6:50 PM, Sanne Grinovero <[hidden email]> wrote:

> N.B. one problem many are not aware of is that - unlike with OSGi -
> the restriction in Jigsaw also applies to private packages, e.g.
> packages you're using within the jar but have no intention to "export"
> make public.
>
> So having this sorted out for OSGi doesn't mean that it will work fine
> with Jigsaw.
>
> I suspect we didn't test this, as far as I know we've only tested
> running and compiling withing JDK9 but Infinispan itself is not
> defining module descriptors; i.e. it's not modularized.
>
> It's very likely that when we'll want to "modularize it" we'll have to
> change APIs.
>
> Thanks,
> Sanne
>
>
> On 4 May 2017 at 07:26, Galder Zamarreño <[hidden email]> wrote:
>> Hi all,
>>
>> As you might already know, there's been big debates about upcoming Java 9 module system.
>>
>> Recently Stephen Colebourne, creator Joda time, posted his thoughts [1].
>>
>> Stephen mentions some potential problems with all jars since no two modules should have same package. We know from past experience that using these jars as dependencies in Maven create all sorts of problems, but with the new JPMS they might not even work?
>>
>> Have we tried all jars in Java 9? I'm wondering whether Stephen's problems with all jars are truly founded since Java offers no publishing itself. I mean, for that Stephen mentions to appear, you'd have to at runtime have an all jar and then individual jars, in which case it would fail. But as long as Maven does not enforce this in their repos, I think it's fine. If Maven starts enforcing this in the jars that are stored in Maven repos then yeah, we have a big problem.
>>
>> Thoughts?
>>
>> Cheers,
>>
>> [1] http://blog.joda.org/2017/04/java-se-9-jpms-module-naming.html
>> --
>> Galder Zamarreño
>> Infinispan, Red Hat
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] All jars must go?

Dan Berindei
Forgot to answer the initial question: we do have integration tests
that use uber jars:

      <module>integrationtests/all-embedded-it</module>
      <module>integrationtests/all-embedded-query-it</module>
      <module>integrationtests/all-remote-it</module>

We don't have a Java 9 build in Jenkins ATM, but they ran fine with
jdk9-ea-164 on my machine.

Cheers
Dan


On Thu, May 4, 2017 at 7:03 PM, Dan Berindei <[hidden email]> wrote:

> If it's just private packages, then we won't have to change the API ;)
>
> Personally I'm more worried about how our externalizers for JDK
> classes are going to work: it's going to be hard to say we support
> Java 9 and at the same time ask users to add a bunch of --add-opens
> [1] to their JVM arguments. I stopped updating the POM comment at some
> point, but most other requirements for access to private JDK fields
> seem to come from WildFly/Pax Exam.
>
> [1]: https://github.com/infinispan/infinispan/blob/master/parent/pom.xml#L1614
>
> Cheers
> Dan
>
>
> On Thu, May 4, 2017 at 6:50 PM, Sanne Grinovero <[hidden email]> wrote:
>> N.B. one problem many are not aware of is that - unlike with OSGi -
>> the restriction in Jigsaw also applies to private packages, e.g.
>> packages you're using within the jar but have no intention to "export"
>> make public.
>>
>> So having this sorted out for OSGi doesn't mean that it will work fine
>> with Jigsaw.
>>
>> I suspect we didn't test this, as far as I know we've only tested
>> running and compiling withing JDK9 but Infinispan itself is not
>> defining module descriptors; i.e. it's not modularized.
>>
>> It's very likely that when we'll want to "modularize it" we'll have to
>> change APIs.
>>
>> Thanks,
>> Sanne
>>
>>
>> On 4 May 2017 at 07:26, Galder Zamarreño <[hidden email]> wrote:
>>> Hi all,
>>>
>>> As you might already know, there's been big debates about upcoming Java 9 module system.
>>>
>>> Recently Stephen Colebourne, creator Joda time, posted his thoughts [1].
>>>
>>> Stephen mentions some potential problems with all jars since no two modules should have same package. We know from past experience that using these jars as dependencies in Maven create all sorts of problems, but with the new JPMS they might not even work?
>>>
>>> Have we tried all jars in Java 9? I'm wondering whether Stephen's problems with all jars are truly founded since Java offers no publishing itself. I mean, for that Stephen mentions to appear, you'd have to at runtime have an all jar and then individual jars, in which case it would fail. But as long as Maven does not enforce this in their repos, I think it's fine. If Maven starts enforcing this in the jars that are stored in Maven repos then yeah, we have a big problem.
>>>
>>> Thoughts?
>>>
>>> Cheers,
>>>
>>> [1] http://blog.joda.org/2017/04/java-se-9-jpms-module-naming.html
>>> --
>>> Galder Zamarreño
>>> Infinispan, Red Hat
>>>
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] All jars must go?

Sanne Grinovero-3
In reply to this post by Dan Berindei
On 4 May 2017 at 12:03, Dan Berindei <[hidden email]> wrote:
> If it's just private packages, then we won't have to change the API ;)

Sorry if that was confusing: I meant to remind there are at least 2
problems to take in consideration.
Right they are not strongly correlated other than being consequences of Jigsaw.

>
> Personally I'm more worried about how our externalizers for JDK
> classes are going to work: it's going to be hard to say we support
> Java 9 and at the same time ask users to add a bunch of --add-opens
> [1] to their JVM arguments. I stopped updating the POM comment at some
> point, but most other requirements for access to private JDK fields
> seem to come from WildFly/Pax Exam.

Using "add-opens" is not the only option, and I agree it's not
desirable - especially for embedded users.

Read the Hibernate blog for some alternatives, but hey yes the APIs
will have to change ;)
 - http://in.relation.to/2017/04/11/accessing-private-state-of-java-9-modules/

Thanks,
Sanne


>
> [1]: https://github.com/infinispan/infinispan/blob/master/parent/pom.xml#L1614
>
> Cheers
> Dan
>
>
> On Thu, May 4, 2017 at 6:50 PM, Sanne Grinovero <[hidden email]> wrote:
>> N.B. one problem many are not aware of is that - unlike with OSGi -
>> the restriction in Jigsaw also applies to private packages, e.g.
>> packages you're using within the jar but have no intention to "export"
>> make public.
>>
>> So having this sorted out for OSGi doesn't mean that it will work fine
>> with Jigsaw.
>>
>> I suspect we didn't test this, as far as I know we've only tested
>> running and compiling withing JDK9 but Infinispan itself is not
>> defining module descriptors; i.e. it's not modularized.
>>
>> It's very likely that when we'll want to "modularize it" we'll have to
>> change APIs.
>>
>> Thanks,
>> Sanne
>>
>>
>> On 4 May 2017 at 07:26, Galder Zamarreño <[hidden email]> wrote:
>>> Hi all,
>>>
>>> As you might already know, there's been big debates about upcoming Java 9 module system.
>>>
>>> Recently Stephen Colebourne, creator Joda time, posted his thoughts [1].
>>>
>>> Stephen mentions some potential problems with all jars since no two modules should have same package. We know from past experience that using these jars as dependencies in Maven create all sorts of problems, but with the new JPMS they might not even work?
>>>
>>> Have we tried all jars in Java 9? I'm wondering whether Stephen's problems with all jars are truly founded since Java offers no publishing itself. I mean, for that Stephen mentions to appear, you'd have to at runtime have an all jar and then individual jars, in which case it would fail. But as long as Maven does not enforce this in their repos, I think it's fine. If Maven starts enforcing this in the jars that are stored in Maven repos then yeah, we have a big problem.
>>>
>>> Thoughts?
>>>
>>> Cheers,
>>>
>>> [1] http://blog.joda.org/2017/04/java-se-9-jpms-module-naming.html
>>> --
>>> Galder Zamarreño
>>> Infinispan, Red Hat
>>>
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] All jars must go?

Dan Berindei
On Thu, May 4, 2017 at 7:22 PM, Sanne Grinovero <[hidden email]> wrote:

> On 4 May 2017 at 12:03, Dan Berindei <[hidden email]> wrote:
>>
>> Personally I'm more worried about how our externalizers for JDK
>> classes are going to work: it's going to be hard to say we support
>> Java 9 and at the same time ask users to add a bunch of --add-opens
>> [1] to their JVM arguments. I stopped updating the POM comment at some
>> point, but most other requirements for access to private JDK fields
>> seem to come from WildFly/Pax Exam.
>
> Using "add-opens" is not the only option, and I agree it's not
> desirable - especially for embedded users.
>
> Read the Hibernate blog for some alternatives, but hey yes the APIs
> will have to change ;)
>  - http://in.relation.to/2017/04/11/accessing-private-state-of-java-9-modules/
>

Both methods seem to require the cooperation of the module containing
the POJOs. In our case those modules are in the JDK, and I doubt
Oracle will be so kind as to open everything to org.infinispan.core ;)

Dan
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Loading...