Future proof duckdb-java by making it a named module.

[parsaloi]

Bug definition
I just hit an unexpected compile time error when I named my module, which requires org.duckdb

To Reproduce

module com.example.dsl.dsl.main {
    requires org.duckdb; // This is currently results in a compile time error as  duckdb-java is yet to have a module definition
    //requires duckdb.jdbc;
    requires java.sql;
    // ...

    exports com.example.dsl.sql.core;
    exports com.example.dsl.sql.dialects;
    exports com.example.dsl.sql.errors;
    exports com.example.dsl.sql.execution;
    exports com.example.dsl.sql.transactions;

    provides com.example.dsl.sql.execution.SqlExecutor
            with com.example.dsl.sql.execution.DuckDBExecutor,
                    com.example.dsl.sql.execution.SQLiteExecutor,
                    com.example.dsl.sql.execution.PostgreSQLExecutor;
}


/// This produces the following compile time error:
org.duckdb - Module not found: org.duckdb

duckdb.jdbc - dsl/src/main/java/module-info.java:24: error: module not found: duckdb.jdbc
      requires duckdb.jdbc; 

Solution proposal
Add module-info.java (module definition) for the org.duckdb library to, add/move package-info.java (package definition) to the respective packages e.g., org.duckdb.io, org.duckdb.user

Alternatives I've considered
Leave it as is, but eventually we will have to handle this, particularly for this library as the java platform evolves:

• <https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/lang/doc-files/RestrictedMethods.html>
• <https://inside.java/2024/12/09/quality-heads-up/>

Environment

• OS: Linux
• CPU architecture: amd64
• org.duckdb.duckdb_jdbc version v1.3.1.0

[staticlibs]

Hi, thanks for the report! I think this is a good idea, but we need to figure out the testing for these module declarations. Currently all builds/tests are run on JDK 8. Going to look into this for 1.4 update.