MaxLich

Если по простому,а судя по вопросу это именно так, то как то так.
Для начала вникаем что такое авторизация и регистрация и из чего состоит. Получится что есть клиент и сервер.
Клиент для регистрации должен сказать желаемый логин и пароль. Для авторизации можно чуть усложнить и работать по 2м схемам, Первый когда клиент скажет серверу логин и пароль. Во втором логин и токен.
*Токен тут получается после авторизации, его генерирует сервер и сообщает клиенту. Используется для минимальной защиты потому как на клиенте можно не хранить пароль а хранить только логин и токен.
Сервер в свою очередь ждет от клиентов логин и пароль, после получения которых проверяет в своем хранилище(бд например) и отвечает клиенту сообщением состояния(ок, логин занят,ошибка, пароль простой и т.д.). Дальше он ждет от этого клиента авторизацию по одному из двух способов которая может быть по логину и паролю, тут сервер ответит также сообщением(сгенерирует токен, ошибка пароль\логин не верный). 2й вариант что ожидается логин и токен , ответ будет (ок, ошибка токен не верный).

Общаться клиент и сервер естественно будет по сети а вот как решать уже вам. Это может быть:
1) Голые сокеты, проще для понимания т.к. никаких библиотек уже не будет и собственно весь протокол будет ваш.
2) Использовать какую нибудь rest подобную систему. К примеру тупо взяв сервер с php и сделать нечто похожее(понимаете смысл надеюсь) на register.php и auth.php. Соответсвенно запросы с клиента уже будут идти тупо по http
3) Взять че покруче и на порядок сложнее, к примеру netty. Круче сокетов но сложнее в пару сотен раз хотя сделать придется по сути тоже что и на сокетах.
4) Какой нибудь сетевой движек, к примеру kryonet. Тут конечно уже ближе к играм но почему нет? Придется читать доки и следовать принципам библиотеки, ниразу не узнав что такое сериализации и зачем она нужна.

Для практики потом можно усложнять схему, к примеру чтобы сервер уже не просто смотрел на логин и токен клиента но и еще на его ip чтобы он совпадал. Можно обернуть все это шифрованием, реализовываться будет по разному в зависимости от того каким путем пойдете. Реализовать еще и временный токен этой сессии или же тупо еще одним параметром от клиента типа что за устройство, тогда клиент под одним логином сможет авторизоваться одновременно с нескольких устройств и никто никому мешать не будет.

В более серьезных проектах примерна такая же схема как я описал выше но доработанная в пару тысяч раз толще на любой чих и случай жизни.

Конкретно для javafx я тут вообще в этой теме ничего не вижу да и вообще быть ничего не может т.к. это всеголишь библиотека для отрисовки интерфейса программы с коллекциями предназначенными помочь это сделать еще удобнее. Аналогично ей существуют еще ее предшественники awt и swing которые посложнее но темнеменее работают и легче по ресурсам.

А где они должны занимать место по вашему? Все потоки создаваемые executor'ом рождаются, работаю и умирают "внутри" пула. Если вам надо выполнять больше потоков, либо увеличивайте лимит, либо используйте CachedThreadPool. Чтобы поток занимался чем-нибудь другим в процессе ожидания ресурса, вам придётся самому переписать ваши Runnable\Callabe-таски, чтобы они проверяли состояние ресурса и в случае его блокировки делали что-нибудь другое.

Вы преувеличивайте знание конкретного языка программирования и сложность его изучения.
ЯП - это базовые знания программиста.
Вы же не приходит в голосу задать вопрос - а какую клавиатуру изучать: слимовую или полновысотную, 80 клавишную или 100 клавишную.

Учите оба.
Котлин как бы удобнее и пр.
Но на Яве больше примеров, библиотек.

Даже если вы будете писать на Котлине, как минимум читать Яву вам все равно придется.

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

Так вот, фигушки вы ее найдете, потому что ленивых программистов в ИТ не любит никто по совершенно прагматическим причинам - если вам лень сейчас изучать Ассемблер и архитектуру ЭВМ, то вы также лениво будете относиться и к чему-нибудь еще, что вам в вашей работе покажется "не очень нужным". Это порождает баги, костыли, говнокод и срыв сроков, за что по голове получает вся команда.

Ничего личного против вас не имею - просто оно вот так почти всегда работает. Если с вами этого не случится - чудесно. Но вероятность, что отличный узкий специалист по Java выйдет из человека, который считает смежные предметы ненужными - стремится к нулю. Не потому что они вам понадобятся непосредственно (хотя я не очень представляю, как можно заниматься оптимизацией кода без понимания принципов работы ЭВМ), а из-за модели поведения.

ЭВМ - один из инструментов программиста. Если Вы плохо знаете или не знаете совсем свой рабочий инструмент, то высококвалифицированным специалистом Вам не стать.
Так что, да, все эти знания нужны.

JNIEXPORT jstring JNICALL Java_Test_saySomething(JNIEnv *env, jobject obj, jstring jStr) {
    // Получаем указатель на массив символов String
    const char *cStr = (*env)->GetStringUTFChars(env, jStr, NULL);
    if (cStr == NULL) return NULL;

    // Выводим полученное
    printf("%s\n", cStr);
    // Освобождаем выделенную под строку область памяти
    (*env)->ReleaseStringUTFChars(env, jStr, cStr);
 
    // Получаем новый массив символов от пользователя
    char buf[128];
    scanf("%s", buf);
 
    // Преобразовываем массив символов в String
    return (*env)->NewStringUTF(env, buf);
}

Только учтите, что Java хранит строки в кодировке Modified UTF-8, а в C вы работаете с ANSI-кодировками. Поэтому, если понадобиться работать с кириллицей, то придётся озаботиться перекодированием.

Всё это можно свести к понятию - подпрограмма. Бывает, читаешь книгу, там автор пишет о своём куске кода как о методе, потом его начинает называть функцией.