-
Notifications
You must be signed in to change notification settings - Fork 594
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add module-info.java #790
Comments
@onkobu seems we could define |
Oh, actually it's already defined Line 128 in 7c3f7de
|
Checked at least with 3.39.2.1 and jlink from an OpenJDK 17, still treated as automatic module and had to be amended.
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. |
Checked also with most recent 3.39.3.0:
|
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 Finally, as I'm facing additional issues, I'm using patched in-tree build of
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". |
Didn't see any use of javax.sql.* in the wild lately. Thanks for reminding me of this.
I'd say this is more of a bottom up movement. Libraries (like SQLite) become modules first. |
Any solutions/workarounds for this yet? I am also facing this issue :( |
@jasonli0616: There are two possible workarounds:
Both ways should work. I'm using approach 1 for Hope this helps. |
@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 This is the 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;
} |
@jasonli0616 Yep, that's all it needs if you are targeting Java 9+. |
@hadrabap Seems like a relatively easy fix to me, but then again my main language isn't java. Is there any reason that a |
@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). |
@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? |
@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. 🙂 |
@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. 😇 |
@hadrabap Sounds great, and thanks for all the info! |
🎉 This issue has been resolved in |
Dependency fixed: xerial/sqlite-jdbc#790
Dependency fixed: xerial/sqlite-jdbc#790
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: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.
The text was updated successfully, but these errors were encountered: