sqlite-jdbc | SQLite JDBC is a library for accessing and creating SQLite | Database library

It seems that your actual project has an old version of Netty somewhere on its classpath.

ByteBuf::writeMediumLE (and all the other LE-suffixed ByteBuf methods) were introduced in Netty 4.1.

TLDR: use the x64 version of Java through Rosetta 2 to make jdbc-sqlite work on the M1 based macOS.

So... After trying everything, black magic included, it looks like the only way to solve it was to use a x86_64 build of Java to run this code. I still don't really understand the reason behind it but it's been the only consistent way of making this build.

For not compromising on speed, you can normally use the bundled java version for normal compilations and have the x86_64 Java as the default one in the terminal for using it when you see this error again. Hopefully they can fix this issue soon in the Java builds for ARM... 😅

Update: this was coused by a different dependency that was forcing an outdated version of jdbc-sqlite driver, after configuring that plugin the issue seems to be solved.

Luis Miguel Mejía Suárez's comment worked perfectly and was the easier approach.

In the context of this project, all I had to do was:

1. Append -SNAPSHOT to the version in /version.sbt (should not be needed normally but for this project I had to do this)
2. Run sbt publishLocal in the parent project.

After this, the example project (which already targets the -SNAPSHOT version) is able to pick up the locally built package.

There is no generally no need to call Class.forName.

Such calls were used in the early years. Modern Java was changed so that JDBC drivers are automatically loaded and registered with the JVM via the Java Service Provider Interface (SPI) facility.

If you are using books or tutorials advising Class.forName, you may want to obtain more up-to-date learning materials.

Furthermore, in Servlet work you generally should not be explicitly accessing the JDBC driver.

Setting the database server address, username, and password would require hard-coding text. When the deployment sysadmins change the IP address, or rotate passwords, your code breaks. You would then have to modify your source code, re-compile, and re-deploy.

Instead, you should externalize such configuration details.

For SQLite, see Using DataSource to connect to SQLite with (Xerial) sqlite-jdbc driver.

You can externalize database configuration by using the the DataSource interface. After obtaining a DataSource object at runtime, make database connections by calling its getConnection method. That DataSource object holds the database server address, username, password, and all other settings needed to make a connection to the database.

Obtain a DataSource object at runtime by using JNDI. Your Servlet container may act as the naming/directory server to provide the DataSource object, if your sysadmin so configures it. Or the DataSource can be obtained via JNDI from an external server such as an LDAP server.

Again, the beauty of using DataSource and JNDI is that you as the Servlet programmer need not be involved, or even informed, when the deployment details change.

For Servlet work, you generally do not bundle the JDBC driver with your app.

Instead, the JDBC driver goes into a folder managed by your Servlet container. Study the documentation for your particular Servlet container. For Apache Tomcat, see this Answer.

In development, your IDE may need access to the JDBC driver to compile. If so, in your Maven POM, mark the dependency with a provided element. This tag tells Maven to omit that dependency from the final build because the dependency will already be present (provided) at runtime.

If you insist on bundling your JDBC driver within the WAR file of your web app, then see the important Comment by Mark Rotteveel.

This topic has been addressed many times on Stack Overflow. Search to learn more.

So, after much struggling I finally managed to fix the problem.

First, I made sure to update Kotlin to the latest version. This didn't actual fix it but it pointed me in the right direction. I checked my gradle file some more and noticed I was getting the warning "Kotlin plugin version is not the same as library version".

I found a thread about that here

I removed the following line from all build.gradle files:

Update: Version 1.6.9 has been released and should fix this issue! 🎉

This is actually a known bug, which is now open for quite a while: OSSRH-66257. There are two known workarounds:

As a workaround, use --add-opens to give the library causing the problem access to the required classes:

Ok I solved it the problem was that in intellij idea not enough unmark Generated Sources Root in folder generated-sources but also its subfolders.

This is unrelated to Maven, it is an access error caused by incorrect configuration of the Java module system for your application.

The error message tells you what is wrong:

The issue is your security rules.