Re: [jdt-core-dev] Questions on Java 9 Modules API

[Fred Bricon <fbricon@xxxxxxxxx>]

On Tue, Sep 5, 2017 at 4:53 PM, Stephan Herrmann <stephan.herrmann@xxxxxxxxx> wrote:

Hi Fred,

Regarding your previous question: yes: when m2e resolves its
classpath container, it would be good to add the module=true
classpath attribute to each modular entry.
This is the official way for telling JDT that a dependency
should be considered as part of the module path.
Or, would m2e be switched into modular mode entirely and
the module=true attribute should be set on the container entry
in .classpath? This would be your choice, I guess, as typically
that container is added to .classpath by m2e's wizard, right?
Anyway, whatever JDT finds in the resolved container, it will use.

Well m2e could blindly set the module flag for all dependencies (I tried, it works), but that I guess that would kinda defeat the whole purpose of Java 9's modular system. I still need to get more familiar with Java 9 and how it stock Maven deals with it, but there's a good chance some dependencies must not be added to the modulepath, depending on their scope.

 

On 05.09.2017 22:27, Fred Bricon wrote:

Hi,

I'm looking into providing support for Java 9 in m2e.

The way the module path is computed in Maven is via reading module-info.class, or module-info.java first, list all required modules, then iterate over all dependencies in the project classpath, check if a dependency is in the list of required modules, then Maven adds it to the module path.

When a project is configured via m2e, we gather all classpath informations from the Maven in-memory model then try to match that into JDT settings (add Java nature, build Maven classpath container entries from Maven dependencies...)

So, what I'm looking for, to try to reproduce Maven's behavior, is a way to:

1 - get all required modules from a module-info.java file (at that point the project is not a Java project yet), so will most likely rely on some AST parsing

Well, if you have a Java project, JDT provides AST for all its elements,
incl. module-info.java. If you don't (yet) have a Java project, invoking
ASTParser as if in standalone mode, might serve your request. I believe
you need to be sure to tell the ASTParser the file name, so it has a chance
to get restricted keywords right ;p

Thanks, I'll look into it

 

2 - find the module name (either automatic or implicit) of a given jar (from File or Path)

We recently added internal API
   org.eclipse.jdt.internal.compiler.env.AutomaticModuleNaming.determineAutomaticModuleName(String)

If you need this as public API, please file a bug, but obtaining all this
information from a Java project, before it is created sounds weired to me.
I thought all the resolving happens much later, viz. when the configured
classpath container is resolved, no? Do you really need to resolve the
container before you add it to the project??
Shouldn't we be discussing, how to use the Java Model etc. to get this
information, after the Java nature has been added?

AutomaticModuleNaming.determineAutomaticModuleName doesn't return the explicit module name (as defined by module-info.class) so it has little value for us. I'm looking for a more generic ModuleHelper.getModuleName(file or path) kind of API. Whether a module is automatic or not should not be a concern at a higher level. We just need a name.

Dependency resolution occurs before projects are configured, so by the time we hit the Java configurator, all dependencies have been added downloaded to the local Maven repo.

We could of course add the Java nature, set the Maven classpath container, save the classpath and then go back on each classpath entry to tune the module flag, then save the classpath again. Doable but that seems suboptimal.

 

best,
Stephan

--

"Have you tried turning it off and on again" - The IT Crowd

And if that fails, then http://goo.gl/tnBgH5