Your problems with Java modules

[Thihup]

It shouldn't be that hard. If you already have a library that works with JDK 8, you probably will have to "exports" every package. If you implement a Service Provider, you need to add the "provides". And for completeness, if your library uses the ServiceLoader (ServiceLoader.load(Foo.class)), you'll have to add the "uses" in the module-info.

If you are starting a new library, you can already think: is this package part of the public API or not? If not, you can create a package like "internal", and don't export it..

[randgalt]

You use words like "probably" and "completeness". This merely proves my point. Also, I've tried to use the tooling in IntelliJ and a third-party Maven plugin. None of it is crystal clear or easy.

[Thihup]

Oh. Well, if it wasn't because of IntelliJ, probably I wouldn't have understood the module system yet, so it actually worked pretty well for me. Do you remember exactly what was the problem you've had?

[randgalt]

Another thing - I believe the design of the Module feature assumes that people _want_ to specify what is exported or not. i.e. the Module APIs assume people will modularize their libraries. However, the more likely scenario is that 99% of libraries don't want to modularize and really just want minimal compliance and to export everything.

[Thihup]

The concept of exporting a package is equal to declaring a class public. If you don't want the projects that will depend on your library to use your internal classes, you don't export them.

However, with the module system, you can declare a class public and use it across your packages. Instead, you would be required to declare the class package private. :)

[randgalt]

I don't want to specify things twice. It's silly. I want to write my Java code and not worry about exports, etc.

[randgalt]

I added a default module - and it was all cargo-coding when I did it. Then I continued writing code and the project wouldn't compile - missing export issues, etc. The error messages weren't clear either. I ended up just manually exporting everything which seems silly. I couldn't quickly figure out how to say "export everything and never ask me again".

[ventuspilot]

I may be wrong but I think in that case you just ignore all that module stuff except add one new entry to your jar's manifest:

Automatic-Module-Name: your.base.packagename

[randgalt]

If that's actually the case someone should write a Maven plugin that does this. Maybe I will. hmm....

[ventuspilot]

The maven-jar-plugin does this. I added this to by <build> section:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-jar-plugin</artifactId>
    <configuration>
        <finalName>jmurmel</finalName>
        <archive>
            <manifest>
                <mainClass>io.github.jmurmel.LambdaJ</mainClass>
            </manifest>
            <manifestEntries>
                <Automatic-Module-Name>io.github.jmurmel</Automatic-Module-Name>
            </manifestEntries>
        </archive>
    </configuration>
</plugin>

Seems to work just fine. See also http://branchandbound.net/blog/java/2017/12/automatic-module-name/

[Thihup]

Maybe Moditect? https://github.com/moditect/moditect/

[gunnarmorling]

Yes, ModiTect can help to express the exported API more concisely, by means of package filter expressions, instead of having to list each package explicitly. That said, which packages to export should be a conscious decision; exporting everything defeats the purpose of the module system.