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 <dan.berin...@gmail.com> 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 <sa...@infinispan.org> 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 <gal...@redhat.com> 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
>>> infinispan-dev@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
