sqlite-jdbc VS Spring Boot

There's also a fairly popular JDBC driver for SQLite too:

https://github.com/xerial/sqlite-jdbc

Mentioning that because from (very) rough memory, Excel can work with JDBC too.

So if the ODBC approach doesn't work for someone, there's potentially another thing they can try. :)

Sadly, another baseless assumption. I just downloaded sqlite java driver from https://github.com/xerial/sqlite-jdbc/. And compiled their sample program on the home page to native code. (all within ~1min after reading your response)

    javac Sample.java && native-image -cp .:sqlite-jdbc-3.41.2.1.jar Sample

Here's a link to the ResultSet source code for that driver. https://github.com/xerial/sqlite-jdbc/blob/master/src/main/java/org/sqlite/jdbc3/JDBC3ResultSet.java

Well, the simplest is to just use basic JDBC. See https://www.tutorialspoint.com/jdbc/jdbc-sample-code.htm or maybe some tests that the xerial-jdbc library has https://github.com/xerial/sqlite-jdbc/blob/master/src/test/java/org/sqlite/CollationTest.java

There is https://github.com/xerial/sqlite-jdbc, a full packaged sql lite for Java. We use it in production apps to store local user profile data. It works, is stable.

> Take the Jetbrains IDEs. I don't mean to offend any VSC fans out there but the Jetbrains IDEs are simply better and more mature in every single way.

I just discontinued my Jetbrains subscription after 10 years or so. Now I'm using VS Code and don't miss anything. My reasons for switching to VS Code are unrelated to the costs but purely due to quality issues and missing or poorly implemented features:

1. For all Jetbrains IDEs, ISO keyboard layout with dead keys doesn't work on Ubuntu based distros. I was baffled when I found out after saying goodbye to Windows lately. When filing a bug I was asked to wade through years old pages of comments to find somewhere someone who posted a workaround that was not compatible with the Toolbox. Well, at least the support could have sent me the instructions to fix it to save me spending an hour to read those threads at the Youtrack.

2. Vue 3 support was a disaster for itself. Still, Vue 3 support is very much behind the VS Code extension.

3. Same for Svelte. They are not even working on bugs / feature requests like intellisense in the templates.

4. Same for TailwindCSS. Never ending storing. Don't know and care if Jetbrains got it right by now.

5. Starting maybe 2 years ago, Jetbrains added feature for feature that were just distracting and annoying. This "run command in terminal" thingie for example. They're bloating their IDEs with new (mostly useless stuff) but don't fix essential bugs or get Webstorm back into shape.

6. Datagrip still doesn't (or maybe it does in the meantime) support SQLite STRICT TABLES (version 3.37). The simple answer from Jetbrains was: "The open source lib we're using does not support it so we don't." (Actually the lib (https://github.com/xerial/sqlite-jdbc) is currently unmaintained - another reason to be careful depending on a lib maintained by a single person.). The reply would be perfectly fine for an open source project, but not for a multi billion dollar company I as a customer had payed accumulated several thousand Euros in the last years.

I'm using mainly Go, Rust and several frontend frameworks. VS Code support for those is really good. Many things work much better in VS Code.

I was working on this project for a few months: https://github.com/xerial/sqlite-jdbc/pull/568. I basically read this entire book to learn more about the C api: https://www.amazon.com/Using-SQLite-Small-Reliable-Choose/dp/0596521189 and studied the JNI for a few weeks.

- Usually manually wired and configured vs the spring boot "starter" pattern of having libraries that automatically do some of the manual setup work for you: https://github.com/spring-projects/spring-boot/blob/main/spr...

I wish more client library sets had the feature-matrix that the pulsar one does, because in practice most end up being the same: Java supports everything because it's either built in the same codebase or is the most used client and gets the most support, while the dotnet client codebase has many feature-requests or performance improvement issues, often leading to a "third-party client" being created.

https://github.com/spring-projects/spring-boot/pull/39754/co...

If you’re currently running with an earlier version of Spring Boot, I recommend that you upgrade to Spring Boot 2.7 before migrating to Spring Boot 3.0. It minimizes compatibility issues as much as possible.

Okay, we need to build the game? No problem, we will use Spring Boot and Swing!

It's weird that some people including you directly attack my competence. As a power user you should have plenty of experience getting something to work that is not properly document, does not work how the documentation promised it to, or has weird problems on top of it. Look at idiotic things like this:

https://github.com/spring-projects/spring-boot/issues/33044

Take any similar issue and you'll see a bunch of people who try to find a solution for them because they just aren't repeatable at all. The underlying issue is the auto configuration doing things you can't follow quite properly. It's like it wasn't mean to be understood. Issues like the one I linked above also show me that the spring dev crowd also doesn't understand the ecosystem anymore. The problem is complexity and automagic.

An interested reader can decide for themselves:

https://github.com/spring-projects/spring-boot/tree/main/spr...

Explicitly decoding URL query parameters occurs less often because many frameworks, including Spring Boot, handle decoding automatically.

https://aws.amazon.com/lambda/ https://aws.amazon.com/api-gateway/ https://aws.amazon.com/serverless/sam/ https://aws.amazon.com/cloudformation/ https://aws.amazon.com/s3/ https://spring.io/projects/spring-boot https://start.spring.io