Re: Java Platform Module System

[Alex Buckley]

On 4/27/2017 12:38 PM, Stephan Herrmann wrote:

On 25.04.2017 19:02, Alex Buckley wrote:

JPMS semantics (notably, dependency resolution) are defined by the API
specification (not the implementation) of
java.lang.module.Configuration and friends. JLS references to JPMS are
references to this Java SE API.


Got it. Since now JLS is no longer self-contained it would tremendously
help if we could get a list of which parts of the API specification are
expected to be considered at compile time. I understand that we need to
apply the naming rules for automatic modules. Is there more that should
be respected / validated / enforced at compile time?


The JLS was never self-contained as it always referenced a variety of 
java.lang and java.io types (and more recently java.lang.annotation and 
java.lang.invoke types). I have changed 7.3 to state:


"The host system must use the Java Platform Module System (as if by 
execution of the 'resolve' method of java.lang.module.Configuration) to 
determine which modules are read by M (§7.7.1). It is a compile-time 
error if the Java Platform Module System is unable to determine which 
modules are read by M."


That is, if a compiler processes a module declaration mentioning 
"requires X;", and the "as if" JPMS resolution fails because no module 
called "X" is found (whether an explicitly declared module with that 
name, or an implicitly declared i.e. automatic module with that name), 
then compilation fails too. The mapping from a JAR filename to an 
implicitly declared i.e. automatic module name is part of JPMS 
resolution. And even if a module called "X" is found, there are other 
reasons why JPMS resolution (and hence compilation) can fail, e.g. the 
module requiring X also requires Y and both X and Y export the same 
package. The JLS, as is traditional, allows a compiler to be as helpful 
or as terse as it likes w.r.t. the content of the compile-time error 
message.



Let me add a friendly reminder, that we are still waiting for a
specification that unambiguously tells us which module system to implement.
For illustration:

(A) Is JPMS a module system that keeps the semantics of qualified names as
they are in Java 8 and only superimposes encapsulation boundaries?
(i.e., each type is globally uniquely identified by its qualified name).

(B) Is JPMS a module system that maintains the assumption that from the
perspective of each module all relevant types can be distinguished using
their qualified name?
(i.e. admitting identical qualified names as long as no compilation of one
module will ever encounter several candidates at once).

(C) Is JPMS a module system that establishes a separate namespace for each
module, where types with identical qualified name - but defined in
different modules - need to be distinguished?
(i.e., uniqueness is primarily required for module-prefixed qualified
names).

Despite some efforts I fail to find a definite answer in JLS (and Alex
mentioned that some of this is still being discussed). Still JLS as of
today sounds mostly like (A). To me (B) sounds like the natural choice, but I
understood Alex as saying it *should* be (C). I don't see, however, how the
conceptual framework of JLS could possibly support such design.


(B) and (C) are not mutually exclusive because (B) was worded from the 
perspective of each module while (C) was not.


