Re: none of our software actually functions

[David M. Lloyd]

On 05/04/2016 02:46 PM, Alan Bateman wrote:


On 04/05/2016 19:33, David M. Lloyd wrote:

Tools like Maven and JUnit are yet still having a difficult time
coping with the oddball module-info.java file.

Has been discussion on the JUnit tests about this? Aside from a few
usability issues then I haven't seen any issues with JUnit, it seems to
work just fine on class path or the module path as an automatic module.


Integration with Maven is the real problem in this case, I guess.


So far none of our software actually functions with Jigsaw, and the
prospect is not improving.

Can you expand a bit on this? Is this code that runs on JDK 8 but
doesn't run on JDK 9? Or maybe you mean that you or someone is migrating
some libraries or a complete stack to modules?


Mainly I'm referring to the unresolved issues at 
http://openjdk.java.net/projects/jigsaw/spec/issues/.  As yet I see no 
evidence of activity from Mark nor anyone in the Jigsaw development on 
any of these issues - no discussion, no response to discussion, nothing. 
 Not even rejection, just radio silence.


To be specific we need resolution to at least #ModuleNameCharacters, 
#CyclicDependences, #LazyConfigurationAndInstantiation, 
#MutableConfigurations, #ClassFilesAsResources, #VersionSyntax, and 
#NonHierarchicalLayers for sure, in order for our system to interoperate 
with Jigsaw (as opposed to trying to pretend it doesn't exist and won't 
come back and bite us for Java EE 9).  I think I can squeak out some 
simple changes that disable version and module name syntax validation 
for the simpler two, maybe even moving the existing rules in to the 
system layer, but the rest require some real design thinking and 
discussion, and I don't think I will have access to the resources needed 
to contribute fixes to these without help from the Jigsaw team.


With the various SE 9 deadlines looming large, how realistic is it to 
expect that even some of these issues will ultimately be resolved?

--
- DML

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

[Mandy Chung]

> On Apr 13, 2016, at 10:29 AM, 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/

Looks okay.  Some suggestion:

You only need to walk one root:
   root = fs.getPath("/modules”)

and instead of caching the available modules, you could
   .filter(x -> Layer.boot().findModule(x.getName(1).toString())).isPresent()

I can sponsor your patch - please send me the changeset.

Mandy

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

[Alan Bateman]

On 03/05/2016 20:43, Alexandre (Shura) Iline wrote:

:
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.

You are right, running it with `-limitmods java.base` will limit the 
observability to just java.base and so`-addmods ALL-SYSTEM` is 
essentially a no-op because "all system" will be java.base in this case. 
I've looked at the changes in the webrev and they look fine, sorry for 
delaying you on this one.


-Alan

Re: none of our software actually functions

[Alan Bateman]

On 04/05/2016 19:33, David M. Lloyd wrote:
Tools like Maven and JUnit are yet still having a difficult time 
coping with the oddball module-info.java file.
Has been discussion on the JUnit tests about this? Aside from a few 
usability issues then I haven't seen any issues with JUnit, it seems to 
work just fine on class path or the module path as an automatic module.



:

So far none of our software actually functions with Jigsaw, and the 
prospect is not improving.
Can you expand a bit on this? Is this code that runs on JDK 8 but 
doesn't run on JDK 9? Or maybe you mean that you or someone is migrating 
some libraries or a complete stack to modules?


-Alan

Re: module-info.java just causes problems

[Paul Benedict]

It's tough to rehash issues. I don't want to re-open old discussions that
go nowhere, yet, I still share David's concerns. Personally, I was very
jealous :-) of the proprietary module.xml the initial jigsaw system had. I
liked the XML way better and still do.

Cheers,
Paul

On Wed, May 4, 2016 at 1:33 PM, David M. Lloyd 
wrote:

> Tools like Maven and JUnit are yet still having a difficult time coping
> with the oddball module-info.java file.  Can we just drop this thing and
> let the layer provide metadata for the module?  This way of defining module
> metadata is clearly causing trouble.  Reference: all previous arguments
> from non-Oracle people over the last 5 years or so.
>
> So far none of our software actually functions with Jigsaw, and the
> prospect is not improving.  In the meantime the EG is alternately
> completely dead or in a state of
> we'll-register-your-issue-but-cannot-help-resolve-them mode.  I'm highly
> concerned.
> --
> - DML
>

