JDK-8178015 : Clarify requirement for app modules to export/open packages to javafx modules
  • Type: Bug
  • Component: javafx
  • Sub-Component: other
  • Affected Version: 9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2017-04-03
  • Updated: 2017-04-21
  • Resolved: 2017-04-21
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 9
9Fixed
Related Reports
Relates :  
JDK-8177751 - Update FX implementation to prepare for renaming of Module and Layer classes
Relates :  
JDK-8178281 - Remove @link reference to Module class until boot JDK is updated
Description
This is a follow-on issue to JDK-8177751 which was done to prepare FX for the moving of java.lang.reflect.Module and java.lang.reflect.Layer to java.lang. Because we had to ensure that the existing JDK (with those classes in their old location) could compile JavaFX, all direct references to those classes were removed. This included temporarily removing two @link references to Module in the FX API docs.

Once the move of Module and Layer to java.lang is complete, and we update our boot JDK to use that build, we can restore those two @link directives.
Comments
Changeset: df50d26b702f Author: kcr Date: 2017-04-21 05:23 -0700 URL: http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/df50d26b702f 8178015: Clarify requirement for app modules to export/open packages to javafx modules Reviewed-by: prr, mchung, alanb
21-04-2017
At Alan's suggestion, I made one more minor change to remove the alternative suggestion of "open"ing the package containing the Application sub-class to javafx.graphics: diff --git a/modules/javafx.graphics/src/main/java/javafx/application/Application.java b/modules/javafx.graphics/src/main/java/javafx/application/Application.java --- a/modules/javafx.graphics/src/main/java/javafx/application/Application.java +++ b/modules/javafx.graphics/src/main/java/javafx/application/Application.java @@ -90,9 +90,7 @@ * {@link Module#isExported(String,Module) export} the containing package to * at least the {@code javafx.graphics} module, either in its * {@code module-info.class} or by calling - * {@link Module#addExports}. Alternatively, the module can - * {@link Module#isOpen(String,Module) open} the containing package to at least - * the {@code javafx.graphics} module. + * {@link Module#addExports}. * </p> * <p> * For example, if the {@code Application} subclass is in the {@code com.foo} webrev that matches this change is here: http://cr.openjdk.java.net/~kcr/8178015/webrev.03/
21-04-2017
Updated webrev with a few suggested wording changes (e.g., removed the reference to ModuleDescriptor, changed "accessible by" back to "accessible to"). http://cr.openjdk.java.net/~kcr/8178015/webrev.02/ Additionally, I removed the example in the FXML annotation showing the use of "opens to" in module-info.java (but left the example in Application).
20-04-2017
+1 -phil.
18-04-2017
Updated webrev incorporating feedback on the openjfx-dev list: http://cr.openjdk.java.net/~kcr/8178015/webrev.01/
18-04-2017
Webrev: http://cr.openjdk.java.net/~kcr/8178015/webrev.00/ Restores the links and makes the requirements for an application in a named module more clear. Also fixes a couple related typos in the modified paragraphs.
17-04-2017
Regarding the following sentence in Application class: "The Application subclass must be declared public, must have a public no-argument constructor, and the containing package must be exported (see Module.isExported(String,Module)) to the javafx.graphics module." Alan had the following suggestion: "I wonder if we can split this so that it is clear that if the application is deployed as a module then the Application sub-class must be in a package that is exported to at least the javafx.graphics module. Also given that the javadoc already has a bunch of headers (Life-cycle, Parameters, ...) then maybe deploying as a module could be its own header/section so that it stands out a bit more." I'll fix this to be more clear as part of this JBS issue, since I will be modifying it anyway.
17-04-2017
Note that we also need to wait until the EA docs [1] are updated with the docs from build 165. [1] http://download.java.net/java/jdk9/docs/api/overview-summary.html
13-04-2017