1

I created a Java 13 project that uses the modular system, and want to use LITIEngine, a game library made with java 8.

After adding the dependency in Maven using :

<dependency>
    <groupId>de.gurkenlabs</groupId>
    <artifactId>litiengine</artifactId>
    <version>0.4.18</version>
</dependency>

I was expecting to use it as an automatic module, in my module-info.java:

module com.myproject {
    require litiengine; // Error: Module litiengine not found.
}

Surprisingly enough, it doesn't seem to be an automatic module, so I grabbed the jar and ran the command jar --file=litiengine-0.4.18.jar --describe-module, and got this weird result:

java.xml.bind jar:file:///D:/WhereverMyJarIs/litiengine-0.4.18.jar/!module-info.class
exports javax.xml.bind
exports javax.xml.bind.annotation
exports javax.xml.bind.annotation.adapters
exports javax.xml.bind.attachment
exports javax.xml.bind.helpers
exports javax.xml.bind.util
requires java.activation transitive
requires java.base mandated
requires java.desktop
requires java.logging
requires java.xml transitive
uses javax.xml.bind.JAXBContextFactory

So, I am supposed to use LITIEngine as java.xml.bind? It doesn't have anything to do with the library I want to use. This makes no sense!

I still tried to require it:

module com.myproject {
    requires java.xml.bind; // IntelliJ gives an error: Ambiguous module reference: java.xml.bind
}

Despite the error IntelliJ gives me, i tried to compile my project with Maven, containing a simple HelloWorld.java file:

package com.myproject;

import de.gurkenlabs.litiengine.Game;

public class HelloWorld {
    public static void main(String[] args) {
        Game.init(args);
        Game.start();
    }
}

When running mvn compile, the compilation fails (I set maven.compiler.target and maven.compiler.source to 13):

Error:(3,21) java: package de.gurkenlabs.litiengine is not visible

At this point, I just tried to use my project as a nonmodular one, but still use Java 13, so i just deleted the module-info.java, and like that, it works. Great, but I lose the ability to use the module system, which i need to use in my project.

I tried one last thing, I used the LITIEngine jar i grabbed earlier, and removed the module-info.class file in it, by opening the jar file as an archive in 7-zip and deleting that file. Then I added it as a local dependency in maven with:

mvn install:install-file -Dfile=./whereverItIs/litiengine-0.4.18.jar \
-DgroupId=com.myproject.jars -DartifactId=litiengine -Dversion=1 -Dpackaging=jar

And I added it as a dependency:

<dependency>
   <groupId>com.myproject.jars</groupId>
   <artifactId>litiengine</artifactId>
   <version>1</version>
</dependency>

I could then use the library in my module-info.java

module com.myproject {
    require litiengine; // No errors this time!
}

And then successfully build it and run it!

So, this proves that this library can work with when imported as an automatic module, but this requires me to edit the jar file and remove the module-info.class in order to make it work, which is very undesirable, because this requires manual action everytime the library receives an update.

The perfect solution would be to be able to ignore the module-info.class file contained inside the jar and make the module system threat it as an automatic module, is there a way to do that?

jeuxjeux20
  • 391
  • 1
  • 6
  • 20
  • Removing files from a downloaded artifact is a bad habit. If the package/class is not visible the authors have a good reason not to use such things. So in the end it sounds as if you are not using the intended interface...furthermore ignoring a `module-info` does not make sense cause the author have defined things in that...and an automatic module will not help here...Furthermore I don't understand your comment: `and got this weird result:`...? What have you expect? – khmarbaise Jan 19 '20 at 12:19
  • I know that doing this is a bad habit, which is why i want to find a solution that doesn't need to remove files. And I did not expect this result, as it describes a `java.xml.base` module, which is weird, because it doesn't have anything to do with the library i want to use, LITIEngine. I would expect instead to have no module-info file inside the jar at all. I edited the post to make it clearer. – jeuxjeux20 Jan 19 '20 at 12:30
  • 1
    @khmarbaise The reason why the result is stated as weird could be because of the module name, which is the same as that of [JAXB module](https://stackoverflow.com/questions/48204141/replacements-for-deprecated-jpms-modules-with-java-ee-apis). That said, the `module-info.class` within this artifact seems to have no relation with the package structure or classes within it. – Naman Jan 19 '20 at 12:31
  • 2
    @jeuxjeux20 An ideal solution would be for the maintainer of the artifact to fix this error. It could be by updating and fixing the `module-info.java` class in the module or just removing it if not intended and declaring the entry in `MANIFEST.MF`. So, go ahead and report it to the maintainers. – Naman Jan 19 '20 at 12:32
  • @Naman I'll file an issue to the [github repo](https://github.com/gurkenlabs/litiengine), thanks! – jeuxjeux20 Jan 19 '20 at 12:35
  • Yes of course the solution could only be the original artifact being fixed...that's of course simply wrong... – khmarbaise Jan 19 '20 at 12:43

0 Answers0