(B) is true. Assume two modules M and N each contain the type P.C, but 
neither module exports P (or, M exports P and N doesn't, or, N exports P 
and M doesn't). Then, a third module O can require M and N. If code in 
any module refers statically to a type P.C, then JPMS resolution 
guarantees that P.C is either defined by that module or is exported to 
the module by exactly one other module which the module reads.


At run time, when 'java' is run with M+N+O on the modulepath, the system 
will stop -- M+N+O will pass resolution (i.e. a Configuration will be 
constructed) but they can't all be mapped to the application class 
loader. javac will produce a lint warning to this effect. However, M and 
N and O are by no means "bad" modules, either individually or jointly, 
as M+N+O will work if mapped to a multi-loader layer. So, (C) is true too.


The JLS, as is traditional with classes and packages, does not restrict 
the modules which can be given as input for an invocation of a compiler. 
A compiler is assumed to be able to process multiple modules at once. In 
the case of M and N, a compiler will encounter P.C in M and P.C in N, 
and is expected to distinguish them -- code in M refers to P.C in M 
while code in N refers to P.C in N. This (C)-style property is now 
expressed in 4.3.4:


"Two reference types are the same compile-time type if they are declared 
in compilation units associated with the same module (§7.3), and they 
have the same binary name (§13.1), and their type arguments, if any, are 
the same, applying this definition recursively."



PS: I'm also having hard times to imagine, how those 

Re: Issue with JavaFX and Jigsaw

[Kevin Rushforth]

Following up on this thread...

While writing the unit tests and documentation for this it became clear 
to me that it requiring applications to export as public API all 
packages used by FXML, Java Beans, and JavaScript callbacks from WebView 
is not a reasonable requirement.


The fact that we use sun.misc.reflect.MethodUtil.invoke is an 
implementation detail that should not dictate our API specification. As 
such, I have been working on a proposed fix as opposed to just 
documenting the existing limitation and producing a more understandable 
error message.


The fix will allow applications to "open" their package to just the 
javafx.base module (for Java Beans), or the javafx.fxml module (for 
FXML), or the javafx.web module (for JavaScript callbacks). This will 
allow applications to keep their FXML controller, for example, in a 
non-pubilc package, which is as it should be since the FXML controller 
is in almost all cases an implementation detail of the application.


I have a fix that should be ready for review early next week. It will 
also have the more descriptive error message in case the package is not 
open to the javafx module in question.


-- Kevin



On Tue, 11 Apr 2017 at 01:36 Trisha Gee  wrote:

From a user/developer point of view, a more descriptive error message 
would be a big help.  I was completely at a loss to understand why I 
needed to unconditionally export my packages, I figured there was a 
requirement from the JavaFX-side of things but it wasn't clear what it 
was or why. A helpful error plus updated documentation would reduce 
confusion.


On Tue, 11 Apr 2017 at 01:54 Mandy Chung > wrote:


It may be useful to point to the javadoc where it specifies to
require the module to export the packages unconditionally.

It would be a good RFE to relax the exports to at least javafx.beans.

Mandy


On Apr 10, 2017, at 3:56 PM, Kevin Rushforth
>
wrote:

Sorry for the delay in responding.

I added a simple test program to the JBS bug that shows the same
behavior as the application and also an evaluation of the bug.

The short version is that JavaFX beans is (mostly) working as
expected, except for the misleading exception message. In JDK 9
it is required that any object that is reflected on by JavaFX
beans, specifically the items passed to TableView, which are
accessed via a PropertyValueFactory, will need to be in a package
that is exported unconditionally. In JDK 10 we can look into
relaxing this requirement such that the package only needs to be
exported to javafx.beans.

I do think we need to make the exception message less confusing
in JDK 9 and also document the requirement in the appropriate
places (at least in TableView and probably in a couple of
javafx.beans.property.adapter classes).

Comments?

-- Kevin


Mandy Chung wrote:

Hi Trisha,

Thanks for the report and stack trace.  I created
https://bugs.openjdk.java.net/browse/JDK-8177566 for further
investigation.

Mandy


  

On Mar 24, 2017, at 2:34 PM, Trisha Gee  
 wrote:

Hi,

I was chatting to Alex Buckley at DevoxxUS about my experiences migrating a
project to using Java 9 modules (specifically, this project:
https://github.com/trishagee/sense-nine) and mentioned some surprising
behaviour in a module that uses JavaFX.  I've been asked to send the
details so people can take a look at it.

My module-info.java is here:

https://github.com/trishagee/sense-nine/blob/master/src/com.mechanitis.demo.sense.client/module-info.java
Note that I have to export two additional packages (mood and user), and I
did not expect (or really want) to.  This is because I was getting this
error if I did not:

java.lang.reflect.InvocationTargetException
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at

java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at

java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:547)
at

javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplicationWithArgs(LauncherImpl.java:482)
at

javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplication(LauncherImpl.java:381)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at

java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at

java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at 

Re: SecurityManager environments

[Alan Bateman]

On 28/04/2017 19:33, Russell Gold wrote:


:
This only works for executable jars? Not libraries?

That is correct. If the executable JAR has Class-Path attributes then 
whoever is creating the application needs to have a global understanding 
so that the Add-Exports or Add-Opens has the complete list of 
modules/packages to break into.


-Alan

Re: RFR: 8179434: test/java/lang/Class/getDeclaredField/FieldSetAccessibleTest.java fails due to JDK-8177845

[Doug Simon]

> On 28 Apr 2017, at 21:11, Mandy Chung  wrote:
> 
> Looks good.

Thanks for the review.

-Doug

>> On Apr 28, 2017, at 12:05 PM, Doug Simon  wrote:
>> 
>> Please review this small fix for a regression introduced by the change for 
>> https://bugs.openjdk.java.net/browse/JDK-8177845.
>> 
>> http://cr.openjdk.java.net/~dnsimon/8179434/
>> https://bugs.openjdk.java.net/browse/JDK-8179434
>> 
>> -Doug
> 

Re: RFR: 8179434: test/java/lang/Class/getDeclaredField/FieldSetAccessibleTest.java fails due to JDK-8177845

[Mandy Chung]

Looks good.

Mandy

> On Apr 28, 2017, at 12:05 PM, Doug Simon  wrote:
> 
> Please review this small fix for a regression introduced by the change for 
> https://bugs.openjdk.java.net/browse/JDK-8177845.
> 
> http://cr.openjdk.java.net/~dnsimon/8179434/
> https://bugs.openjdk.java.net/browse/JDK-8179434
> 
> -Doug

RFR: 8179434: test/java/lang/Class/getDeclaredField/FieldSetAccessibleTest.java fails due to JDK-8177845

[Doug Simon]

Please review this small fix for a regression introduced by the change for 
https://bugs.openjdk.java.net/browse/JDK-8177845.

http://cr.openjdk.java.net/~dnsimon/8179434/
https://bugs.openjdk.java.net/browse/JDK-8179434

-Doug

Re: SecurityManager environments

[Russell Gold]

> On Apr 6, 2017, at 3:50 AM, Alan Bateman  wrote:
> The Add-Exports and Add-Opens attributes are the executable JAR equivalent of 
> the --add-exports and --add-opens command line options. So if an application 
> is hacking into say sun.awt then the maintainer of the application can shield 
> the users of the application until those issues are fixed. These JAR file 
> attributes are ignored when running on JDK 8.

This only works for executable jars? Not libraries?

hg: jigsaw/jake/jdk: Missing "_" from list not allowed in identifier

[alan . bateman]

Changeset: 67cc686edb03
Author:alanb
Date:  2017-04-28 18:56 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/67cc686edb03

Missing "_" from list not allowed in identifier

! src/java.base/share/classes/jdk/internal/module/Checks.java
! test/java/lang/module/ModuleDescriptorTest.java

hg: jigsaw/jake/hotspot: runtime/modules/JVM* tests failing

[alan . bateman]

Changeset: cb4db673f846
Author:alanb
Date:  2017-04-28 16:36 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/cb4db673f846

runtime/modules/JVM* tests failing

! test/runtime/modules/JVMAddModuleExports.java
! test/runtime/modules/JVMAddModulePackage.java
! test/runtime/modules/JVMDefineModule.java

hg: jigsaw/jake/jdk: 3 new changesets

[alan . bateman]

Changeset: 9313f1d89ca3
Author:alanb
Date:  2017-04-28 14:05 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/9313f1d89ca3

Java identifier validation incomplete

! src/java.base/share/classes/jdk/internal/module/Checks.java
! test/java/lang/module/ModuleDescriptorTest.java

Changeset: a5b44f5b25b5
Author:alanb
Date:  2017-04-28 14:06 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a5b44f5b25b5

--validate-modules usage message should be clearer

! src/java.base/share/classes/sun/launcher/resources/launcher.properties

Changeset: 7865999d80d9
Author:alanb
Date:  2017-04-28 14:12 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7865999d80d9

Drop -Xdiag:resolver

! src/java.base/share/native/libjli/java.c

Re: Can automatic modules be made to work?

[Stephen Colebourne]

On 27 April 2017 at 19:50, Robert Scholte  wrote:
> The returning question is: how can I as a *library builder* participate in
> adopting Jigsaw?

Indeed, the community really wants to help JPMS adoption and add
module metadata. Since bottom up won't work, a mechanism needs to be
provided that enables migration of any jar file, whether its
dependencies have been modularized or not.

> Which made me think of the concept of soft and strict modules. Assuming
> 'strict' is the preferred default, 'soft' or any equivalent alternative
> would be a new keyword which has the same effect as add-reads
> =ALL-UNNAMED, but it's information is available at both compile time
> and runtime.
> With soft modules you can require a subset of modules.

I think that the notions expressed recently of "requires classpath",
"partial requirements", "incomplete/complete modules" [1] and
"strict/soft modules" (above) are all fundamentally the same idea.
Robert expresses a possible underlying mechanism well I think.

I'd envisage an additional keyword, or some other syntax, to mark a
module as not being able to specify all dependencies (because they are
not modules yet):

soft module org.joda.beans {
  requires org.joda.convert;
  // TODO requires guava, revisit when guava is released as a module
}

With this approach, I think JPMS adoption could be quite strong in the
community.

Stephen

[1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-April/012370.html