JDK9: define a stable automatic module name with Automatic-Module-Name entry in MANIFEST

[zyxist]

JDK9 is out and introduces a module system.

RxJava does not currently use modules. When we use it in a JDK9 modular application, Java turns the JAR into a so-called automatic module, whose name is derived from the JAR archive name. However, the default name does not follow the recommended module naming conventions (reverse-dns style, module name derived from the main exported package).

It is possible to specify a stable automatic module name through a Automatic-Module-Name manifest entry, while still targeting JDK8:

Automatic-Module-Name: io.reactivex

Selecting a stable module name is very important, because Java does not allow two modules to own the same package, and you may end up with a module hell. The naming issues are well-explained on Stephen Colebourne's blog:

• http://blog.joda.org/2017/04/java-se-9-jpms-module-naming.html
• http://blog.joda.org/2017/05/java-se-9-jpms-automatic-modules.html <- the explanation of module hell problem

And the comment of Mike Reinhold, chief Java architect:

Strongly recommend that all modules be named according to the reverse Internet domain-name convention. A module's name should correspond to the name of its principal exported API package, which should also follow that convention. If a module does not have such a package, or if for legacy reasons it must have a name that does not correspond to one of its exported packages, then its name should at least start with the reversed form of an Internet domain with which the author is associated.

[JakeWharton]

io.reactivex.rxjava2 would be better.

…

On Sun, Sep 24, 2017, 11:14 AM Tomasz Jędrzejewski ***@***.***> wrote: JDK9 is out and introduces a module system. RxJava does not currently use modules. When we use it in a JDK9 modular application, Java turns the JAR into a so-called automatic module, whose name is derived from the JAR archive name. However, the default name does not follow the recommended module naming conventions (reverse-dns style, module name derived from the main exported package). It is possible to specify a stable automatic module name through a Automatic-Module-Name manifest entry, while still targeting JDK8: Automatic-Module-Name: io.reactivex Selecting a stable module name is very important, because Java does not allow two modules to own the same package, and you may end up with a module hell. The naming issues are well-explained on Stephen Colebourne's blog: - http://blog.joda.org/2017/04/java-se-9-jpms-module-naming.html - http://blog.joda.org/2017/05/java-se-9-jpms-automatic-modules.html <- the explanation of module hell problem And the comment of Mike Reinhold, chief Java architect: Strongly recommend that all modules be named according to the reverse Internet domain-name convention. A module's name should correspond to the name of its principal exported API package, which should also follow that convention. If a module does not have such a package, or if for legacy reasons it must have a name that does not correspond to one of its exported packages, then its name should at least start with the reversed form of an Internet domain with which the author is associated. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#5618>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEEEQv68UhFi-hX8Vt_XfaYZE8M4YADks5slnHCgaJpZM4Ph64L> .

[akarnokd]

What is the automatic module name RxJava it receives now? What happens to those who are already using this auto-name in their projects?

[JakeWharton]

The filename of the jar is used.

…

On Sun, Sep 24, 2017 at 11:34 AM David Karnok ***@***.***> wrote: What is the automatic module name RxJava it receives now? What happens to those who are already using this auto-name in their projects? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#5618 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEEES2c_67cR_p2IydyztcdK4klk5qfks5slnZwgaJpZM4Ph64L> .

[zyxist]

Currently, to use Mockito you have to use the name derived from the JAR file:

module com.example.foo {
   requires mockito.core;
}

If you change this name later to org.mockito (or even change the JAR name), and there will be other modular projects that use Mockito as a dependency under the old mockito.core name, you'll fall into a module hell, because Java will refuse to compile an application that tries to import both mockito.core and org.mockito. From JVM perspective, they will be two distinct modules with the same packages inside, which is illegal.

The second link provided in the original issue description contains a great explanation of the module hell problem.

[akarnokd]

I see another problem: RxJava 2 is located in io.reactivex package so RxJava 3 can't be in io.reactivex or any of its subpackages if we want to allow them to live side-by-side.

[zyxist]

Actually, you can put RxJava 3 into a subpackage. io.reactivex and io.reactivex.rxjava3 is not considered as a package split. It will be also possible to create a module named io.reactivex.rxjava3.

[akarnokd]

I see. Since this only affects a line in the generated manifest, PR welcome.

[akarnokd]

Closing via #5644.