AutoFirma no inicia con OpenJDK Java 17 #244
Comments
|
A mí me da el mismo error en Fedora 35. Ahora bien, con Java ando más perdido que un pulpo en un garaje, así que no sé si la que tengo es la versión 11, o la 18.9. Copio abajo la información para el que la sepa descifrar. El problema me lo está dando AutoFirma 1.7.1, pero la 1.6.5 me lo dio también -por eso intenté actualizar-. |
|
Yo miro así la versión: |
|
Sí, sí, yo también, pero si miras la salida de mi comando, aparecerían dos números de versión, el 11 y el 18.9. Por eso decía que con Java nunca estoy seguro de cuál es el número de versión de verdad. 😅 |
|
Hola, Y para dejar por defecto una versión concreta de java debes ejecutar (tanto en Fedora como en Ubuntu): Te aparecerá una lista con todos los Java instalados en tu sistema y escribiendo el número que aparece a la izquierda de cada vesrión de Java, eliges cual quieres dejar por defecto. En Ubuntu, con la última versión de Autofirma instalada y firmando contra una versión antigua y sin parchear del Portafirmas de la AGE (Versión: 5.0.7 ), solo me funciona con Java 11. Hay que tener en cuenta que también importa si firmas en un portafirmas antiguo y sin parchear, que puede dar problemas con navegadores, o con el cliente de Autofirma si no está actualizado. Si vas a firmar en una página actualizada, con poner Java 11 por defecto, e instalar la última versión de Autofirma, y seleccionar tu certificado escogiendo "Almacén de certificados del sistema" (icono pequeñito que aparece en la ventana de firma), podrás firmar. A todo esto, si usas una tarjeta smartcard con chip como el DNIe u otra similar de otra entidad certificadora, deberás tener instalado el Kit de uso de esa entidad certificadora y te deberá funcionar bien el lector de tarjetas de tu equipo. Si encontraras problemas con esto, comenta con qué tipo de tarjeta tienes problemas y el que controle de ese tipo de tarjetas te pasará la información para hacerla funcionar. |
|
A mí directamente no me abre, así que ya no es cuestión del almacén de firmas. Simplemente no llega ni a crear la ventana. Si a ti la última versión te abre en Ubuntu, querrá decir que falta alguna dependencia en el RPM de Fedora, o quizá falta algún script de configuración. |
|
¿Y qué ocurre si necesitas tener otra versión de Java por defecto? En Python también suelen aparecer problemas con la versión por defecto v2 o v3) y las aplicaciones deben estar desarrolladas una de dos:
|
Yo he sufrido el mismo error en Fedora 36. La solución ha sido: |
|
Hola: En un principio no hay incompatibilidades de AutoFirma con OpenJDK 17. El problema que señala @narcisgarcia ( Tanto para hacer una prueba con una JRE concreta como para hacer que AutoFirma se ejecute con una JRE distinta de la que tenemos configurada en las variables
En su lugar usaremos el mismo, pero indicando la ruta concreta de la JRE que deseamos utilizar. Por ejemplo:
Probablemente (según la distribución que uséis) también se tenga que hacer lo mismo en /usr/share/applications/autofirma.desktop. Un saludo. |
Pues tienes razón. Me he fijado que en Fedora 36 yo tenía instalado solamente el OpenJDK 17 headless. He instalado el openjdk17 completo y ahora puedo ejecutar Autofirma. Me aparece un aviso de compatibilidad con la version 17 de openjdk pero me ha funcionado sin mayor problema. |
Muchas gracias por apuntarlo. Efectiva
Muchas gracias por el apunte. En mi caso, con bajar a openjdk-11 me ha funcionado (estoy utilizando Fedora 37). Se puede utilizar openjdk-17 (si no es el headless), pero Autofirma se queja de que no es una versión soportada, así que hacer el downgrade a la 11 parece ser lo más recomendado. Un saludo y gracias de nuevo |
|
Gracias @Gamuci pero: En Debian el paquete openjdk-17-jre depende de openjdk-17-jre-headless. Parece que hubo alguna corrección con la versión 1.7.1 de AutoFirma, porque ahora lo probé de nuevo y por lo menos la aplicación arranca, aunque con la advertencia: Evidentemente, en Debian y la mayoría de distribuciones, lo que hay que instalar es el paquete de la distribución, que está muy bien preparado para no dar problemas en su entorno. |
|
Prepárense porque la versión 18 de OpenJDK está publicada desde hace casi un año. |
Efectivamente ese era el problema. En Fedora 38 viene instalada por defecto |
Exige la existencia de alguna librería de Java >= 11 sin exigir ninguna versión o proveedor particular. En el issue ctt-gob-es#259 se nos motiva por qué no se exige ninguna dependencia de Java para la instalación: hay usarios que no quieren instalarse ninguna otra versión que la que ya tienen. Esto provoca mucho quebraderos de cabeza para usuarios que se instalan Autofirma sin leerse las instrucciones, acabando con instalaciones rotas - no es intuitivo para el usuario instalarse las dependencias manualmente. Para conciliar esto utilizamos los virtual packages de Debian: se supone que un paquete que da la funcionalidad de un JRE 11 debería de declarar en la sección Provides: del paquete que aporta java11-runtime. Si no hay ningún paquete que ya provea al sistema de un runtime de Java compatible con las versiones 11 o 17, se instala default-jre, versión >= 11. Nótese que para que dpkg tenga conocimiento de esa instalación previa de Java, debe de haberse instalado también con dpkg o apt. Según de cómo de acomodador se quiera ser a los usuarios con su instalación custom de Java fuera de dpkg, esto podría ser un breaking change para ellos. En mi opinión, este es un uso menor, viendo la cantidad de comentarios de la comunidad al respecto, como veremos. Así se resuelven muchos problemas de instalación: - un usuario en ctt-gob-es#16 estuvo días con problemas por no tener Java (no el posteador) - resolves ctt-gob-es#244, donde varios usuarios vieron su problema resuelto gracias a una aclaración indicando su problema con las dependencias. - closes ctt-gob-es#258, que simplemente pregunta desconcertado. - En ctt-gob-es#263, al menos un usuario reporta haber solucionado su problema instalando Java de Oracle. - En ctt-gob-es#250, al final del hilo, un usuario reporta que el funcionamiento o no de Autofirma varía de versión a versión. - close ctt-gob-es#259, el issue mencionado al principio de este commit message. - tenemos un tutorial/explicación y todo en ctt-gob-es#302 También está la PR ctt-gob-es#268, que pide aclarar la instalación para Fedora, que sufre de exactamente lo mismo. De hecho: - ctt-gob-es#230 y ctt-gob-es#355 parecen ser tambien problemas de tener instalado java headless (el log errores menciona java.awt, abstract window toolkit). Otros 2 usuarios reportaban errores similares en ctt-gob-es#172, y otro usuario en ctt-gob-es#168 sabe que tiene headless pero no que necesita las versión no headless. Referencias: https://wiki.debian.org/Java - sección Understanding Java Virtual packages names. La misma idea de usar virtual package names surge en varias preguntas de StackOverflow: - Depender de Java pero no de ninguna implementación particular https://unix.stackexchange.com/questions/291783/can-i-indicate-that-a-deb-package-depends-on-java-but-not-specify-what-impleme - Depender de Java pero sin ser estricto en versiones https://unix.stackexchange.com/questions/550060/set-minimal-jre-version-to-deb-package-dependency y https://stackoverflow.com/questions/36181613/how-to-configure-java-7-or-java-8-dependency-in-debian-deb-package
Exige la existencia de alguna librería de Java >= 11 sin exigir ninguna versión o proveedor particular. En el issue ctt-gob-es#259 se nos motiva por qué no se exige ninguna dependencia de Java para la instalación: hay usarios que no quieren instalarse ninguna otra versión que la que ya tienen. Esto provoca mucho quebraderos de cabeza para usuarios que se instalan Autofirma sin leerse las instrucciones, acabando con instalaciones rotas - no es intuitivo para el usuario instalarse las dependencias manualmente. Para conciliar esto utilizamos los virtual packages de Debian: se supone que un paquete que da la funcionalidad de un JRE 11 debería de declarar en la sección Provides: del paquete que aporta java11-runtime. Si no hay ningún paquete que ya provea al sistema de un runtime de Java compatible con las versiones 11 o 17, se instala default-jre, versión >= 11. Nótese que para que dpkg tenga conocimiento de esa instalación previa de Java, debe de haberse instalado también con dpkg o apt. Según de cómo de acomodador se quiera ser a los usuarios con su instalación custom de Java fuera de dpkg, esto podría ser un breaking change para ellos. En mi opinión, este es un uso menor, viendo la cantidad de comentarios de la comunidad al respecto, como veremos. Así se resuelven muchos problemas de instalación: - un usuario en ctt-gob-es#16 estuvo días con problemas por no tener Java (no el posteador) - resolves ctt-gob-es#244, donde varios usuarios vieron su problema resuelto gracias a una aclaración indicando su problema con las dependencias. - closes ctt-gob-es#258, que simplemente pregunta desconcertado. - En ctt-gob-es#263, al menos un usuario reporta haber solucionado su problema instalando Java de Oracle. - En ctt-gob-es#250, al final del hilo, un usuario reporta que el funcionamiento o no de Autofirma varía de versión a versión. - close ctt-gob-es#259, el issue mencionado al principio de este commit message. - tenemos un tutorial/explicación y todo en ctt-gob-es#302 También está la PR ctt-gob-es#268, que pide aclarar la instalación para Fedora, que sufre de exactamente lo mismo. De hecho: - ctt-gob-es#230 y ctt-gob-es#355 parecen ser tambien problemas de tener instalado java headless (el log errores menciona java.awt, abstract window toolkit). Otros 2 usuarios reportaban errores similares en ctt-gob-es#172, y otro usuario en ctt-gob-es#168 sabe que tiene headless pero no que necesita las versión no headless. Referencias: https://wiki.debian.org/Java - sección Understanding Java Virtual packages names. La misma idea de usar virtual package names surge en varias preguntas de StackOverflow: - Depender de Java pero no de ninguna implementación particular https://unix.stackexchange.com/questions/291783/can-i-indicate-that-a-deb-package-depends-on-java-but-not-specify-what-impleme - Depender de Java pero sin ser estricto en versiones https://unix.stackexchange.com/questions/550060/set-minimal-jre-version-to-deb-package-dependency y https://stackoverflow.com/questions/36181613/how-to-configure-java-7-or-java-8-dependency-in-debian-deb-package
Exige la existencia de alguna librería de Java >= 11 sin exigir ninguna versión o proveedor particular. En el issue ctt-gob-es#259 se nos motiva por qué no se exige ninguna dependencia de Java para la instalación: hay usarios que no quieren instalarse ninguna otra versión que la que ya tienen. Esto provoca mucho quebraderos de cabeza para usuarios que se instalan Autofirma sin leerse las instrucciones, acabando con instalaciones rotas - no es intuitivo para el usuario instalarse las dependencias manualmente. Para conciliar esto utilizamos los virtual packages de Debian: se supone que un paquete que da la funcionalidad de un JRE 11 debería de declarar en la sección Provides: del paquete que aporta java11-runtime. Si no hay ningún paquete que ya provea al sistema de un runtime de Java compatible con las versiones 11 o 17, se instala default-jre, versión >= 11. Nótese que para que dpkg tenga conocimiento de esa instalación previa de Java, debe de haberse instalado también con dpkg o apt. Según de cómo de acomodador se quiera ser a los usuarios con su instalación custom de Java fuera de dpkg, esto podría ser un breaking change para ellos. En mi opinión, este es un uso menor, viendo la cantidad de comentarios de la comunidad al respecto, como veremos. Así se resuelven muchos problemas de instalación: - un usuario en ctt-gob-es#16 estuvo días con problemas por no tener Java (no el posteador) - resolves ctt-gob-es#244, donde varios usuarios vieron su problema resuelto gracias a una aclaración indicando su problema con las dependencias. - closes ctt-gob-es#258, que simplemente pregunta desconcertado. - En ctt-gob-es#263, al menos un usuario reporta haber solucionado su problema instalando Java de Oracle. - En ctt-gob-es#250, al final del hilo, un usuario reporta que el funcionamiento o no de Autofirma varía de versión a versión. - close ctt-gob-es#259, el issue mencionado al principio de este commit message. - tenemos un tutorial/explicación y todo en ctt-gob-es#302 También está la PR ctt-gob-es#268, que pide aclarar la instalación para Fedora, que sufre de exactamente lo mismo. De hecho: - ctt-gob-es#230 y ctt-gob-es#355 parecen ser tambien problemas de tener instalado java headless (el log errores menciona java.awt, abstract window toolkit). Otros 2 usuarios reportaban errores similares en ctt-gob-es#172, y otro usuario en ctt-gob-es#168 sabe que tiene headless pero no que necesita las versión no headless. Referencias: https://wiki.debian.org/Java - sección Understanding Java Virtual packages names. La misma idea de usar virtual package names surge en varias preguntas de StackOverflow: - Depender de Java pero no de ninguna implementación particular https://unix.stackexchange.com/questions/291783/can-i-indicate-that-a-deb-package-depends-on-java-but-not-specify-what-impleme - Depender de Java pero sin ser estricto en versiones https://unix.stackexchange.com/questions/550060/set-minimal-jre-version-to-deb-package-dependency y https://stackoverflow.com/questions/36181613/how-to-configure-java-7-or-java-8-dependency-in-debian-deb-package
Entorno: Debian GNU/Linux 11 Stable (bullseye) arquitectura amd64.
Con la versión 11 de Java la aplicación AutoFirma abre correctamente, pero con la 17 (disponible de bullseye-backports) no:
The text was updated successfully, but these errors were encountered: