Temurin-build: Отсутствие DLL означает, что пользователи вынуждены загружать распространяемый компонент Microsoft Visual C ++.

@johanvos - это то, что вы ожидаете от нашего дистрибутива, или это часть пакета JavaFX?

Это часть дистрибутива OpenJDK, поэтому по соображениям согласованности я думаю, что он также должен быть частью дистрибутива AdoptOpenJDK?

Отлично, спасибо! @ ali- ince /

Включение dll в пакет увеличит размер дистрибутива OpenJDK, что следует учитывать. Microsoft не рекомендует статическое связывание или включать DLL в свой собственный каталог, поскольку обновление ОС / безопасности может не относиться к этой среде выполнения.

Смотрим на: https://social.msdn.microsoft.com/Forums/en-US/a28331ae-19a3-4a34-b3ba-1e8fd4430375/missing-apimswincore-dlls

Похоже, это библиотеки уровня ОС, но каким-то образом они изменили название. Сообщество MS предлагает использовать mincore.lib, который является прокладкой для всей поверхности api, но двоичный файл будет работать только с Windows 8+.

В качестве альтернативы мы можем, вероятно, распространить полную распространяемую программу установки Visual C ++ в нашем пакете установщика.

Какой был бы хороший вариант?

@sunnythepooh

В качестве альтернативы мы можем, вероятно, распространить полную распространяемую программу установки Visual C ++ в нашем пакете установщика.

Фу !!!

AdoptOpenJDK должен стать заменой для выпуска jdk.java.net.

Если вы заставите конечных пользователей прыгать через обруч, это будет очень разрушительно для ценностного предложения приложений с нулевой зависимостью jlink'd.

ИМХО, хотя я вижу причину, по которой вы могли бы подумать о включении перенаправителя VC ++ в AdoptOpenJDK, вы должны включать его только в том случае, если этого требует .dll, и поскольку единственное, что требует этого, - это собственный .dll JavaFX, тогда причина для включения кажется странной .

Для пакета JavaFX имеет больше смысла включать его.

Или включил его в дополнительный пакет AdoptOpenJavaFX :-)

Для пакета JavaFX имеет больше смысла включать его.

Я вижу, что вы можете быть абсолютно правы в том, что .dll в идеальном мире должны быть в пакете JavaFX.

Между тем, пока вы не начнете предоставлять свой собственный пакет AdoptOpenJavaFX или не убедите Gluon включить .dll в свой пакет, AdoptOpenJDK будет непригодным для использования в приложениях JavaFX.

Я уверен, что есть множество лучших долгосрочных подходов, но в то же время это недопустимое состояние неопределенности для AdoptOpenJDK.

Я думаю, что основная проблема здесь может заключаться в том, что AdoptOpenJDK создает JDK с другой версией Visual Studio (я проверю, но, вероятно, это VS2013), чем та, с которой построен JavaFX (учитывая отсутствие имен DLL, это, вероятно, VS2017).

Я попробую сначала проверить версию VS и обновить ее здесь.

Я заметил, что AdoptOpenJDK 12 (точка доступа) теперь имеет необходимые библиотеки DLL, поэтому все работает отлично для приложений JavaFX.

Спасибо!!!

Я заметил, что AdoptOpenJDK 12 (точка доступа) теперь имеет необходимые библиотеки DLL, поэтому все работает отлично для приложений JavaFX.

Спасибо!!!

Приятно слышать - для Java 11 и 8 я подозреваю, что эта проблема будет решена в самое ближайшее время. @ ali-ince Сейчас мы строим с VS 2017 для всех версий?

Еще нет @karianna , это все еще продолжается. Я обновлю эту ветку, когда мы перейдем на vs2017.

Быстрое обновление по этому поводу;

1. 64-битные сборки JDK11u теперь переведены на VS2017.
2. 32-разрядные сборки JDK11u находятся на VS2013. Исправление, которое позволит 32-разрядной версии JDK11u скомпилировать с VS2017, будет запущено с обновлением 11.0.4, и мы переключимся на VS2017 параллельно с этим.
3. 32-разрядные и 64-разрядные сборки JDK8u теперь переключаются на VS2013 (ранее они были смешанными на VS2010 / VS2013). Мы работаем над тем, чтобы они были построены на VS2017, но, похоже, потребуется больше времени, чтобы получить исправление для отправки в апстрим.

Привет!
У нас есть проблемы в нашей клиентской среде с отсутствующими библиотеками времени выполнения C.
Как обстоят дела с этим вопросом?

Обходной путь заключается в установке среды выполнения C на ВСЕХ тысячах клиентских систем, в которых она не установлена ​​вместе с операционной системой.
Мы не можем заставить нашего клиента сделать это или перейти, например, с Windows Server 2012 R2 на более новые версии, если сама Microsoft поддерживает эти версии.

//РЕДАКТИРОВАТЬ:
Есть ли еще какие-нибудь обходные пути?