Re: RFR 8154182: Fix java/lang/Class/getDeclaredField/FieldSetAccessibleTest.java to only use available modules

[Shura]

> On Apr 14, 2016, at 7:27 AM, Alan Bateman  wrote:
> 
> On 13/04/2016 18:29, Alexandre (Shura) Iline wrote:
>> Hi,
>> 
>> Could you be so kind to take a look on this fix:
>> http://cr.openjdk.java.net/~shurailine/8154182/webrev.00/
>> 
> What would you think of having this test run with `-addmods ALL-SYSTEM` 
> instead? Your patch is okay but it will mean that the test won't exercise 
> getDeclaredFields on the EE module, at least not when we bring the changes in 
> jake to JDK 9. This option can be used with `-limitmods`.
> 
> Another test like this is VerifyModuleDelegation. In both cases the tests 
> have been changed to run with `-addmods ALL-SYSTEM` in jake.

Alan,

I am not sure what you are suggesting.

Right now the test is failing without my changes, if “-limitmods java.base” is 
supplied to the jtreg command line:
$ jtreg -jdk:... -noreport "-javaoptions:-limitmods java.base" 
java/lang/Class/getDeclaredField/FieldSetAccessibleTest.java
with 
Test failed for the following classes: …

Right now the test has:
 * @run main/othervm -Djdk.launcher.addmods=ALL-SYSTEM FieldSetAccessibleTest 
UNSECURE
Changing it to 
 * @run main/othervm -addmods ALL-SYSTEM FieldSetAccessibleTest UNSECURE
yields the same results.

I was thinking that the Jake integration would change something, but I see the 
same behavior as before.

Shura

> 
> -Alan

Re: RFR: JDK-8151914 java/util/jar/JarFile/MultiReleaseJar* tests do not declare module dependences

[Chris Hegarty]

On 2 May 2016, at 22:48, Steve Drach  wrote:

> Looks fine to me,

+1.

-Chris.

> although I am not an official reviewer.  Thanks for doing this.
> 
>> On May 2, 2016, at 1:03 PM, Alexandre (Shura) Iline 
>>  wrote:
>> 
>> Hi,
>> 
>> Can you please take a look on:
>> http://cr.openjdk.java.net/~shurailine/8151914/webrev.01/
>> ?
>> 
>> Thank you
>> 
>> Shura
>> 
> 

Re: RFR: JDK-8151914 java/util/jar/JarFile/MultiReleaseJar* tests do not declare module dependences

[Steve Drach]

Looks fine to me, although I am not an official reviewer.  Thanks for doing 
this.

> On May 2, 2016, at 1:03 PM, Alexandre (Shura) Iline 
>  wrote:
> 
> Hi,
> 
> Can you please take a look on:
> http://cr.openjdk.java.net/~shurailine/8151914/webrev.01/
> ?
> 
> Thank you
> 
> Shura
> 

Re: Overriding requirements of 3rd party modules

[Alan Bateman]

On 03/05/2016 13:46, Gunnar Morling wrote:

Hi,

While looking into Jigsaw-enabling some existing code, I came across the
following use case for which I'm seeking advice on how to deal with.

Consider a 3rd party library that contains JPA entities. Application
developers will include that library into their app and work with its
entities as part of their model. The library author doesn't know which JPA
provider will be used (Hibernate, EclipseLink etc.), so the library should
work with any compatible provider.

Now the different providers all have their own JPA API Jar. Thus in the
module-info.java of the library, there'd be a "requires" clause to one of
the API Jars (e.g. "hibernate-jpa-2.1-api") for compiling and testing the
library.

But users of the lib might want to use *another* JPA provider and hence
  API Jar for their app. What's Jigsaw's approach for letting the user deal
with that? I.e. how could the user override the requirement of the lib in
order to work with the provider of their choice?

I vaguely remember a concept of "module aliases" in earlier drafts which
might have been used for that (for instance, all the different API Jars
could act as "jpa-2.1"), but I cannot seem to find that in the current docs
anymore.

The early exploration phase did have some support for aliasing 
(`provides jpa` for example). This is not in the current design.


An alternative is to use services of course, say where there is one API 
module and a service provider interface to allow the implementation be 
plugged in. The current design (with `uses` and `provides`) leads itself 
very well to this type of loose coupling. We have many examples in Java 
SE and the JDK. Sorry I don't know JPA too well to know whether this 
applies or not but I do see a javax.persistence.spi package that looks 
like it supporting plugging in alterative implementations.


-Alan

Overriding requirements of 3rd party modules

[Gunnar Morling]

Hi,

While looking into Jigsaw-enabling some existing code, I came across the
following use case for which I'm seeking advice on how to deal with.

Consider a 3rd party library that contains JPA entities. Application
developers will include that library into their app and work with its
entities as part of their model. The library author doesn't know which JPA
provider will be used (Hibernate, EclipseLink etc.), so the library should
work with any compatible provider.

Now the different providers all have their own JPA API Jar. Thus in the
module-info.java of the library, there'd be a "requires" clause to one of
the API Jars (e.g. "hibernate-jpa-2.1-api") for compiling and testing the
library.

But users of the lib might want to use *another* JPA provider and hence
 API Jar for their app. What's Jigsaw's approach for letting the user deal
with that? I.e. how could the user override the requirement of the lib in
order to work with the provider of their choice?

I vaguely remember a concept of "module aliases" in earlier drafts which
might have been used for that (for instance, all the different API Jars
could act as "jpa-2.1"), but I cannot seem to find that in the current docs
anymore.

Thanks,

--Gunnar

hg: jigsaw/jake/jdk: Fix typo

[chris . hegarty]

Changeset: 42007c6589fc
Author:chegar
Date:  2016-05-03 11:07 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/42007c6589fc

Fix typo

! src/java.base/share/classes/java/lang/reflect/Module.java