mayton2019

Да это ООП код.

Почти все современные среды разработки в дереве проекта (Project=>External libraries) показывают зависимости.
Но успех мероприятия сильно зависит от того как проект создавался. Для maven-сборщика
это точно работает. Для других - надо смотреть.

Обычно DAO не сериализируют. Вот Contact - можно.
И DAO так не делают. Обычно DAO предоставляет доступ к источникам данных. К базе например.
Но он не обязан ничего внутри себя хранить.

А моя программа выдает при n = 5 m = 4 путь: 15432

Код работает как написано. Только ты зря завел переменную current. Без нее можно обойтись.
Получается что ты шагаешь не через единичку а идешь длинными прыжками по модулю 5.
И тебе кажется что идешь назад.

for (int i = 0; i < n; i++) {
            System.out.print(arr[current]);
            current = (current + m) % n;
        }

Я-бы переписал проще.

for (int i = 0; i < n; i++) {
            System.out.print(arr[(i+ m) % n]);
        }

Если они связаны 1:1 то соедини их в одну табличку и все.

UPD: Автор если ты сомневаешся - то лучше не делай. На все технические вопросы тут ответят.
Но риски - это дело твоё. Похлопывать тебя по плечу или давать санкции на авантюры - никто не будет.
Если ты отвественный за БД и уверен в себе - то иди и делай.

У меня - сходу замечание по твоему стилю. Зачем ты переменную card переписываешь? Это сбивает с толку.

List<Card> cards = .....

cards = entityManager

Нельзя одну переменную брать в двух ипостасях. Сэкономил в одном - проиграл в читаемости.

Второе я думаю что эта задача прекрасно решается одним SQL-запросом. Так было в продуктовых системах с 2000х годов когда еще не было этих ваших ORM/Hibernate. И все нормально работало. Поэтому делай все одним запросом. Не думай о накладных расходах в базе. Мой опыт показывает что база - лучше справляется когда выбирает все данные сразу одним курсором (запросом).

А игры с Lazy-Eager которые придумали в ORM решают проблемый самого ORM и ApplicationServer а базе они вобщем-то не нужны.

Если ты собрался глубоко заняться оптимизацией - посмотри лекцию Алименкова особенно в части трассировки Hibernate запросов. Собери цифры. Сколько карточек на 1 акк в среднем? 1 или 10 или 1000? Сколько транзакций на акк? Это все влияет на смыслы оптимизаций.

Обычно звание джуниора ты получаешь после прохождения собеседования. Тебя должны градуировать специалисты которые уровнем выше. Вот. А чтоб быть готовым к собеседованию я советую купить платный курс Java-junior. Благо курсов щас много. И я не рекламирую курсы, не имею отношения к ним вообще. Но плата - будет хорошим мотиватором чтоб учится.

С бесплатными курсами - почти ничего не выйдет. Их обычно все бросают.

По Multithreading

"Что выведет следующий фрагмент кода"

Это - самый плохой класс задач на мультипоточку. Я видел много таких. Большинство из них основаны на Race Conditions и бывало и такое что негативный эффект не воспроизводится хотя и ожидается в задаче. А не воспроизводится по тесяче причин. По другой операционке или по другой версии JDK/JRE. Вобщем что
выведет код нужно выкинуть и заменить его на какой-то модульный тест да и еще и под нагрузкой. И беря
во внимание комплексность самого вопроса я-бы не стал такое выводить например в собеседования. Так
можно и мидла макнуть головой в сортир. Попробуйте распознать в коде например задачу обедающих
философов. Я готов спорить на коньяк что если вы никогда не слыхали - то не распознаете подвох.

Где и как подтянуть теорию Multithreading(М). Ответ - нигде. Самый лучший вариант - начать писать много кода
с мультипоточкой и наблюдать. Очень многие эффекты книги не объясняют. И 99% новичек нигде не прочитает
про разницу между использованием synchronized и atomic.

Вобщем берите код с нагрузкой и наблюдайте.

Тебе проще всего разбить своей проект на 2 проекта. Первое это нужные jar-библиотеки log4j, postgres jdbc, jackson и сделать просто упаковку их в один артифакт. И второе - это основной код который зависит от этих библиотек.

Связь между проектами можно организовать через maven repository.

Тебе нужна функция цветовой дистанции между двумя цветами. Типа

double getDistance(int rgb1, int rgb2) {
    ....
}

Формула будет похожа на взвешенную сумму цвета как ты писал выше. Только в цветах
нужны будут разности r1 - r2 e.t.c. И взять декартово расстояние.

Она будет возрващать от 0 до некоторого максимального вещественного. Если 0 - то цвета идентичны.

Задаешь порог чувствительности например 5% и если цвета rgb1 и rgb2 близки - то соотв. считаешь
что совпадение было. Сравнивать по знаку == цвета нельзя в фотографиях. Там очень редко
бывает численное совпадение. Практически - никогда не бывает.

обязательно ли именовать пакеты в Java именно так "com.javastart.NAME"

Их можно именовать как угодно. Просто если делать интеграцию твоего приложения с другими
библиотеками то конфликтов имен можно избежать если всегда добавлять домен + твое имя.
Это практически всегда уникально.

Автор попробуй поменяй версию com.qiwi.billpayments.sdk на более новую или более старую.

Можно брать последнюю с суффиксом LongTermSupport (LTS) но с условием что фреймворк тоже
поддерживает эту версию. Например я тоже люблю топчик (JDK17) но вынужден кататься на
более старой модели жигулей JDK11 только потому что нужные Spark/Hadoop иногда хотят
именно старую версию.

Для разработок в банковской среде очень многие enterprise приложения до сих пор (!)
сидят на JDK-8 и очень мало вероятно что они когда-то переведут language на что-то более
старшее. Поэтому весьма анекдотична ситуация когда вас собеседуют и спрашивают про
модное-молодежное а когда приходите на рабочее место - с ужасом узнаете какой
огромный парк легаси сред и языков вас будет сопровождать. Печаль-печаль.

Вообще проблемы установки конкретного дистрибутива ощущают с болью в основном Windows-пользователи.
Для Linux эта проблема не так заметна. Можешь поставить 3/11/17 LTS в разные фолдеры и переключать их просто меняя PATH/CLASSPATH для текущего сеанса консоли.

Для приложений на базе контейнеризации (docker/kuber) - вообще такой проблемы не существует.
Каждое приложение выбирает себе конкетную сборку JRE/JDK в конфигурации образа.

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

Делать его бином тоже как-то не хочется

Не совсем понятно почему не хочется. Экономишь память? Или время иниализации бина?

У тебя проблема вовсе не в Spring. Здесь если убрать Spring за скобки - то ты также будешь ломать
голову над тем как разложить твои данные по методам.

Попробуй реши эту задачу вообще без Spring. Будет простое ООП-решение. Вот затащи его потом
в Spring и вопрос сам собой решится.

Это значит, мне надо сделать 1000 репозиториев, в каждом Х методов (получение по ID, получение по значению поля, одного объекта, коллекции...). И ещё 1000*Х методов в контроллерах....

Зачем такой ужас. Делай только те репозитарии которые реально задействованы в бизнес-задачах.
Из личного опыта могу сказать что если приложение спроектировано по умному - то ему не нужно
выделять каждую таблицу в Entity.