Дмитрий Александров

Загвоздка в том что javafx стал модулем и сама модульная система работает чуть иначе.
Собственно раньше в java8 было так что:

• собрал jar и запускаешь его командой "java -jar имя_файла.jar"
  
• если есть зависимые библиотеки то так "java -cp зависимые_библиотеки.jar -jar имя_файла.jar"
  
• можно собрать fatjar. Тут зависимости при сборке вашего jar помещаются внутрь вашего jar. Запуск такой "java -jar имя_файла.jar"
  

Проблема зависимостей связана с тем что они тащят всю библиотеку за собой.

С приходом java9 и новее пришли модули которые по сути "должны" заменить старую систему зависимостей и проблему таскания ненужного кода в библиотеках.
Теперь так, но учтите что тут есть подводные камни т.к. работает и старая и новая система и могут даже пересекаться между собой. Для примера вы можете собрать свой jar как модуль или по старинке "тупой jar"

• если программа не берет никакие модули то можно по старинке "java -jar имя_файла.jar"
  
• если программа сама собранна как модуль "java --module-path "путь\до\директории\с\модулем\проги" --add-modules имя.модуля.вашей.проги -m имя.модуля.вашей.проги/имя.главного.класса"
  
• если есть другие зависимые модули то все в точности как в предыдущем пункте
  
• так же могут быть собраны fatjar как в java8
  

Вам для запуска надо так "java --module-path "на последнем скрине путь ваш есть" --add-modules javafx.controls,javafx.fxml -jar имя_файла.jar -m имя.модуля.вашей.проги/имя.главного.класса".

Это очень поверхностно и крайне кратко все. В целом система модулей предполагает что вы больше не должны отправлять вашу программу в виде jar, а должны собрать самодостаточную программу. Т.е. в компиляторах есть утилиты что бы упаковать вашу программу вместе со всеми необходимыми модулями и jre, пользователь же просто запускает ее не устанавливая jre\javafx\кучи библиотек.

JavaFX просто отображает графику и работает ВСЕГДА в одном своем потоке. Для взаимодействия с ней(что то пошевелить на экране) из другого потока используется такая штука Platform.runLater(java.lang.Runnable runnable).
В вашей задаче я себе представляю картину так:
Сервер:
1)держит состояния 4х переменных. ПоложениеИ1(у),ПоложениеИ2(у),ПоложениеМяча(х,у),ВекторНаправленияМяча(х,у). По хорошему еще дополнительно количество очков для каждого игрока и флаг для каждого игрока о готовности игры\паузы.
2)слушает сокет и ожидает игроков. Как только игроки подключились начинает принимать от игроков их положения клюшек и вносить в переменные. Симулирует игровое поле в отдельном потоке по фиксированному числу тиков с положениями клюшек игроков, мяча и его движения. Отправляет игрокам положения клюшек, и мяча. Опционально шлет количество очков и запускает\паузит игру по флагам от игроков.
Не забывает что все в игре максимально детерминированно, т.е. размер поля для симуляции известен, положения игроков известно и т.д. Т.е. все прекрасно симулируется.

Клиент:
1) держит состояния 4х переменных. ПоложениеСебя(у),ПоложениеИ2(у),ПоложениеМяча(х,у),ВекторНаправленияМяча(х,у).
2) В одном потоке подключается к серверу. Принимает все координаты и шлет положения в поток javafx.
3) Поток javafx рисует графику(помним что все размеры заранее известны), слушает нажатия кнопок\мыши и шлет на сервер.

В минимальном виде это будет работать.
Т.е. по итогу игровая логика происходит на сервере. Игроки же просто получают координаты друг друга и мяча, в ответ шлют серверу положение своей клюшки.

Так правильно, вы кнопку ни в какой контейнер и не поместили.

Ну так и реализуйте, стягивайте нужный файлик куда нибудь локально, скажем в %temp% и оттуда его отображаете в imageview. Чтобы каждый раз не перекачивать делайте проверку на наличие файла и совпадение размера.
Т.е. есть url картинки, есть место где лежит ваш кэш, смотрите сначала по названию есть или нет файл, затем по размеру файла который хранится в кэше и на сайте, если один и тот же то просто отображаете а если отличается или файла нет то грузите в кэш. В случае отсутствия инета просто тупо берете картинку из кэша а если нет и инета и этой картинки в кэше то отображаете заглушку из ресурсов которые идут с программой вашей.

domanskiy, пытайтесь и осваивайте, только перед этим почитайте книгу, статью о MVC, что это, зачем, как и где применяется, как используется в java и в javafx в частности. Скажу даже по другому, MVC это обобщенный принцип, а вот его реализаций в подходе уйма.
Сам вопрос противоречит вообще всему.

