Jdbi: JDBI3 version 3.19.0 does not run on JDK < 11

Hi @sjoerdtalsma , sorry this bit you: caffeine does not have any version that runs on both jdk8 and jdk16. Since 16 is now GA, Jdbi upgraded to a version of Caffeine that's compatible. The release notes do mention:

upgrade caffeine dep to 3.0.1 for jdk16 (NOTE: jdk8 users will need to manage it back to 2.x)

but I agree it's not very prominent.

I also added a note here: http://jdbi.org/#_java_compatibility

Is there some way we could better signal this to users? Hopefully once you manage the caffeine version back to 2.x it all just works, but please let us know if there's further troubles.

I made some updates to the release notes to call this out much more prominently. Let us know if there's anything else we can do better here.

Thanks, I hope others read a bit more carefully than me.
It's not really a problem for me, but something the users of my library have to be careful of as well as this is a transitive dependency of a transitive dependency for them 😉 .

I decided to not downgrade caffeine, but stick with the standard version and just build with a more recent JDK while still delivering a JDK8 bytecode artifact. That way I leave it up to them to decide for themselves.

Thank you for the extra emphasis, I'll close this issue now.

Yeah, it is really unfortunate that this gets pushed to end users. But if they want an excellent development experience, it is about time to upgrade Java, it will only continue to get harder and harder to run on 8 ;)

Imagine trying to keep JDK 1.5 bytecode compatibility while adding jigsaw module-info.java metadata for your library 😉
I try to keep the requirements restricted to the least common denominator.

sorry this bit you: caffeine does not have any version that runs on both jdk8 and jdk16

Just fyi, the compatibility problem in 2.x is only for those who want to disable sun.misc.Unsafe. That is still allowed in JDK16 by default, but can be restricted via jlink. Unsafe was no longer required in Caffeine 3.0 (via fallbacks), and completely removed on master (upcoming 3.0.2). The tighten of access restrictions in JDK16 didn't affect us, but JDK8 didn't ship with VarHandles so we were stuck using Unsafe (or migrating to AtomicReferenceFieldUpdater which has performance problems due to using reflection when accessing a field).

hi @ben-manes, thanks for the extra context here. It's true that jdk16 does allow you to still use Unsafe but I don't think it is allowed by default - at least in our case we had to pass --illegal-access=permit since the default is now deny. I didn't want the "out of the box experience" for a new jdk16 project with Jdbi to require an ugly switch like that, hence the upgrade to 3.x.

Thanks for updating to not use Unsafe anymore, we're happy to see it gone :)