module-info.java just causes problems

[David M. Lloyd]

Tools like Maven and JUnit are yet still having a difficult time coping 
with the oddball module-info.java file.  Can we just drop this thing and 
let the layer provide metadata for the module?  This way of defining 
module metadata is clearly causing trouble.  Reference: all previous 
arguments from non-Oracle people over the last 5 years or so.


So far none of our software actually functions with Jigsaw, and the 
prospect is not improving.  In the meantime the EG is alternately 
completely dead or in a state of 
we'll-register-your-issue-but-cannot-help-resolve-them mode.  I'm highly 
concerned.

--
- DML

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

[Alexandre (Shura) Iline]

This makes sense - I will move the tests into a subduer, put the dependencies 
into a TEST.properties file.

jdk.zipfs has the code needed for access jars - the tests are failing without 
that dependency.

Shura
> On May 4, 2016, at 8:30 AM, Chris Hegarty  wrote:
> 
> On 4 May 2016, at 14:32, Alan Bateman  wrote:
>> 
>> On 04/05/2016 11:24, Chris Hegarty wrote:
>>> :
>>> The tests cause compilation of test library classes, but only some tests
>>> actually use the methods that provoke compilation. Similar to above, tests
>>> that don’t actually compile anything could depend on just java.compiler.
>>> 
>>> This is all to fragile and may cause problems with future refactoring. I
>>> think we should add the same set of @moduels to all these tests, rather
>>> than an individual set determined by intimate knowledge of the inner
>>> workings of the test.
>>> 
>>> @modules java.compiler
>>>   jdk.compiler
>>>   jdk.zipfs
>>>   jdk.jartool
>>> 
>>> with the addition of jdk.httpserver for MultiReleaseJarHttpProperties.
>>> 
>> or we could move the tests into their own MultiRelease sub-directory and 
>> create a TEST.properties with a module key. That would allow these tests to 
>> drop @modules, except the test that uses the HTTP server.
> 
> I think that would be better.
> 
> -Chris.

Re: RFR: JDK-8155649: IncludeLocalesPlugin throws NPE when jdk.localedata not resolved

[Naoto Sato]

Thanks, Alan.

I thought of the same for en_US w/o jdk.localedata case, and reached the 
same conclusion.


I found one typo in my fix, where "-addmods" in plugins.properties 
should be "--addmods". I will correct it and push the changeset.


Naoto

On 5/4/16 3:03 AM, Alan Bateman wrote:

On 04/05/2016 00:33, Naoto Sato wrote:

Hi,

Please review the fix for the following issue:

https://bugs.openjdk.java.net/browse/JDK-8155649

The proposed fix is located at:

http://cr.openjdk.java.net/~naoto/8155649/webrev.00/

This looks okay. There is a corner case where it should be possible to
--include-locales to specify en_US and it should always succeed but I
don't think that is worth spending time on.

-Alan

