Temurin-build: La falta de DLL significa que los usuarios se ven obligados a descargar Microsoft Visual C ++ Redistributable

@johanvos - ¿Es esto algo que esperarías que tuviese nuestra distribución o es parte del paquete JavaFX en la parte superior?

Es parte de la distribución OpenJDK, así que por razones de coherencia, creo que también debería ser parte de la distribución AdoptOpenJDK.

¡Genial gracias! @ ali-ince / @johnoliver uno para que lo miremos

La inclusión de dlls en el paquete aumentaría el tamaño del distribuible de OpenJDK, lo que debería tenerse en cuenta. Microsoft no recomienda la vinculación estática ni incluye la DLL en su propio directorio, ya que es posible que la actualización de seguridad / sistema operativo no se aplique a esos tiempos de ejecución.

Mirando: https://social.msdn.microsoft.com/Forums/en-US/a28331ae-19a3-4a34-b3ba-1e8fd4430375/missing-apimswincore-dlls

Parece que esas son bibliotecas de nivel de sistema operativo, pero de alguna manera han cambiado el nombre. La sugerencia de la comunidad de MS es que deberíamos usar mincore.lib, que es una corrección para toda la superficie de la API, pero el binario solo funcionaría con Windows 8+.

Alternativamente, podemos distribuir probablemente el instalador redistribuible de Visual C ++ completo en nuestro paquete de instalación.

¿Cuál sería una buena opción?

@sunnythepooh

Alternativamente, podemos distribuir probablemente el instalador redistribuible de Visual C ++ completo en nuestro paquete de instalación.

¡¡¡Qué asco !!!

AdoptOpenJDK debería ser un reemplazo directo para la versión jdk.java.net.

Si hace que los usuarios finales salten por el aro, sería muy perjudicial para la propuesta de valor de las aplicaciones jlink de dependencia cero.

En mi humilde opinión, aunque puedo ver la razón por la que consideraría incluir el VC ++ redist en AdoptOpenJDK, solo debe incluirlo si un .dll lo requiere y porque lo único que lo requiere es el propio .dll de JavaFX, entonces la razón para incluirla parece extraña .

Tiene más sentido que el paquete JavaFX lo incluya.

O incluirlo en un paquete adicional AdoptOpenJavaFX :-)

Tiene más sentido que el paquete JavaFX lo incluya.

Puedo ver que puede tener toda la razón en que los .dlls en un mundo ideal deberían estar en un paquete JavaFX.

Mientras tanto, sin embargo, hasta que pueda comenzar a proporcionar su propio paquete AdoptOpenJavaFX o convencer a Gluon de que incluya los .dlls en su paquete, AdoptOpenJDK no se puede utilizar para las aplicaciones JavaFX.

Estoy seguro de que hay todo tipo de enfoques mejores a largo plazo, pero mientras tanto, este es un estado de limbo inaceptable para AdoptOpenJDK.

Creo que el principal problema aquí puede ser que AdoptOpenJDK construye el JDK con una versión diferente de Visual Studio (lo comprobaré, pero probablemente sea VS2013) de la que está construido JavaFX (dado que faltan los nombres de DLL, probablemente sea VS2017).

Intentaré verificar la versión de VS primero y actualizar aquí.

Me di cuenta de que AdoptOpenJDK 12 (hotspot) ahora tiene las DLL necesarias, por lo que todo funciona perfectamente para las aplicaciones JavaFX.

¡¡¡Gracias!!!

Me di cuenta de que AdoptOpenJDK 12 (hotspot) ahora tiene las DLL necesarias, por lo que todo funciona perfectamente para las aplicaciones JavaFX.

¡¡¡Gracias!!!

Es bueno escucharlo: para Java 11 y 8, sospecho que este problema se resolverá ahora en las noches. @ ali-ince ¿Estamos construyendo con VS 2017 para todas las versiones ahora?

Todavía no @karianna , eso todavía está en progreso. Actualizaré este hilo cuando cambiemos a vs2017.

Una actualización rápida sobre esto;

1. Las compilaciones JDK11u de 64 bits ahora se cambiaron a VS2017.
2. Las compilaciones de JDK11u de 32 bits están en VS2013. Una solución que permitirá que JDK11u de 32 bits se compile con VS2017 se lanzará con la actualización 11.0.4 y cambiaremos a VS2017 en paralelo.
3. Las compilaciones JDK8u de 32 y 64 bits ahora se cambiaron a VS2013 (anteriormente estaban mezcladas con VS2010 / VS2013). Estamos trabajando para que también se desarrollen en VS2017, pero parece que tomará más tiempo obtener una solución para su envío a upstream.

¡Hola!
Tenemos problemas en el entorno de nuestro cliente con las bibliotecas de tiempo de ejecución de C que faltan.
¿Cómo está el estado de este tema?

La solución alternativa sería instalar el tiempo de ejecución de C y TODOS los miles de sistemas cliente que no lo tienen instalado con el sistema operativo.
No podemos obligar a nuestro cliente a hacer esto o pasar de, por ejemplo, Windows Server 2012 R2 a versiones más nuevas siempre que Microsoft sea compatible con estas versiones.

//EDITAR:
¿Hay otras soluciones mientras tanto?