Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Java9/Use cases"

m
 
(38 intermediate revisions by 3 users not shown)
Line 1: Line 1:
We will write down user scenarios and use cases related to Java modules here that will eventually become part of existing features or new features.
+
Once Java 9 Support is installed, the following are the features that will be supported - These features are in different stages of completion as indicated against the individual items.
 +
More elaborate examples can be found here https://wiki.eclipse.org/Java9/Examples
  
 +
== Add a Java 9 JRE ==
 +
* Use Eclipse Preferences -> Java -> Installed JREs -> Add to add the Java 9 JRE
 
== Creation of module-info ==
 
== Creation of module-info ==
*User manually creates a module-info, similar to package-info.
+
* Context Menu of src -> New -> File - give the module-info.java as name - no compiler errors.  
**The created module info has just the module name and an empty body.
+
* picks up the modules used by project and populates the module-info
*A new wizard/dialogue to create a blank module-info or to create one from the existing project
+
* Context Menu of Project -> Cofigure -> Create module-info. A default module-info.java with all packages exported should be created - no compiler errors.
**Wizard pulls out all the packages in the project (sources only) across all source folders
+
* If the project has a MANIFEST.MF, it should use that information (x-internal, x-friends, reexport, etc.)
and also picks up the modules used by project and populates the module-info
+
* Make sure that the Java build is updated, i.e. org.eclipse.jdt.MODULE_PATH is added automatically
 +
 
 +
== Manipulation of module-info ==
 +
* change module-info in all possible ways, e.g. add/remove modules and packages
 +
* verify that reconciler (problems while typing), the markers after save, and the Module Source Path container is updated
 +
* have a way to see the module target platform
 +
 
 +
== Search ==
 +
*[The work is in progress - currently, packages and types are found in the module-info.java file]
 +
* The search scope should be decided appropriately.
 +
* May think of putting a configurable button "find in module-info.java" as applicable for the constructs - use case of this to be discussed.
 +
* Selection based search from module-info.java file
 +
 
 +
== DOM AST ==
 +
*[status : done from JDT Core; jdt ui internal ast level bump up expected]
 +
* {{bug|496123}} New elements created for module-info.java constructs in DOM/AST one each for the exports, opens, requires, provides and uses.
 +
* bug {{bug|506430}} for formatting is a consumer of AST [ status: in progress]
  
 
== Completion  ==
 
== Completion  ==
*Completions offered on all keywords depending on context (for e.g. exports 'to', provides 'with')
+
* Keyword completions such as exports, opens, requires, provides, uses and to in exports.
*Completions offered on all packages and types depending on the scope and context (scopes being discused in bug {{bug|507288}})
+
* completion on package references in exports, opens, provides and uses.
*Compiler allows/rejects packages and types depending on scope and context.
+
* Type reference completions uses, provides-interface and provides-implementations (implementation sensitive to interfaces as well)
+
* Module reference completions in targeted exports and requires
 +
* Tracked via {{bug|486988}}
 +
 
 
== Quick assist ==
 
== Quick assist ==
*Fill in
+
* Fill in
+
 
 
== Quick fix ==
 
== Quick fix ==
 
*Unresolved package in 'exports'
 
*Unresolved package in 'exports'
Line 29: Line 50:
 
 
 
== Hover ==
 
== Hover ==
*Hover on module names (the whole name, not just fragements) should display the module name
+
[status: in progress]
**When and if the spec allows Javadoc, then the documenation should be displayed in the hover
+
*Hover on module names (the whole name, not just fragments) should display the module name
 +
**Dani: I question how useful this is if we don't show any additional information than what's already in the editor.
 +
***Jay:That's not what I really meant. I just meant that's what happens as default behavior without any Javdoc on that element.
 +
***Dani:Yes, but see next item. Currently it's only the name I think. That was my point. As soon as we have Javadoc, it makes perfect sense.
 +
**When and if the spec allows Javadoc, then the documentation should be displayed in the hover
 +
**PROBLEM: Modules shipped with Java 9 currently don't come with module-info.java in the src.zip
 
*Hover on all package and type names should work like everywhere else.
 
*Hover on all package and type names should work like everywhere else.
+
 
 
== Code navigation ==
 
== Code navigation ==
 +
[status: in progress]
 
*Action on module should open the module-info.java or module-info.class
 
*Action on module should open the module-info.java or module-info.class
 
*Action on package names should open the package-info if present.
 
*Action on package names should open the package-info if present.
*Action on any types, should open the type, even those in other modules than the current one.
+
*Action on any types, should open the type, even those in other modules than the current one - done
+
 
