Add module-info.java

[onkobu]

Is your feature request related to a problem? Please describe. When packing with jlink sqlite-jdbc breaks the build. It is a so called auto module and cannot be packaged with jlink automatically.

Describe the solution you'd like Add a module-info.java.

Describe alternatives you've considered Issue #478

Additional context While it is feasible as a developer to hack some script or action to re-pack sqlite-jdbc with appropriate module info it is impossible for the lesser experienced. It requires pre-conditions and initial steps that are error prone and not reproducible.

Tool jdeps generates this:

module org.xerial.sqlitejdbc {
    requires transitive java.logging;
    requires transitive java.sql;

    exports org.sqlite;
    exports org.sqlite.core;
    exports org.sqlite.date;
    exports org.sqlite.javax;
    exports org.sqlite.jdbc3;
    exports org.sqlite.jdbc4;
    exports org.sqlite.util;

    provides java.sql.Driver with
        org.sqlite.JDBC;

}

I use this module-info.java in https://sourceforge.net/projects/jworktime/ for a Swing-based project as well as in https://codeberg.org/onkobu/mottow for an Undertow-based REST backend demo. While the first has a section in the README.md the latter ships a shell script to turn a bunch of auto modules into explicit ones.

[gotson]

For reference neither H2 nor pgjdbc have this yet

[gotson]

@onkobu seems we could define Automatic-Module-Name in the manifest?

[gotson]

Oh, actually it's already defined https://github.com/xerial/sqlite-jdbc/blob/7c3f7decb14a30bf55459b3da6a0b1c3171dc161/pom.xml#L128-L128

[onkobu]

Checked at least with 3.39.2.1 and jlink from an OpenJDK 17, still treated as automatic module and had to be amended.

For reference neither https://github.com/h2database/h2database/issues/1415 nor https://github.com/pgjdbc/pgjdbc/issues/1979 have this yet

Steam engines still in use here in Germany never were never updated with Bluetooth. But as soon as I'm packing H2 in favour of SQLite I'll be annoying there, too.

Nevertheless I didn't check with backwards compatibility with other JDKs like on Android or so. Could be necessary to make this multi-release then. I'm planning to give this a try in other contexts since module path enforces each package definition to be unique. This breaks with some project's policies to have project descriptions in a dedicated package of the same name across multiple components.

There is also no need to hurry/ I don't urge anyone. But maybe it is just a matter of some spare time and a few tests. Or it is already clearly not an option.

[onkobu]

Checked also with most recent 3.39.3.0:

Error: automatic module cannot be used with jlink: org.xerial.sqlitejdbc from file:///[…]/.m2/repository/org/xerial/sqlite-jdbc/3.39.3.0/sqlite-jdbc-3.39.3.0.jar

[hadrabap]

I'm facing the same issue. My position is a bit different. I've chosen SQLite for my project to be ready for future. As everybody is fully aware the Java AWT/Swing is fading out. The best alternative for my client application is C++/Qt. SQLite is extremely popular in the native world. Starting the data store with SQLite eliminates the future migration headaches.

From the native point of view I look at sqlite-jdbc as an additional library (native SQLite can be staticaly linked as well) rather than as something underlying deep inside JVM.

Finally, as I'm facing additional issues, I'm using patched in-tree build of sqlite-jdbc. My module-info.java needs to look like this:

module <redacted>.sqlite.jdbc {

    requires transitive java.logging;
    requires transitive java.sql;
    requires transitive java.sql.rowset;

    exports org.sqlite;
    exports org.sqlite.core;
    exports org.sqlite.date;
    exports org.sqlite.javax;
    exports org.sqlite.jdbc3;
    exports org.sqlite.jdbc4;
    exports org.sqlite.util;

    provides java.sql.Driver with org.sqlite.JDBC;
    provides javax.sql.DataSource with org.sqlite.SQLiteDataSource;
    provides javax.sql.ConnectionPoolDataSource with org.sqlite.javax.SQLiteConnectionPoolDataSource;

}

Module in this configuration works in Java SE 17 as well as in OpenLiberty (should work in other application servers as well depending on the particular ClassLoader configuration — JakartaEE is not modular yet, but the application server's runtime might be).

By the way, there is another database-as-component serving similar purpose as SQLite: Apache Derby. That one is already "modular".

[onkobu]

Didn't see any use of javax.sql.* in the wild lately. Thanks for reminding me of this.

JakartaEE is not modular yet

I'd say this is more of a bottom up movement. Libraries (like SQLite) become modules first.

[jasonli0616]

Any solutions/workarounds for this yet? I am also facing this issue :(

[hadrabap]

@jasonli0616: There are two possible workarounds:

1. Clone the source code into your project as Maven module with your patches (e.g. this module-info.java)
2. Create your own Maven module with just module-info.java and download official sources (requires compilation) or binaries from Maven Central using maven-dependnecy-plugin and combine all of them together using maven-jar-plugin.

Both ways should work. I'm using approach 1 for sqlite-jdbc (as I needed additional patches) and approach 2 for re-releasing (now obsolete) JSR305 annotations with additional stuff. Both ways work great!

Hope this helps.

[jasonli0616]

@hadrabap Thanks, I got it working with the first method. If I'm not mistaken, the only thing required to fix this is adding a module-info.java into this repo, is this correct?

This is the module-info.java that I got using the first method, the exact same as @onkobu.

module org.xerial.sqlitejdbc {
    requires transitive java.logging;
    requires transitive java.sql;

    exports org.sqlite;
    exports org.sqlite.core;
    exports org.sqlite.date;
    exports org.sqlite.javax;
    exports org.sqlite.jdbc3;
    exports org.sqlite.jdbc4;
    exports org.sqlite.util;

    provides java.sql.Driver with
        org.sqlite.JDBC;

}

[hadrabap]

@jasonli0616 Yep, that's all it needs if you are targeting Java 9+.

[jasonli0616]

@hadrabap Seems like a relatively easy fix to me, but then again my main language isn't java. Is there any reason that a module-info.java hasn't been added to this?

[hadrabap]

@jasonli0616 Well, in fact it is more complicated. First, the world is very slowly adopting to Java Platform Module System. It happened just last year when majority of dev tools started to covering it in a reasonable fashion. For example till now IntelliJ IDEA has problems. NetBeans and Eclipse are fine. Second thing is that this driver supports Java 8 as well and therefor incorporating JPMS means switching from single JAR to multirelease JAR distribution.

The second problem is not an issue for me and you as we both target Java 9+ (Java 17 in my case).

[jasonli0616]

@hadrabap Thanks for clarifying! So would you say backwards compatibility is the main issue? Would it be feasible to have a fork of this project for Java9+ with JPMS?

[hadrabap]

@jasonli0616 I would go the multirelease JAR way. Its easier to tweak the POM than been dealing with multiple repos.

I'll try my best to prepare a PR for it tomorrow. 🙂

[hadrabap]

@jasonli0616 And yes, the backward compatibility is still the must as most of the Enterprise are still on Java 8. I'm also maintaining several Java 8 apps. 😇

[jasonli0616]

@jasonli0616 I would go the multirelease JAR way. Its easier to tweak the POM than been dealing with multiple repos.

I'll try my best to prepare a PR for it tomorrow. 🙂

@hadrabap Sounds great, and thanks for all the info!

[github-actions[bot]]

🎉 This issue has been resolved in 3.39.4.1 (Release Notes)