Jdbi: JDBI3 version 3.19.0 ne fonctionne pas sur JDK < 11

Créé le 12 avr. 2021  ·  7Commentaires  ·  Source: jdbi/jdbi

Selon les notes de version , je m'attendais à ce que cette version fonctionne sur JDK 8, mais j'obtiens l'erreur suivante :

java.lang.UnsupportedClassVersionError: com/github/benmanes/caffeine/cache/Caffeine has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 53.0

La version de classe 55.0 est JDK 11, donc cela ne fonctionnera pas à partir de JDK 8.
Cela est apparu dans la demande de fusion suivante : https://github.com/talsma-ict/enumerables/pull/242

question

Commentaire le plus utile

désolé ce peu vous: la caféine n'a pas de version qui fonctionne à la fois sur jdk8 et jdk16

Juste pour info, le problème de compatibilité dans 2.x est uniquement pour ceux qui veulent désactiver sun.misc.Unsafe . Cela est toujours autorisé dans JDK16 par défaut, mais peut être restreint via jlink. Unsafe n'était plus requis dans Caffeine 3.0 (via les solutions de secours) et complètement supprimé sur le maître (à venir 3.0.2). Le resserrement des restrictions d'accès dans JDK16 ne nous a pas affecté, mais JDK8 n'était pas livré avec VarHandles, nous étions donc bloqués en utilisant Unsafe (ou en migrant vers AtomicReferenceFieldUpdater qui a des problèmes de performances dus à l'utilisation de la réflexion lors de l'accès à un champ) .

Tous les 7 commentaires

Salut @sjoerdtalsma , désolé ce peu vous : la caféine n'a pas de version qui fonctionne à la fois sur jdk8 et jdk16. Puisque 16 est maintenant GA, Jdbi est passé à une version de Caffeine compatible. Les notes de version mentionnent :

mettre à niveau le dep de caféine vers 3.0.1 pour jdk16 (REMARQUE : les utilisateurs de jdk8 devront le gérer à nouveau vers 2.x)

mais je suis d'accord que ce n'est pas très important.

J'ai également ajouté une note ici : http://jdbi.org/#_java_compatibility

Existe-t-il un moyen de mieux signaler cela aux utilisateurs ? J'espère qu'une fois que vous aurez ramené la version caféine à 2.x, tout fonctionnera, mais veuillez nous faire savoir s'il y a d'autres problèmes.

J'ai apporté quelques mises à jour aux notes de version pour l'appeler beaucoup plus clairement. Faites-nous savoir s'il y a autre chose que nous pouvons faire mieux ici.

Merci, j'espère que d'autres liront un peu plus attentivement que moi.
Ce n'est pas vraiment un problème pour moi, mais quelque chose dont les utilisateurs de ma bibliothèque doivent faire attention car c'est une dépendance transitive d'une dépendance transitive pour eux 😉 .

J'ai décidé de ne pas rétrograder la caféine, mais de m'en tenir à la version standard et de simplement construire avec un JDK plus récent tout en fournissant un artefact de bytecode JDK8. De cette façon, je leur laisse le soin de décider par eux-mêmes.

Merci pour l'accent supplémentaire, je vais clore ce sujet maintenant.

Oui, c'est vraiment dommage que cela soit poussé aux utilisateurs finaux. Mais s'ils veulent une excellente expérience de développement, il est temps de mettre à jour Java, cela ne fera que devenir de plus en plus difficile à exécuter sur 8 ;)

Imaginez essayer de garder la compatibilité du bytecode JDK 1.5 tout en ajoutant des métadonnées puzzle module-info.java pour votre bibliothèque 😉
J'essaie de limiter les exigences au plus petit dénominateur commun.

désolé ce peu vous: la caféine n'a pas de version qui fonctionne à la fois sur jdk8 et jdk16

Juste pour info, le problème de compatibilité dans 2.x est uniquement pour ceux qui veulent désactiver sun.misc.Unsafe . Cela est toujours autorisé dans JDK16 par défaut, mais peut être restreint via jlink. Unsafe n'était plus requis dans Caffeine 3.0 (via les solutions de secours) et complètement supprimé sur le maître (à venir 3.0.2). Le resserrement des restrictions d'accès dans JDK16 ne nous a pas affecté, mais JDK8 n'était pas livré avec VarHandles, nous étions donc bloqués en utilisant Unsafe (ou en migrant vers AtomicReferenceFieldUpdater qui a des problèmes de performances dus à l'utilisation de la réflexion lors de l'accès à un champ) .

salut @ben-manes, merci pour le contexte supplémentaire ici. Il est vrai que jdk16 vous permet toujours d'utiliser Unsafe mais je ne pense pas que ce soit autorisé par défaut - au moins dans notre cas, nous avons dû passer --illegal-access=permit puisque la valeur par défaut est maintenant deny. Je ne voulais pas que "l'expérience prête à l'emploi" pour un nouveau projet jdk16 avec Jdbi nécessite un commutateur aussi laid, d'où la mise à niveau vers 3.x.

Merci d'avoir mis à jour pour ne plus utiliser Unsafe, nous sommes heureux de le voir disparaître :)

Cette page vous a été utile?
0 / 5 - 0 notes