Temurin-build: DLLs ausentes significa que os usuários são forçados a baixar o Microsoft Visual C ++ Redistributable

@johanvos - Isso é algo que você esperaria que nossa distro tivesse ou faz parte do pacote JavaFX no topo?

É parte da distribuição OpenJDK, então por razões de consistência, eu acho que deveria fazer parte da distribuição AdoptOpenJDK também.

Muito obrigado! @ ali- ince /

Incluir dlls no pacote aumentaria o tamanho da distribuição do OpenJDK, o que deve ser levado em consideração. A Microsoft não recomenda vinculação estática ou incluir a DLL em seu próprio diretório, pois o sistema operacional / atualização de segurança pode não se aplicar a esses sistemas de tempo de execução

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

Parece que essas são bibliotecas de nível de sistema operacional, mas de alguma forma eles mudaram o nome. A sugestão da comunidade MS é que devemos usar mincore.lib, que é um shim para toda a superfície da API, mas o binário só funcionaria com o Windows 8+.

Como alternativa, podemos provavelmente distribuir o instalador redistribuível completo do Visual C ++ em nosso pacote de instalação.

Qual seria uma boa opção?

@sunnythepooh

Como alternativa, podemos provavelmente distribuir o instalador redistribuível completo do Visual C ++ em nosso pacote de instalação.

Que nojo!!!

AdoptOpenJDK deve ser um substituto imediato para a versão jdk.java.net.

Se você fizer os usuários finais saltarem por obstáculos, seria muito prejudicial para a proposta de valor dos aplicativos jlink de dependência zero.

IMHO, embora eu possa ver a razão pela qual você consideraria incluir o redist VC ++ em AdoptOpenJDK, você só deve incluí-lo se um .dll exigir e porque a única coisa que exige é o próprio .dll do JavaFX, então o motivo para incluir parece estranho .

Faz mais sentido que o pacote JavaFX o inclua.

Ou incluí-lo em um pacote extra AdoptOpenJavaFX :-)

Faz mais sentido que o pacote JavaFX o inclua.

Posso ver que você pode estar absolutamente certo de que os .dlls em um mundo ideal devem estar em um pacote JavaFX.

Enquanto isso, entretanto, até que você possa começar a fornecer seu próprio pacote AdoptOpenJavaFX ou convencer o Gluon a incluir os .dlls em seu pacote, o AdoptOpenJDK é inutilizável para aplicativos JavaFX.

Tenho certeza de que existem todos os tipos de abordagens melhores de longo prazo, mas, por enquanto, esse é um estado de limbo inaceitável para o AdoptOpenJDK.

Acho que o principal problema aqui pode ser que o AdoptOpenJDK constrói o JDK com uma versão diferente do visual studio (irei verificar, mas provavelmente é VS2013) do que o JavaFX foi criado (dados os nomes DLL ausentes, provavelmente é VS2017).

Vou tentar verificar a versão do VS primeiro e atualizar aqui.

Percebi que o AdoptOpenJDK 12 (hotspot) agora tem as DLLs necessárias, então tudo funciona perfeitamente para aplicativos JavaFX.

Obrigada!!!

Percebi que o AdoptOpenJDK 12 (hotspot) agora tem as DLLs necessárias, então tudo funciona perfeitamente para aplicativos JavaFX.

Obrigada!!!

Bom saber - para Java 11 e 8, suspeito que esse problema será resolvido durante a noite agora. @ ali-ince Estamos construindo com o VS 2017 para todas as versões agora?

Ainda não @karianna , ainda está em andamento. Vou atualizar este tópico quando mudarmos para o vs2017.

Uma atualização rápida sobre isso;

1. As compilações JDK11u de 64 bits agora são alteradas para VS2017.
2. As compilações JDK11u de 32 bits estão no VS2013. Uma correção que permitirá que o JDK11u de 32 bits seja compilado com o VS2017 será lançada com a atualização 11.0.4 e iremos mudar para o VS2017 paralelamente a isso.
3. As compilações JDK8u de 32 bits e 64 bits agora são trocadas para o VS2013 (anteriormente, eles estavam no VS2010 / VS2013 mistos). Estamos trabalhando para que eles também sejam compilados no VS2017, mas isso parece levar mais algum tempo para obter uma correção para envio ao upstream.

Oi!
Temos problemas em nosso ambiente de cliente com as bibliotecas de tempo de execução C ausentes.
Como está o status deste problema?

A solução alternativa seria instalar o tempo de execução C em TODOS os milhares de sistemas cliente que não o possuem instalado com o sistema operacional.
Não podemos forçar nosso cliente a fazer isso ou mudar, por exemplo, do Windows Server 2012 R2 para versões mais recentes, desde que a própria Microsoft suporte essas versões.

//EDITAR:
Existem outras soluções alternativas entretanto?