Если утрировать то примерно так образно будет выглядеть один из вариантов MVC в javafx:
К примеру программа которая должна читать\сохранять файл, и выводить содержимое в таблицу на форме.
M (Model) - скажем будет DataModel.class. В нем 3 функции loadData(), saveData() и getData(). Реализует полностью логику работы Как читать\писать файл. Как переварить данные, сложить\умножить\...
V (View) - это непосредственно то как что то будет отображено на форме, т.е. это сам FXML файл или класс описывающий интерфейс, где какая кнопка, как она выглядит. Предоставляет ListView и пару кнопок для обращения к себе. Абсолютно ничего не знает откуда и как берутся данные для отображения(т.е. совсем).
С (Controller) - к примеру DataController.class. Этот класс знает только что предоставил View (опять же просто знает что там есть UI который сам нарисует) и пару кнопок, опять же не знает как они выглядят, где они находятся. Также знает где взять данные (из DataModel) но абсолютно не знает как она их получает. По итогу, тут идет стык Представления и Данных. Просто берет из DataModel методом getData() данные и передает их в View в listView. Берет событие кнопки load и вызывает в DataModel метод loadData(). При этом еще раз, контроллер понятия не имеет, где там кнопка на форме, как добываются данные, ему это до фени.
Как итог каждая часть не зависит от другой. Надо чтобы вместо получения данных из файла они брались из БД или телепатией? Не вопрос, просто переделай DataModel.class , все остальные части программы даже не поймут что что то изменилось. Надо вместо JavaFX отдать данные в виде вэб странички? Пожалуйста меняй View и опять же ничего другого переделывать не надо.

А теперь возвращаемся к началу, бегом читать литературу.

А и еще на за метку, любые длительные работы надо выполнять в фоне и дозаполнять ими форму. Если же данные влияют на отображение то для этого существуют прелоадеры (вот запускаешь ты свою IDE и видишь сначала квадратик с картинкой и прогресбаром и только следом отображается окно программы).

В случае с FXML из конструктора контроллера еще нельзя обращаться к fxml элементам, зато есть метод initialize() который отрабатывает уже после инициализации всего fxml, используйте его.

Ну начнем по порядку.
Java как язык и среда крайне консервативная и любые нововведения как правило воспринимаются в штыки. Плохо это или хорошо вопрос крайне тонкий и в глазах потребителя всегда разный. Со стороны энтерпрайза это просто восхитительно, есть огромный выбор в хороших специалистах, есть огромное время поддержки нужной версии которая обкатана годами и уже почти все известно о всех тонкостях. Со стороны мелких инноваторов и разработчиков развитие идет непостижимо медленно а значит есть отставание от трендов и оно значительное.
Предрекая вопрос что за бред привожу следующий факт по поддержке версий:
J2SE 1.4 выход 2002 год, конец поддержки 2013
J2SE 5.0 выход 2005 год, конец поддержки 2015
J2SE 6 выход 2006 год, конец поддержки 2018
J2SE 7 выход 2011 год, конец поддержки 2022
J2SE 8 выход 2014 год, конец поддержки 2025
J2SE 9-10 вышли в 2017/18 годах, проходные бэты и ключевой момент развития и политики java в котором произошло множество огромных изменений политики. Особенно изменилась лицензия по моему именно где то тут и очень сильно, рекомендую почитать холивары на эту тему.
J2SE 11 вышла в 2018, конец поддержки 2026 год.
Если вдаваться в абстракцию могу предложить следующую иллюстрацию. (еще раз это просто иллюстрация для понимания и попыток провести параллель с чем то иным).
Предположим что майкрософт идет тем же трендом что и оракл как и весь мир большого бизнеса. На выходе имеем следующее:
-основная ОС на которую ориентируются большие игроки рынка софта и игр является winXP.
-миром до сих пор правят однопоточные но многогерцовые процессоры которые правда уперлись в 5Ггц. Зачем менять то что и так прекрасно в простоте. Просто удешевляем и "ухолодняем" производство. Да и вообще у основной массы все еще камни уровня 1 поток и 3.4 ГГц. Ориентируемся на это.
-миром видеокарт до сих пор правят dx9c без новомодных нововведений, без cuda\opencl, без dxr, без подходом низкоуровнего апи вида вулкана\dx12. Зачем менять то что итак прекрасно работает и давно известно с каждой стороны. Видеокарты выходят давно упер в возможности выходя из ревизии к ревизии с фиксами багов и удешевлением производства. Да и в общем то зачем что то новое, т.к. у основной массы еще графика уровня встройки.
- всякие nvme\m2\pcie4 все от лукавого, зачем это если у массового пользователя все еще sata2 hdd который едва ли выдает что то среднее.
-мониторы у всех в среднем 800х600 пикслей, а зачем больше то?
+ На выходе с этими ориентировками имеем универсальный продукт(софт\игру) которая будет работать вообще у всех в среднем отлично, все возможные баги были известны и пофикшены еще 10 лет назад. Новомодное все от лукавого и только у единиц энтузиастов, а значит не берем их в расчет или берем пытаясь выдать это как фичу.

Теперь немного пояснений к вышесказанному, разработчики, большие естественно, получают колоссальное преимущество т.к. их много, есть выбор, они знают и понимают что и как происходит, у них есть богатый стаж как делать можно и как нельзя, а главное почему. Изучение языка и стандарта версии крайне подробное, тонны книг, курсов, обсуждений. С другой стороны никаких новшеств нет, все как на уровне 10 лет назад так и осталось, хочешь круглую кнопочку так забудь или только медленными костылями за которые сразу объявят костылеписателем рукожопом.

