Jdbi: JDBI3 Version 3.19.0 läuft nicht auf JDK < 11

Hallo @sjoerdtalsma , sorry das hat dich

upgrade coffein dep auf 3.0.1 für jdk16 (HINWEIS: jdk8-Benutzer müssen es zurück auf 2.x verwalten)

aber ich stimme zu, es ist nicht sehr prominent.

Ich habe auch hier eine Notiz hinzugefügt: http://jdbi.org/#_java_compatibility

Gibt es eine Möglichkeit, dies den Benutzern besser zu signalisieren? Hoffentlich funktioniert alles, sobald Sie die Coffein-Version zurück auf 2.x verwalten, aber bitte lassen Sie es uns wissen, wenn es weitere Probleme gibt.

Ich habe einige Aktualisierungen an den Versionshinweisen vorgenommen, um dies deutlicher hervorzuheben. Lassen Sie es uns wissen, wenn wir hier noch etwas besser machen können.

Danke, ich hoffe andere lesen etwas aufmerksamer als ich.
Für mich nicht wirklich ein Problem, aber was die Benutzer meiner Bibliothek auch beachten müssen, da dies für sie eine transitive Abhängigkeit von einer transitiven Abhängigkeit ist 😉 .

Ich beschloss, Koffein nicht herunterzustufen, sondern bei der Standardversion zu bleiben und einfach mit einem neueren JDK zu bauen, während ich immer noch ein JDK8-Bytecode-Artefakt ausliefere. So überlasse ich es ihnen selbst zu entscheiden.

Vielen Dank für die zusätzliche Hervorhebung, ich schließe dieses Thema jetzt.

Ja, es ist wirklich bedauerlich, dass dies an Endbenutzer weitergegeben wird. Aber wenn sie eine hervorragende Entwicklungserfahrung wünschen, ist es an der Zeit, Java zu aktualisieren, es wird nur immer schwieriger, es auf 8 zu laufen ;)

Stellen Sie sich vor, Sie versuchen, die JDK 1.5-Bytecode-Kompatibilität aufrechtzuerhalten, während Sie jigsaw module-info.java Metadaten für Ihre Bibliothek hinzufügen 😉
Ich versuche, die Anforderungen auf den kleinsten gemeinsamen Nenner zu beschränken.

Entschuldigung, dass Sie das gebissen haben: Koffein hat keine Version, die sowohl auf jdk8 als auch auf jdk16 läuft

Nur zur Info, das Kompatibilitätsproblem in 2.x ist nur für diejenigen, die sun.misc.Unsafe deaktivieren möchten. Das ist in JDK16 standardmäßig noch erlaubt, kann aber über jlink eingeschränkt werden. Unsafe war in Caffeine 3.0 (über Fallbacks) nicht mehr erforderlich und wurde auf Master (demnächst 3.0.2) vollständig entfernt. Die Verschärfung der Zugriffsbeschränkungen in JDK16 hatte keine Auswirkungen auf uns, aber JDK8 wurde nicht mit VarHandles ausgeliefert, sodass wir bei der Verwendung von Unsafe feststeckten (oder bei der Migration zu AtomicReferenceFieldUpdater mit Leistungsproblemen aufgrund der Verwendung von Reflektion beim Zugriff auf ein Feld festhielten). .

Hallo @ben-manes, danke für den zusätzlichen Kontext hier. Es stimmt, dass Sie mit jdk16 weiterhin Unsafe verwenden können, aber ich glaube nicht, dass dies standardmäßig zulässig ist - zumindest mussten wir in unserem Fall --illegal-access=permit da die Standardeinstellung jetzt deny ist. Ich wollte nicht, dass die "Out-of-the-Box-Erfahrung" für ein neues jdk16-Projekt mit Jdbi einen solchen hässlichen Schalter erfordert, daher das Upgrade auf 3.x.

Vielen Dank für das Update, um Unsafe nicht mehr zu verwenden. Wir freuen uns, dass es verschwunden ist :)