== Using legacy Jar files in a module project ==
+
== Using legacy JAR files in a module project ==
*Legacy Jar files or class folders continue to be supported by Java module projects. To be able to use them, the user
+
*Legacy JAR files or class folders continue to be supported by Java module projects. To be able to use them, the user
adds the path to the build path, as he normally would. In addition to that, he can choose to tell the compiler whether or not promote a Jar as automatic modules. The compiler seems an automatic module differently from an unnamed module. The IDE should allow the user to do this ({{bug|506878}})
+
adds the path to the build path, as he normally would. In addition to that, he can choose to tell the compiler whether or not promote a JAR as automatic modules. The compiler seems an automatic module differently from an unnamed module. The IDE should allow the user to do this ({{bug|506878}} & {{bug|508708}})
*Similar support would be provided in command line compiler as well, but the distinction between automatic and unnamed modules is made based on where the Jar path is found, in the -modulepath or -classpath.
+
*Similar support would be provided in command line compiler as well, but the distinction between automatic and unnamed modules is made based on where the JAR path is found, in the -modulepath or -classpath.
  
 
== Outline View ==
 
== Outline View ==
 
*Add more here
 
*Add more here

Latest revision as of 04:08, 5 January 2018

Once Java 9 Support is installed, the following are the features that will be supported - These features are in different stages of completion as indicated against the individual items. More elaborate examples can be found here https://wiki.eclipse.org/Java9/Examples

Add a Java 9 JRE

  • Use Eclipse Preferences -> Java -> Installed JREs -> Add to add the Java 9 JRE

Creation of module-info

  • Context Menu of src -> New -> File - give the module-info.java as name - no compiler errors.
  • picks up the modules used by project and populates the module-info
  • Context Menu of Project -> Cofigure -> Create module-info. A default module-info.java with all packages exported should be created - no compiler errors.
  • If the project has a MANIFEST.MF, it should use that information (x-internal, x-friends, reexport, etc.)
  • Make sure that the Java build is updated, i.e. org.eclipse.jdt.MODULE_PATH is added automatically

Manipulation of module-info

  • change module-info in all possible ways, e.g. add/remove modules and packages
  • verify that reconciler (problems while typing), the markers after save, and the Module Source Path container is updated
  • have a way to see the module target platform

Search

  • [The work is in progress - currently, packages and types are found in the module-info.java file]
  • The search scope should be decided appropriately.
  • May think of putting a configurable button "find in module-info.java" as applicable for the constructs - use case of this to be discussed.
  • Selection based search from module-info.java file

DOM AST

  • [status : done from JDT Core; jdt ui internal ast level bump up expected]
  • bug 496123 New elements created for module-info.java constructs in DOM/AST one each for the exports, opens, requires, provides and uses.
  • bug bug 506430 for formatting is a consumer of AST [ status: in progress]

Completion

  • Keyword completions such as exports, opens, requires, provides, uses and to in exports.
  • completion on package references in exports, opens, provides and uses.
  • Type reference completions uses, provides-interface and provides-implementations (implementation sensitive to interfaces as well)
  • Module reference completions in targeted exports and requires
  • Tracked via bug 486988

Quick assist

  • Fill in

Quick fix

  • Unresolved package in 'exports'
    • Offer to create the package?
  • Unresolved type in 'with' clause
    • Offer to create an empty type that implements the mentioned service.
  • Unresolved type in 'provides' clause
    • ?
  • 'with' does not implement 'provides'
    • Offer to make the implementation implement the interface
  • Unresolved import or type in a class
    • Offer to add the module to 'requires' clause

Hover

[status: in progress]

  • Hover on module names (the whole name, not just fragments) should display the module name
    • Dani: I question how useful this is if we don't show any additional information than what's already in the editor.
      • Jay:That's not what I really meant. I just meant that's what happens as default behavior without any Javdoc on that element.
      • Dani:Yes, but see next item. Currently it's only the name I think. That was my point. As soon as we have Javadoc, it makes perfect sense.
    • When and if the spec allows Javadoc, then the documentation should be displayed in the hover
    • PROBLEM: Modules shipped with Java 9 currently don't come with module-info.java in the src.zip
  • Hover on all package and type names should work like everywhere else.

Code navigation

[status: in progress]

  • Action on module should open the module-info.java or module-info.class
  • Action on package names should open the package-info if present.
  • Action on any types, should open the type, even those in other modules than the current one - done

Using legacy JAR files in a module project

  • Legacy JAR files or class folders continue to be supported by Java module projects. To be able to use them, the user

adds the path to the build path, as he normally would. In addition to that, he can choose to tell the compiler whether or not promote a JAR as automatic modules. The compiler seems an automatic module differently from an unnamed module. The IDE should allow the user to do this (bug 506878 & bug 508708)

  • Similar support would be provided in command line compiler as well, but the distinction between automatic and unnamed modules is made based on where the JAR path is found, in the -modulepath or -classpath.

Outline View

  • Add more here

Back to the top