5

I have a project like this:

\---main
    \---src
        \---com.foo
            \---UnnamedStart.java
\---api
    \---src
        \---com.foo.api
            \---ApiInterface.java
        \---module-info.java
\---impl
    \---src
        \---com.foo.impl
            \---ApiInterfaceImpl.java
        \---module-info.java

Implementatio of UnnamedStart.java is:

public static void main(String[] args) {
    ServiceLoader<ApiInterface> services = ServiceLoader.load(ApiInterface.class);
    ...
}

Note that main is unnamed module.

api/src/module-info.java is:

module com.foo.api {
     exports com.foo.api;
}

and impl/src/module-info.java is:

update 1.1 - code below updated see comments, added requires

update 1.2 - code below updated, provides A with B changed to provides B with A mistake during creating question, originally was ok

module com.foo.impl {
     requires com.foo.api; //added (update 1.1)
     provides com.foo.impl.ApiInterface
         with com.foo.api.ApiInterfaceImpl; //vice versa (update 1.2)
}

When I run my code in UnnamedStart.java I end up with no element in services.

I also tried to create a static method in com.foo.api.ApiInterface:

static List<ApiInterface> getInstances() {
    ServiceLoader<ApiInterface> services = ServiceLoader.load(ApiInterface.class);
    List<ApiInterface> list = new ArrayList<>();
    services.iterator().forEachRemaining(list::add);
    return list;
}

and add in api/src/module-info.java line uses com.foo.api.ApiInterface; but it gave the same result (nothing).

The only way I made it work is by migrating main from unnamed to named module.

1. How does java 9 work when unnamed module trying to interact with named module?

2. Does it possible to make it work and keeping the main like unnamed module?

update 1.3 - added related project

Andrew Sasha
  • 1,254
  • 1
  • 11
  • 21
  • 3
    module com.foo.impl seems to be missing `requires com.foo.api` so I doubt it will compile. In any case, you'll need to run with `--add-moduels com.foo.impl` to ensure that the com.foo.impl module is resolved - you need this because no module declares requires it and no other module `uses com.foo.api`. – Alan Bateman Jan 18 '18 at 20:00
  • 1
    @Andrew Additionally, when you migrated to a *named module*, did you not put a `requires com.foo.api` in the main module descriptor? – Naman Jan 19 '18 at 01:37
  • 2
    @nullpointer - the initial module is on the class path so it doesn't have a module-info. Mixing the module path and the class path is okay, I suspect he's just missing `--add-modules com.foo.impl`. – Alan Bateman Jan 19 '18 at 08:14
  • @AlanBateman Agreed over that for the case when the OP is using an unnamed module. The question also mentioned about migrating to a named module(module path). That's when I was asking about the `requires` directive being used in the module descriptor. – Naman Jan 19 '18 at 08:17
  • `requires com.foo.api` - originally I have this, miss add it here Yes, you are right, I forgot to put `--add-modules com.foo.impl`, also I used wrong command to run my project, now it works fine with `/usr/lib/jvm/jdk-9.0.4/bin/java -classpath /path/main/target/classes -p /path/api/target/classes:/path/impl/target/classes --add-modules com.foo.impl com.foo.UnnamedStart`. Thanks and could you answer please :) – Andrew Sasha Jan 19 '18 at 09:33
  • @nullpointer "did you not put a requires com.foo.api in the main module descriptor?" - I put it – Andrew Sasha Jan 19 '18 at 09:42
  • 1
    @AndrewChmielowski I meant the same(maybe sarcastically), that you needed the requires within the impl module(as in your edit) to compile the code in the unnamed scenario as well. Also, the module resolution still needed the impl to be resolved during the startup. To check which you could also [make use of the `--show-module-resolution`](https://stackoverflow.com/questions/48339598) flag. – Naman Jan 19 '18 at 11:00

1 Answers1

5

ServiceLoader::load works as usual, but the are other things.

[Short answer]

1. Unnamed module reads the same like named module to named module, but named module can not access types in the unnamed module.

2. You are trying to launch an application from a non-modular JAR so you have to explicitly resolve required modules by --add-modules com.foo.impl.

Note that your required modules have to be on module graph (e.g. add by --module-path).

[More details]

1. There are 4 different types of modules: built-in platform module, named module, automatic module, unnamed module and each of them are named apart from unnamed module

As they wrote the unnamed module treats all the other modules the same like named module:

All other modules have names, of course, so we will henceforth refer to those as named modules.

The unnamed module reads every other module. [...]

The unnamed module exports all of its packages. [...] It does not, however, mean that code in a named module can access types in the unnamed module. A named module cannot, in fact, even declare a dependence upon the unnamed module. [...]

If a package is defined in both a named module and the unnamed module then the package in the unnamed module is ignored.

Even an automatic module indeed is also named:

An automatic module is a named module that is defined implicitly, since it does not have a module declaration.

2. Second part of this answer

If you compile non-modular code or launch an application from a non-modular JAR, the module system is still in play and because non-modular code does not express any dependencies, it will not resolve modules from the module path.

So if non-modular code depends on artifacts on the module path, you need to add them manually with the --add-modules option. Not necessarily all of them, just those that you directly depend on (the module system will pull in transitive dependencies) - or you can use ALL-MODULE-PATH (check the linked post, it explains this in more detail).

This @nullpointer comment will be useful

Also, the module resolution still needed the impl to be resolved during the startup. To check which you could also make use of the --show-module-resolution flag.

Andrew Sasha
  • 1,254
  • 1
  • 11
  • 21
  • 3
    Nice answer :) Was thinking of writing one myself, but this one is sufficiently detailed. – Naman Jan 22 '18 at 14:14