>8 не рекомендуется для новых разработок
Всё верно, зачем новую разработку начинать на устаревшей платформе? Кто так делает?
>все время предлагает перейти на более свежую версию
Не видел такого, т.е. у пользователя на Windows стоит 8-ка и Updater постоянно предлагает обновиться на 10-ку?
>Это как бы признак огромного кризиса и проблем в языке.
Нет, это перемены, необходимые для дальнейшего роста популярности JVM. Сделали, то, что давно нужно было сделать. Такие точки перелома есть везде, например Windows 98 -> Windows XP или x32 -> x64 и т.д.
>У вас точно кросс-платформенное приложение? ;)
Да. В Windows приложение должно лежать в Program Files/app.name. И по прежнему есть user.home
>Но фактически вы предлагаете в папке программы держать ровно один файл.
Нет, можете там держать остальные библиотеки требуемые для старта приложения. В 9-ке появилась возможность делать сборки, поэтому будут еще файлы JRE. Но я пока такую сборку не пробовал.
>приложение под Windows взаимодействует с другими исполняемыми файлами
>Или приложение сильно модульное, где набор модулей задаётся на этапе установки
Для таких ситуаций делают инсталятор. И как я говорил, всё должно лежать в Program Files/app.name, в других ОС читайте инструкции, где и что должно лежать.
>Хаки? Мне нужно обычное кросс-платформенное desktop GUI приложение и чтобы оно реально работало.
Я вам предложил вариант. Он рабочий. Можете также использовать ProcessHandle API, если вы не наврнёте новых хаков на пускалку вашего JAR-а, то это API будет нормально работать.
>В моём случае пользователь просто распаковывает tgz и вперёд
И что, вы в рантайме не можете создать user.home/.app.name скопировав туда конфиги из JAR-а? И туда же устанавливать плагины, если у вас настолько простое развёртывание?
>говорит сам за себя
В 99.9% подобных багов это криворукость разработчика, а не сбой промышленной платформы с миллионами разработчиков.
>то времени и желания переписывать кучу кода у меня нет
Так сидите на 8-ке, она до 2020 поддерживается. Зачем вы ринулись под 9-ку всё переписывать? На 9-ку толком никто не переходил, только с 10-ой, когда более-менее всё отшлифовалось — люди стали переползать.
>а если инструмент не работает и всё время ломается, то его нужно менять инструмент
А вы думаете где-то лучше? ) Везде так, это ИТ, куча легаси и постоянное движение впёред. И джава среди прочих инструментов еще более-менее вменяемая.
>плагины
Обычно в user.home/app.name, можно в /usr/lib/app.name Можно даже в /usr/lib/jvm
>ресурсы и прочую муть
Обычно пакуется в JAR
>файл может быть запущен разными способами, включая запуск из всяких «запускальщиков»
Если вам нужны подобные хаки, то гуглите новые хаки для 10-ки, если старые перестали работать.
>Проверили эту строчку или
Не нашел, чем у вас там строчка отличается. Просто скопировал, код из статьи в IDE и всё.
>Ничего просто не соберётся
А вы чем собираете? У меня с Maven проблем не было, всё собирается, я даже ни каких module-info.java не добавлял. И в зависимостях куча древних JAR-ов. И в проекте ничего не менял, всё стандартно по мавенскому шаблону.
>Это обычно нужно, чтобы понять, где искать файлы приложения — конфигурацию, плагины и т.п.
У приложения должен быть константный каталог в user.home с нужной конфигурацией. Если хотите узнать о текущем процессе больше, то появился новый API ProcessHandle.
>Files.readAllLines("/etc/mime.types", Charset.defaultCharset())
Проверил — у меня работает.
>Это нереалистичная идея. Вычислительная сложность огромная. Условия меняются.
Большинство программ работают линейно, у них всегда есть протоптанный путь на графе условных переходов. Минимумы и максимумы входящих и исходящих данных у конкретного пользователя довольно просто предсказывать.
>Какие параметры мы будем оценивать? Как будем изменять алгоритм в зависимости от того, что получили сбором статистики?
Это исследовательская задача, которая требует не сыкунов с границами в мышлении и теплым местечком в корпорации с бесплатной едой и абонементов на фитнес. Такая задача требует новых бунтарей и пионеров.
>Я считаю, что и в вебе должно быть тоже самое.
Но в вебе не тоже самое. Все пишут на JavaScript или извращаются с трансляцией ЯП в JavaScript. Решить проблему хотят с помощью WebAssembly, но сейчас это очень обрезанный рантайм и все ждут следующую версию WebAssembly, которая уже как год проектируется.
По сути WebAssembly, та же JVM, но со своими тараканами. Поэтому не нужно «для каждого языка тащить в стандарт его рантайм». В стандарте есть описание байт-кода и вам нужно натянуть рантайм конкретного языка на этот байт-код.
Но когда выйдет WebAssemlbly 2.0 неизвестно. Поэтому сейчас можно сделать HTML и CSS движок, отказавшись от JavaScript, замапив работу с DOM напрямую, на методы конкретного ЯП. Тем самым можно манипулировать DOM из своего любимого ЯП, не нагружая рендеринг HTML и CSS прослойкой из JavaScript движка, полностью отказавшись от него.
Т.е. использовать HTML и CSS движок как кроссплатформенную GUI библиотеку, заместо QT и подобных решений. И ничего более я не предлагаю ) Единственно, для манипуляций с DOM, необходимо соблюдать все W3C стандарты. А значит придеться столкнуться с тем, что не всё API от W3C красиво ляжет на статически типизированные языки. Поэтому потребуется особый маппинг такого API. Но это проблема уже конкретного ЯП, а само стандартное API не должно как-либо изменяться.
>Джава то зачем?
Хороший и популярный ЯП для кроссплатформенной разработки. После джавы можно один в один сделать C++ и С# маппинг DOM API. У Rust и Go достаточно активное и компетентное комьюнити, чтобы они самостоятельно сделали эмбединг этого движка. Остаётся Node.js, но там и маппить, то нечего плевая работа.
Кстати, sciter.com/blog посмотрите на похожую идею. Реализация ужасна, маркетинг ужасен, но люди ведут блог с 2006 года, может даже что-то зарабатывают…
>Нужен какой-то понимающий в этом деле партнёр, наверное.
Если у вас будет, плохонький, но работающий прототип, с рендерингом HTML и CSS, то на электронную почту вам куча партнёров насыпится. Думаю можно даже на индигого стартануть с этим прототипом.
Я могу помочь в плане эмбединга с джавой и маппингом DOM API. Маппинг DOM API на джаву у меня готов, путем парсинга IDL в исхдниках Chromium. Сейчас работаю над веб-фреймворком по типу Angular, который базируется на этом маппинге (т.е. все пишется на джаве).
По итогу могу сделать сайт проекта, реально работающие приложения, на которые можно ссылаться как на примеры. Может быть даже сделаю какой-нибудь маркетинг в интернете, насколько я это умею делать.
С wasm выйдет сложнее. Во-первых, непонятно когда будет wasm 2.0, а во-вторых, затем еще нужно рантайм каждого ЯП портировать или ждать пока портируют.
Проще отмапить DOM API на конкретный ЯП и эмдедить движок в этот ЯП. Это можно хоть сейчас делать и это всем нужно. И более того, этот маппинг DOM API также будет востребован в рантайме wasm 2.0
Почему бы не сосредоточиться на разработке браузера для веб-приложений? Сделайте основную базу из HTML и CSS, чтобы можно было рендерить GUI. Добавьте вебсокет или другой апи для IPC с бекэндом. Оптимизируйте, чтобы по памяти занимало крохи, запускалось на любой табуретке без тормозов и вам гарантирован успех.
А потом уже делайте полноценный браузер на донатах или коммерческих продажах выше приведенного решения.
Я это даже вижу без джаваскрипта, когда можно все это дело заэмбендить в ту же джаву и отмапить DOM API на джава код. Я бы даже помог на этом участке.
Всё верно, зачем новую разработку начинать на устаревшей платформе? Кто так делает?
>все время предлагает перейти на более свежую версию
Не видел такого, т.е. у пользователя на Windows стоит 8-ка и Updater постоянно предлагает обновиться на 10-ку?
>Это как бы признак огромного кризиса и проблем в языке.
Нет, это перемены, необходимые для дальнейшего роста популярности JVM. Сделали, то, что давно нужно было сделать. Такие точки перелома есть везде, например Windows 98 -> Windows XP или x32 -> x64 и т.д.
Да. В Windows приложение должно лежать в Program Files/app.name. И по прежнему есть user.home
>Но фактически вы предлагаете в папке программы держать ровно один файл.
Нет, можете там держать остальные библиотеки требуемые для старта приложения. В 9-ке появилась возможность делать сборки, поэтому будут еще файлы JRE. Но я пока такую сборку не пробовал.
>приложение под Windows взаимодействует с другими исполняемыми файлами
>Или приложение сильно модульное, где набор модулей задаётся на этапе установки
Для таких ситуаций делают инсталятор. И как я говорил, всё должно лежать в Program Files/app.name, в других ОС читайте инструкции, где и что должно лежать.
>Хаки? Мне нужно обычное кросс-платформенное desktop GUI приложение и чтобы оно реально работало.
Я вам предложил вариант. Он рабочий. Можете также использовать ProcessHandle API, если вы не наврнёте новых хаков на пускалку вашего JAR-а, то это API будет нормально работать.
И что, вы в рантайме не можете создать user.home/.app.name скопировав туда конфиги из JAR-а? И туда же устанавливать плагины, если у вас настолько простое развёртывание?
>говорит сам за себя
В 99.9% подобных багов это криворукость разработчика, а не сбой промышленной платформы с миллионами разработчиков.
Так сидите на 8-ке, она до 2020 поддерживается. Зачем вы ринулись под 9-ку всё переписывать? На 9-ку толком никто не переходил, только с 10-ой, когда более-менее всё отшлифовалось — люди стали переползать.
>а если инструмент не работает и всё время ломается, то его нужно менять инструмент
А вы думаете где-то лучше? ) Везде так, это ИТ, куча легаси и постоянное движение впёред. И джава среди прочих инструментов еще более-менее вменяемая.
/etc/app.name
>плагины
Обычно в user.home/app.name, можно в /usr/lib/app.name Можно даже в /usr/lib/jvm
>ресурсы и прочую муть
Обычно пакуется в JAR
>файл может быть запущен разными способами, включая запуск из всяких «запускальщиков»
Если вам нужны подобные хаки, то гуглите новые хаки для 10-ки, если старые перестали работать.
>Проверили эту строчку или
Не нашел, чем у вас там строчка отличается. Просто скопировал, код из статьи в IDE и всё.
Нет, здесь он начинает расцвет.
>и тогда на смену Java нужно искать другой инструмент
Т.е. искать новый инструмент и переписывать код с нуля у вас время найдётся, а почитать документацию и пофиксить
недокументированные хакибаги: «Разбираться, в чём проблема времени не хватило.» ©А вы чем собираете? У меня с Maven проблем не было, всё собирается, я даже ни каких module-info.java не добавлял. И в зависимостях куча древних JAR-ов. И в проекте ничего не менял, всё стандартно по мавенскому шаблону.
>Это обычно нужно, чтобы понять, где искать файлы приложения — конфигурацию, плагины и т.п.
У приложения должен быть константный каталог в user.home с нужной конфигурацией. Если хотите узнать о текущем процессе больше, то появился новый API ProcessHandle.
>Files.readAllLines("/etc/mime.types", Charset.defaultCharset())
Проверил — у меня работает.
Большинство программ работают линейно, у них всегда есть протоптанный путь на графе условных переходов. Минимумы и максимумы входящих и исходящих данных у конкретного пользователя довольно просто предсказывать.
>Какие параметры мы будем оценивать? Как будем изменять алгоритм в зависимости от того, что получили сбором статистики?
Это исследовательская задача, которая требует не сыкунов с границами в мышлении и теплым местечком в корпорации с бесплатной едой и абонементов на фитнес. Такая задача требует новых бунтарей и пионеров.
Собрать статистику паттернов работы? И в последствии генерировать код алокатора под конкретный паттерн?
Так вот она какая каша из топора...
Но в вебе не тоже самое. Все пишут на JavaScript или извращаются с трансляцией ЯП в JavaScript. Решить проблему хотят с помощью WebAssembly, но сейчас это очень обрезанный рантайм и все ждут следующую версию WebAssembly, которая уже как год проектируется.
По сути WebAssembly, та же JVM, но со своими тараканами. Поэтому не нужно «для каждого языка тащить в стандарт его рантайм». В стандарте есть описание байт-кода и вам нужно натянуть рантайм конкретного языка на этот байт-код.
Но когда выйдет WebAssemlbly 2.0 неизвестно. Поэтому сейчас можно сделать HTML и CSS движок, отказавшись от JavaScript, замапив работу с DOM напрямую, на методы конкретного ЯП. Тем самым можно манипулировать DOM из своего любимого ЯП, не нагружая рендеринг HTML и CSS прослойкой из JavaScript движка, полностью отказавшись от него.
Т.е. использовать HTML и CSS движок как кроссплатформенную GUI библиотеку, заместо QT и подобных решений. И ничего более я не предлагаю ) Единственно, для манипуляций с DOM, необходимо соблюдать все W3C стандарты. А значит придеться столкнуться с тем, что не всё API от W3C красиво ляжет на статически типизированные языки. Поэтому потребуется особый маппинг такого API. Но это проблема уже конкретного ЯП, а само стандартное API не должно как-либо изменяться.
Так сколько хеловорд с гралем оперативки займет? Заметил, что начиная с восьмёрки, хеловорд что-то в районе 16Мб забирает в 64 битном линуксе.
>Джава то зачем?
Хороший и популярный ЯП для кроссплатформенной разработки. После джавы можно один в один сделать C++ и С# маппинг DOM API. У Rust и Go достаточно активное и компетентное комьюнити, чтобы они самостоятельно сделали эмбединг этого движка. Остаётся Node.js, но там и маппить, то нечего плевая работа.
Если у вас будет, плохонький, но работающий прототип, с рендерингом HTML и CSS, то на электронную почту вам куча партнёров насыпится. Думаю можно даже на индигого стартануть с этим прототипом.
Я могу помочь в плане эмбединга с джавой и маппингом DOM API. Маппинг DOM API на джаву у меня готов, путем парсинга IDL в исхдниках Chromium. Сейчас работаю над веб-фреймворком по типу Angular, который базируется на этом маппинге (т.е. все пишется на джаве).
По итогу могу сделать сайт проекта, реально работающие приложения, на которые можно ссылаться как на примеры. Может быть даже сделаю какой-нибудь маркетинг в интернете, насколько я это умею делать.
Проще отмапить DOM API на конкретный ЯП и эмдедить движок в этот ЯП. Это можно хоть сейчас делать и это всем нужно. И более того, этот маппинг DOM API также будет востребован в рантайме wasm 2.0
Почему бы не сосредоточиться на разработке браузера для веб-приложений? Сделайте основную базу из HTML и CSS, чтобы можно было рендерить GUI. Добавьте вебсокет или другой апи для IPC с бекэндом. Оптимизируйте, чтобы по памяти занимало крохи, запускалось на любой табуретке без тормозов и вам гарантирован успех.
А потом уже делайте полноценный браузер на донатах или коммерческих продажах выше приведенного решения.
Я это даже вижу без джаваскрипта, когда можно все это дело заэмбендить в ту же джаву и отмапить DOM API на джава код. Я бы даже помог на этом участке.