ScriptEngineManager factory = new ScriptEngineManager();
ScriptEngine engine = factory.getEngineByName("nashorn");
engine.eval("print('Hello, World!');");var MyClass = Java.type("some.package.MyClass");
var my = new MyClass();
my.printMsg("Hello!");И да, я не программист, и в этом деле только начинающий, поэтому пока работаю по урокам и беру с пользой информацию.сильно рад что не копипастер, лучше подучи алгоритмы а любой ЯП всего лишь их реализует. Просто сейчас очень часто, по крайне мере у меня, ситуация когда кто то спрашивает "у меня такойто грандиозный проект но вот тут проблема, помогите или пните в туториал, помогите?!" а следом видишь что "Some resource not found" или "divide by zero exception" и становится просто страшно и обидно.
game_objects[] obj;
game_cycle{
...
if(obj[i].on_screen(cam_coords))
obj[i].tick();
else if(!obj[i].isDied()) obj[i].resetPos();
...
}2. После подключению к одному из серверов - просим ввести пароль через команду (или как в дальнейшем планировалось - в специальном окне).
Но тут возникает вопрос можно ли легче сделать. По идеи можно передавать логин и пароль в аргументы запускатора, но тут возможно будут проблемы со стороны сервера, т.к. серверу необходимо передать этот пароль из клиента и произвести авторизацию. Так что скорей всего данная идея не закатит.
Вижу я, что вы много в этом разбираетесьпомимо своего проекта делал еще к 3м лаунчеры с нуля в т.ч. пара публичных которые до сих пор гдето на рубакките тухнут.
Насчет разворачивания тут есть варианты со своими плюсами и минусами
1) Решение в лоб. Составляем примитивный скрипт вида apt-get install proga1 proga2 ... progaN . Дальше на свежеустановленной системе достаточно будет запустить полученное и все перечисленное будет установлено. Останется толькко подмонтировать облако и все. Минусов много, если дистр сильно обновился или изменились репозитории то какой то программы или ее версии может просто не оказаться. Плюсы что делается просто и вообще для какого угодно дистра с какой угодно системой пакетов.
2) Юзать дистрибутивы с пакетными менеджерами использующими "оверлейные, контейнерные" типы софта. К примеру дистрибутивы Puppy и все производные используют pet\pfs\sfs контейнеры. По сути это ФС начиная от корня( \ ) программа разложена по нужным ей местам. Ось видит такой пакет и накладывает поверх основной ФС тем самым получается что она как бы установлена. При этом любые изменения файлов или добавления сохраняются отдельно, т.е. не трогают саму программу. Опять много плюсов и минусов, к примеру крайне удобно контролировать версии софта, очень удобно их переносить на другие инсталяции(тупым копированием pet\pfs\sfs), всегда легко и бесследно можно удалить или обновить софт, легко собрать свой пакет, легко собрать целый свой дистрибутив. Из минусов то что такой бутерброт оверлейных ФС накладывает свои нагрузки к примеру на оперативку, т.е. 100 таких программ это 100 фс наложенных друг на друга и каждая кушает скажем по 1 мегабайту озу.
3) snap или flatpack или appimage, тут если проще говоря развитие идей п2, точнее даже аналогичные подходы. Тут можешь почитать что к чему.
С одной стороны лично я бы предпочел тот же puppy с его подходом, просто потому что мне нравится такой подход, крайне удобно все контролировать и отсутсвует зависимость от устаревания репозиториев. С другой стороны скорее всего если понадобится что то обновить то придется делать это ручками или искать кто уже собрал пакет. На 2х ноутбуках у меня и используется puppy самосборный просто потому что удобно, софт стоит нужных версий и обновления не требуются, ноуты не очень мощные. С другой стороны на работе на рабочем ноуте сейчас стоит манжаро просто потому что нужны самые свежие версии софта, на серверах centos и opensuse.