Re: RFR 8155088, Fix module dependencies in java/sql/* and javax/* tests

[Alan Bateman]

On 04/05/2016 15:39, Felix Yang wrote:

Hi Alan,

please review the updated webrev. Reverted changes for those tests 
with "-addmods".


http://cr.openjdk.java.net/~xiaofeya/8155088/webrev.01/
For the javax.transaction test then don't you also add 
"java.transaction" in the @modules value? The rest looks fine.


-Alan

Re: RFR 8155088, Fix module dependencies in java/sql/* and javax/* tests

[Felix Yang]

Hi Alan,

please review the updated webrev. Reverted changes for those tests 
with "-addmods".


http://cr.openjdk.java.net/~xiaofeya/8155088/webrev.01/

Thanks,
Felix
On 2016/4/29 15:25, Alan Bateman wrote:

On 29/04/2016 03:16, Felix Yang wrote:

Hi there,

please review the changes to explicitly declare module 
dependencies for "java/sql/*" and "javax/*" tests;


Bug: https://bugs.openjdk.java.net/browse/JDK-8155088

Webrev: http://cr.openjdk.java.net/~xiaofeya/8155088/webrev.00/
Felix - would it be disruptive to you if I asked to hold off on this 
until we get the changes in jake pushed to jdk9/dev (next week). The 
reason is that this we've changed most of these tests in jake to use 
-addmods. We've also replaced the TEST.properties for the 
javax.transaction tests so that they are run with a driver class 
instead. This is also related to the policy for root modules which 
impacts the tests that we have for the EE modules in the jdk repo.


-Alan

Re: Modules with packages duplication

[Alan Bateman]

On 04/05/2016 14:18, Konstantin Barzilovich wrote:

Hello,

I can see that RI checks if there are packages with the same names in 
different modules (named or unnamed).
This check fails even if there is no clash (no module can read both 
packages).

Will it be the same in final version of JDK9 or it can be changed soon?

I think you are asking about modules on the application module path 
(`java -modulepath ...`) that are resolved at startup. These are defined 
to the application class loader so they cannot have overlapping 
packages. It's trivial to do things like map each module in its own 
class loader but that messes with visibility with lots of implications 
(particularly when running with both a class path and module path or 
where you bringing automatic modules into the picture). So what you are 
seeing is specific to the boot Layer and no specific short term plans to 
change this.


-Alan

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

[Alan Bateman]

On 04/05/2016 11:24, Chris Hegarty wrote:

:
The tests cause compilation of test library classes, but only some tests
actually use the methods that provoke compilation. Similar to above, tests
that don’t actually compile anything could depend on just java.compiler.

This is all to fragile and may cause problems with future refactoring. I
think we should add the same set of @moduels to all these tests, rather
than an individual set determined by intimate knowledge of the inner
workings of the test.

  @modules java.compiler
jdk.compiler
jdk.zipfs
jdk.jartool

with the addition of jdk.httpserver for MultiReleaseJarHttpProperties.

or we could move the tests into their own MultiRelease sub-directory and 
create a TEST.properties with a module key. That would allow these tests 
to drop @modules, except the test that uses the HTTP server.


-Alan

Modules with packages duplication

[Konstantin Barzilovich]

Hello,

I can see that RI checks if there are packages with the same names in  
different modules (named or unnamed).
This check fails even if there is no clash (no module can read both  
packages).

Will it be the same in final version of JDK9 or it can be changed soon?

--
Thanks,
Konstantin.

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

[Alan Bateman]

On 04/05/2016 09:40, Chris Hegarty wrote:

On 3 May 2016, at 16:10, Chris Hegarty  wrote:


Can you please take a look on:
http://cr.openjdk.java.net/~shurailine/8151914/webrev.01/

Taking another look over this before sponsoring….

The test library dependency seems to be on java.compiler, and not jdk.compiler,
right ?  Also, I see no reason for the addition of jdk.zipfs.

java.compiler is just the API module, the runtime image needs to have 
jdk.compiler linked in to be useful. So I think @modules jdk.compiler is 
right here as otherwise the test will be selected when testing a "JRE". 
java. javac needs the zipfs provider in order to compiler against 
libraries that are packaged as JAR/zip files so I assume this is why it 
listed here.


-Alan.

Re: RFR: JDK-8155649: IncludeLocalesPlugin throws NPE when jdk.localedata not resolved

[Alan Bateman]

On 04/05/2016 00:33, Naoto Sato wrote:

Hi,

Please review the fix for the following issue:

https://bugs.openjdk.java.net/browse/JDK-8155649

The proposed fix is located at:

http://cr.openjdk.java.net/~naoto/8155649/webrev.00/
This looks okay. There is a corner case where it should be possible to 
--include-locales to specify en_US and it should always succeed but I 
don't think that is worth spending time on.


-Alan

Re: Overriding requirements of 3rd party modules

[Alan Bateman]

On 04/05/2016 09:20, Emmanuel Bernard wrote:

:
JPA uses the service loader pattern to find the list of implementations.
But what Gunnar is describing is a concern of the API module itself.

For reasons related to history, license, copyright openness concerns and
code maintenance, there are several alternative incarnations of JSR APIs
floating around. They are all sig compliant as per the TCK but they have
different Maven GAVs

For JPA at the very least, there is the Oracle and Red Hat version. I'm
pretty sure Apache has its own too. So if the third party module Gunnar
mentions does use the hibernate version (which its own name), there is
no way for the third party module user to override this decision and use
the Oracle one.

I don't know how/when Java EE will embrace modules but I would expect 
that module names will be chosen and that the module name, exports, etc. 
will become part of the TCK signature test.


In the case of JPA then it might be "module java.persistence" where 
compliant implementations will have a declaration like this:


module java.persistence {
exports javax.persistence;
exports javax.persistence.criteria;
exports javax.persistence.metamodel;
exports javax.persistence.spi

uses javax.persistence.spi.PersistenceProvider;
:
}

When you have an explicit module then it doesn't matter how the artifact 
is named, the group/artifact/version in Maven isn't relevant to the 
module system either.


I realize that we are in somewhat of a void at the moment in that there 
aren't Java EE modules yet but cases like this, where they are several 
different copies of the API classes, then maybe the folks involved could 
come together with the spec lead for the API and agree the module name.


-Alan

Re: Overriding requirements of 3rd party modules

[Gunnar Morling]

Note that this is not a requirement specific only to JPA.

There are more cases where reusable components obtain a package from module
A at their own build time (and thus would declare requirements in
module-info.java accordingly) but need to work with the same package
provided by another module B when being part of a downstream application.

For instance there is the "stripped" javaee-api-7.0.jar which can be used
for compiling a module against the complete Java EE API (and thus seems
reasonable as requirement in module-info.java). But this JAR contains no
actual method implementations at all, instead the same packages must be
provided from other sources when executing a module compiled against it as
part of a downstream application.

Or consider the case of logging (abstractions). Suppose a library depends
on Commons Logging (JCL). An application using the library might wish to
work with slf4j though for a unified logging experience. For that purpose
slf4j provides a JCL-over-slf4j bridge. This is a drop-in replacement for
JCL, re-implementing the JCL packages but using slf4j and its configured
backend underneath. In such scenario the application developer would need
to override the requirement of the lib to JCL with the slf4j-based bridge.

I agree that in theory it'd be nice if there was a canonical source for
each package which then uses the service loader to bootstrap specific
implementations. But in practice we are not there. There may be several
providers of the same package (as in the case of JPA), or a package doesn't
foresee different implementations and thus should be replaceable with a
compatible alternative (the logging bridge example).

Thus it's my believe that it is vital for the module system to provide
application developers with means of overriding module requirements of
their dependencies with (package-compatible) alternatives.




2016-05-04 10:20 GMT+02:00 Emmanuel Bernard :

> On Tue 2016-05-03 14:45, Alan Bateman wrote:
> > 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.
>
> JPA uses the service loader pattern to find the list of implementations.
> But what Gunnar is describing is a concern of the API module itself.
>
> For reasons related to history, license, copyright openness concerns and
> code maintenance, there are several alternative incarnations of JSR APIs
> floating around. They are all sig compliant as per the TCK but they have
> different Maven GAVs
>
> For JPA at the very least, there is the Oracle and Red Hat version. I'm
> pretty sure Apache has its own too. So if the third party module Gunnar
> mentions does use the hibernate version (which its own name), there is
> no way for the third party module user to override this decision and use
> the Oracle one.
>
> Hope that clarifies.
>
> emmanuel
>

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

[Chris Hegarty]

On 3 May 2016, at 16:10, Chris Hegarty  wrote:

>>> 
>>> Can you please take a look on:
>>> http://cr.openjdk.java.net/~shurailine/8151914/webrev.01/

Taking another look over this before sponsoring….

The test library dependency seems to be on java.compiler, and not jdk.compiler,
right ?  Also, I see no reason for the addition of jdk.zipfs.

-Chris.

Re: Overriding requirements of 3rd party modules

[Emmanuel Bernard]

On Tue 2016-05-03 14:45, Alan Bateman wrote:
> 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.

JPA uses the service loader pattern to find the list of implementations.
But what Gunnar is describing is a concern of the API module itself.

For reasons related to history, license, copyright openness concerns and
code maintenance, there are several alternative incarnations of JSR APIs
floating around. They are all sig compliant as per the TCK but they have
different Maven GAVs

For JPA at the very least, there is the Oracle and Red Hat version. I'm
pretty sure Apache has its own too. So if the third party module Gunnar
mentions does use the hibernate version (which its own name), there is
no way for the third party module user to override this decision and use
the Oracle one.

Hope that clarifies.

emmanuel