Temurin-build: Fehlende DLLs bedeuten, dass Benutzer gezwungen sind, Microsoft Visual C ++ Redistributable herunterzuladen

@johanvos - Ist das etwas, was Sie von unserer Distribution erwarten würden, oder ist das Teil des JavaFX-Pakets oben

Es ist Teil der OpenJDK-Distribution. Aus Konsistenzgründen denke ich, dass es auch Teil der AdoptOpenJDK-Distribution sein sollte.

Grosses Dankeschön! @ ali-ince / @johnoliver eine, in die wir schauen können

Das Einfügen von DLLs in das Paket würde die Größe der OpenJDK-Distribution erhöhen, was eine Überlegung sein sollte. Microsoft empfiehlt keine statische Verknüpfung oder nimmt die DLL nicht in Ihr eigenes Verzeichnis auf, da das Betriebssystem- / Sicherheitsupdate möglicherweise nicht für diese Laufzeit gilt

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

Es sieht so aus, als wären dies Bibliotheken auf Betriebssystemebene, aber irgendwie haben sie den Namen geändert. Der Vorschlag der MS-Community ist, dass wir mincore.lib verwenden sollten, eine Unterlegscheibe für die gesamte API-Oberfläche, aber die Binärdatei würde nur mit Windows 8+ funktionieren.

Alternativ können wir wahrscheinlich das vollständige verteilbare Visual C ++ - Installationsprogramm in unserem Installationspaket verteilen.

Was wäre eine gute Option?

@sunnythepooh

Alternativ können wir wahrscheinlich das vollständige verteilbare Visual C ++ - Installationsprogramm in unserem Installationspaket verteilen.

Yuck !!!

AdoptOpenJDK sollte ein Ersatz für die Version jdk.java.net sein.

Wenn Sie Endbenutzer dazu bringen, durch Reifen zu springen, wäre dies für das Wertversprechen von jlink'd-Apps ohne Abhängigkeit sehr schädlich.

IMHO, obwohl ich den Grund sehen kann, warum Sie in Betracht ziehen würden, die VC ++ - Redist in AdoptOpenJDK aufzunehmen, sollten Sie sie nur einschließen, wenn eine DLL dies erfordert und weil das einzige, was dies erfordert, die eigene DLF von JavaFX ist, erscheint der Grund für die Aufnahme seltsam .

Es ist sinnvoller, das JavaFX-Paket einzuschließen.

Oder in einem AdoptOpenJavaFX-Extrapaket enthalten :-)

Es ist sinnvoller, das JavaFX-Paket einzuschließen.

Ich kann sehen, dass Sie absolut Recht haben, dass sich die DLLs in einer idealen Welt in einem JavaFX-Paket befinden sollten.

In der Zwischenzeit ist AdoptOpenJDK für JavaFX-Apps unbrauchbar, bis Sie Ihr eigenes AdoptOpenJavaFX-Paket bereitstellen oder Gluon davon überzeugen können, die DLLs in das Paket aufzunehmen.

Ich bin mir sicher, dass es alle möglichen besseren langfristigen Ansätze gibt, aber in der Zwischenzeit ist dies für AdoptOpenJDK ein inakzeptabler Schwebezustand.

Ich denke, das Hauptproblem hier könnte sein, dass AdoptOpenJDK das JDK mit einer anderen Version von Visual Studio erstellt (ich werde es überprüfen, aber es ist wahrscheinlich VS2013) als JavaFX (da die DLL-Namen fehlen, ist es wahrscheinlich VS2017).

Ich werde versuchen, zuerst die Version von VS zu überprüfen und hier zu aktualisieren.

Ich habe festgestellt, dass AdoptOpenJDK 12 (Hotspot) jetzt über die erforderlichen DLLs verfügt, sodass für JavaFX-Apps alles perfekt funktioniert.

Vielen Dank!!!

Ich habe festgestellt, dass AdoptOpenJDK 12 (Hotspot) jetzt über die erforderlichen DLLs verfügt, sodass für JavaFX-Apps alles perfekt funktioniert.

Vielen Dank!!!

Gut zu hören - Für Java 11 und 8 vermute ich, dass dieses Problem jetzt in den Nightlies behoben sein wird. @ ali-ince Bauen wir jetzt mit VS 2017 für alle Versionen?

Noch nicht @karianna , das ist noch in Arbeit. Ich werde diesen Thread aktualisieren, wenn wir zu vs2017 wechseln.

Ein kurzes Update dazu;

1. JDK11u 64-Bit-Builds werden jetzt auf VS2017 umgestellt.
2. JDK11u 32-Bit-Builds befinden sich auf VS2013. Ein Fix, der es JDK11u 32-Bit ermöglicht, mit VS2017 zu kompilieren, wird mit dem 11.0.4-Update gestartet und wir werden parallel dazu zu VS2017 wechseln.
3. JDK8u 32-Bit- und 64-Bit-Builds werden jetzt auf VS2013 umgestellt (zuvor waren sie auf VS2010 / VS2013 gemischt). Wir arbeiten daran, dass diese auch auf VS2017 aufbauen, aber es scheint etwas länger zu dauern, bis ein Fix für die Übermittlung an Upstream vorliegt.

Hallo!
Wir haben Probleme in unserer Kundenumgebung mit den fehlenden C-Laufzeitbibliotheken.
Wie ist der Status zu diesem Thema?

Die Problemumgehung besteht darin, die C-Laufzeit auf ALLEN Tausenden von Client-Systemen zu installieren, auf denen sie nicht mit dem Betriebssystem installiert ist.
Wir können unseren Kunden nicht dazu zwingen oder von Windows Server 2012 R2 auf neuere Versionen umsteigen, solange Microsoft diese Versionen selbst unterstützt.

//BEARBEITEN:
Gibt es in der Zwischenzeit weitere Problemumgehungen?