Jdbi: JDBI3 versión 3.19.0 no se ejecuta en JDK <11

Hola @sjoerdtalsma , perdón por esto: la cafeína no tiene ninguna versión que se ejecute tanto en jdk8 como en jdk16. Dado que 16 ahora es GA, Jdbi se actualizó a una versión de Caffeine que es compatible. Las notas de la versión mencionan:

actualice el depósito de cafeína a 3.0.1 para jdk16 (NOTA: los usuarios de jdk8 deberán volver a administrarlo a 2.x)

pero estoy de acuerdo en que no es muy prominente.

También agregué una nota aquí: http://jdbi.org/#_java_compatibility

¿Hay alguna forma en la que podamos señalar esto mejor a los usuarios? Con suerte, una vez que administre la versión de cafeína a la 2.x, todo simplemente funcionará, pero avísenos si hay más problemas.

Hice algunas actualizaciones en las notas de la versión para destacar esto de manera mucho más destacada. Háganos saber si hay algo más que podamos hacer mejor aquí.

Gracias, espero que otros lean un poco más detenidamente que yo.
No es realmente un problema para mí, pero algo de lo que los usuarios de mi biblioteca deben tener cuidado es una dependencia transitiva de una dependencia transitiva para ellos 😉.

Decidí no degradar la cafeína, sino seguir con la versión estándar y simplemente compilar con un JDK más reciente sin dejar de ofrecer un artefacto de código de bytes JDK8. De esa manera, dejo que ellos decidan por sí mismos.

Gracias por el énfasis adicional, cerraré este tema ahora.

Sí, es realmente lamentable que esto llegue a los usuarios finales. Pero si quieren una excelente experiencia de desarrollo, ya es hora de actualizar Java, solo será cada vez más difícil de ejecutar en 8;)

Imagínese tratando de mantener la compatibilidad del código de bytes JDK 1.5 mientras agrega metadatos de rompecabezas module-info.java para su biblioteca 😉
Intento mantener los requisitos restringidos al mínimo denominador común.

lo siento un poco: la cafeína no tiene ninguna versión que se ejecute tanto en jdk8 como en jdk16

Solo para su información, el problema de compatibilidad en 2.x es solo para aquellos que desean deshabilitar sun.misc.Unsafe . Eso todavía está permitido en JDK16 de forma predeterminada, pero se puede restringir a través de jlink. Inseguro ya no se requería en Caffeine 3.0 (a través de alternativas) y se eliminó por completo en el maestro (próximamente 3.0.2). El endurecimiento de las restricciones de acceso en JDK16 no nos afectó, pero JDK8 no se envió con VarHandles, por lo que nos quedamos atrapados usando Unsafe (o migrando a AtomicReferenceFieldUpdater que tiene problemas de rendimiento debido al uso de la reflexión al acceder a un campo) .

hola @ ben-manes, gracias por el contexto adicional aquí. Es cierto que jdk16 le permite seguir usando Unsafe, pero no creo que esté permitido por defecto, al menos en nuestro caso tuvimos que pasar --illegal-access=permit ya que el valor predeterminado ahora es denegar. No quería que la "experiencia inmediata" de un nuevo proyecto jdk16 con Jdbi requiriera un desagradable cambio como ese, de ahí la actualización a 3.x.

Gracias por actualizar para dejar de usar Inseguro, nos alegra que desaparezca :)