Надеюсь параллель понятна. Теперь к вопросу.
Сейчас, я напомню 2019 год, скажу честно видел не один десяток энтерпрайз решений которые до сих пор все еще развиваются на jre7. Есть те кто скрипя зубами переходит на jre8, но пока, опять же лично мои наблюдения, это вот прям скрипя зубами о асфальт, очень нехотя, очень не хочется.

Касательно компиляции в ехе, нет такого понятия в мире java. Опять же дам пояснения.
Java это про изоляцию хостового железа от софта. Т.е. у Вас есть софт которому глубоко фиолетово сколько там ядер, какая ФС, какая ОС и т.д. .JRE это "виртуальная машина" и в этом ее прелесть, "есть один бинарник который работает везде и которому пофиг где он был запущен" главное чтобы была JRE.
И вот тут возникает прикол, самих реализаций JRE множество, есть платные, есть бесплатные, есть условно платные, у каждой своя лицензия и ограничения Каждая решает свои проблемы.

Так вот, предложу очередную аналогию. Предположим Вы создали автомобиль который ездит на "топливе", все замечатально, в вашем определении топливо "все что горит". На практике же на бензине он как бы работает и так как ожидалось. На дизельном как то вообще не очень. На авиационном, ну работает правда не долго. На водородном вот даже не заводится.

Ну ладно хватит вокруг да около, а то развел демагогию. Лично мое мнение и практика, JAVA приложения вообще нельзя, еще раз НЕЛЬЗЯ собирать в ехе или любую другую самодостаточную сборку.
Банально но потому что Вы врезаете пользователя или СЕБЯ в лицензию или ограничения. Ну например вы собрали ехе который по сути включает jre под win10 и скинули мне, а у меня winXP и нифига не работает, а если работает то с совершенно непонятными логами багов. Вот скинули бы jar файл с пометкой что собран под jre7 то проблем бы не было от слова совсем.

А, и к слову, даже встроенный механизм java по сборке так называемых native сборок не решает проблем разношерстности от слова совсем.

PS. надеюсь не зря написал такое эссе и донес свою мысль. Мысль основывается на моих наблюдениях и опыте.

Много тонкостей. Покажите код где именно загружается изображение и как его передаете в ImageView.
Немного тонкостей, каждый способ ниже даст абсолютно разный результат итоговый по качеству:
1)через конструктор Image(java.lang.String url, double requestedWidth, double requestedHeight, boolean reserveRatio, boolean smooth).
2) Методы setFitWidth()\height у ImageView дадут другой результат.
3) Методы setScaleX()\Y у ImageView дадут тоже другой результат.

Дальше, не ручаюсь но, раньше был баг со сглаживанием, точнее его отсутсвием а еще точнее игнорированием в конструкторе Image, возможно это уже пофиксили а возможно и нет. Лично я выкручивался способами 2 и 3, после того как подгружал его через Image уже вытягивая.

PS если ImageView используете только для отображения картинки то лучше сразу откажитесь в сторону css. Влепите pane на нужное место и в него уже динамически лепите css стиль. Это гораздо легче по ресурсам и дает гораздо больше вариантов всяких рюшечек.

%тролейбус_из_буханки_хлеба.жпг%
Javafx совсем для другого сделана, в т.ч. и реализация 3д в ней. В играх все максимально предсказуемо реализовано, простой цикл в котором все крайне последовательно происходит и отрезано абсолютно все что ненужно.
Конкретно тут надо сначала читать как работает цикл в javafx, что за чем следует и т.д.. Дальше в любом случае javafx тащит за собой тонны абсолютно ненужного кода. Кроме того для правильной реализации всего и вся нужно учитывать дельту времени от которой пляшет вообще все в реалтайме. В общем я даже не знаю как это описать. Ну попробуйте представить что вы забиваете гвозди микроскопом, а теперь что гвоздей надо забить тысяч пять. Можно? можно! Удобно? не совсем. Практично? абсолютно нет.

В общем если хотите в реалтайм игры то смотрите на jmonkey engine, libgdx, если по хардкорнее то JOGL, LWJGL.

PS, как вариант попробуйте рисовать в canvas, но опять же львиную долю проблем это не решит никак. Если прям игра и javafx то что то более размеренное но не реалтайм где вот такие проблемы будет видно.

Теперь задайте себе пару вопросов:
1) При чем тут javafx и каким боком она связано с сутью вопроса?
2) У вас есть рабочее приложение которое работает с БД, Логично что приложение ваше и вы его писали, следовательно гдето в таком явном месте есть самая обычная строка подключения к БД в которой написано "localhost". Так вот это не намекает на место с которого стоило начать и попробовать вписать тут ссылку удаленного сервера?
3) Вы хотя бы думали о абсурдности и глупости своего вопроса?

А что тут непонятно, даже коментарии все объясняют. А в первоисточнике так вообще с рисуночками все есть.