Орхан Гасанлы

Потому что у вас для каждого элемента из tab прогоняется вся логика приложения.
Должно быть как-то так:

int dice;
        int[] tab = new int[3];
        boolean gameOver = false;


        System.out.println("\n\t -= SNAIL RUN =- ");

        while (!gameOver) {
            System.out.println("\n");
            for (int i = 0; i < tab.length; i++) {

                // Generating random numbers
                dice = ThreadLocalRandom.current().nextInt(1, 6 + 1);
                tab[i] += dice;

                if (tab[i] > 50) {
                    gameOver = true;
                }

                System.out.print("Dice" + (i + 1) + "=" + dice + " | ");
            }

            System.out.println("\n");
            for (int i = 0; i < tab.length; i++) {
                System.out.print(tab[i] + " | ");
            }

            System.out.println("\n________________________________________________________________");
        }

        System.out.println("\nGAME OVER");

Перенести объявление переменной счётчика в тело внешнего цикла.

Нашел, в `pom.xml` были несоответствия в версиях подключаемых библиотек. У меня было:

<dependency> <!-- For annotations -->
                <groupId>org.springframework</groupId>
                <artifactId>spring-context</artifactId>
                <version>5.3.12</version>
</dependency>

А надо:

<dependency> <!-- For annotations -->
                <groupId>org.springframework</groupId>
                <artifactId>spring-context</artifactId>
                <version>5.3.10</version>
</dependency>

Парень,
Востребованы не сами языки, а специалисты, которые на этих языках умеют работать.

И учить нужно будет настолько много, что ты должен не на медиану смотреть, а на себя - что тебе ближе. Потому что в процессе обучения, ты еще не раз будешь лезть на стену и кричать зачем я в это гребаное ИТ полез.

Лично у тебя должна душа лежать к технологии, чтобы не забросить ее через месяц, через год, через 5 лет, через 30 лет.

Зачем ты спрашиваешь у рандомов из интернета? Уровень джуниора это тонны знаний, и это очень очень минимальный объем, который позволяет джуну с джава переключится на джуна C# довольно быстро, и вдобавок получив взгляд со стороны. Поэтому пока ты лазишь по hh, конкуренты уже пишут свой первый проект.

Бакеты хранят внутри себя ноды в форме односвязного списка, но как только количество нод достигает 8 (константа TREEIFY_THRESHOLD = 8) и количество бакетов достигает 64 (константа MIN_TREEIFY_CAPACITY = 64), произойдет переход к древовидной структуре в этом бакете. Но возможен и обратный переход из древовидной структуры в односвязный список. Это происходит, когда количество нод в этом бакете сокращается до 6 (константа UNTREEIFY_THRESHOLD = 6), например при увеличении ёмкости хэш-таблицы (количеста бакетов). В этот момент происходит перехеширование всех элементов. Но есть ещё один интересный момент. Допустим вы переопределили хэшкод, чтобы тот возвращал одно и то же значение. И как не трудно догадаться все элементы будут попадать в один бакет. Изначально 16 бакетов, если добавить 9 нод и все они попадут в один бакет, то мапа расширится до 32, если не произойдет распределение, то при добавлении 10 ноды - расширится до 64. И вот если снова не произошло распределения и 11 ноду добавить в тот же бакет, то этот бакет перестроится в дерево.

Не нормально. Во-первых, глупо использовать язык со статической типизацией и не пользоваться её преимуществами. Во-вторых, "взять у объекта параметр с проверкой на наличие" видимо обозначает использование рефлексии, что медленно и небезопасно.

Это не случайное значение из массива. Это массив всех строк в modelOfPersonalComputersStringArray.

Если нужна одна случайная строка, то надо потом взять

Random random = new Random();
String s = tempArray[ random(tempArray.length) ];

Попробуй исключить обновленные модули из спринговых зависимостей.
Примерно так:

<dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-data-jpa</artifactId>
            <exclusions>
                <exclusion>
                    <groupId>org.apache.tomcat</groupId>
                    <artifactId>tomcat-jdbc</artifactId>
                </exclusion>
                <exclusion>
                    <groupId>org.hibernate</groupId>
                    <artifactId>hibernate-core</artifactId>
                </exclusion>
                <exclusion>
                    <groupId>org.hibernate</groupId>
                    <artifactId>hibernate-entitymanager</artifactId>
                </exclusion>
            </exclusions>
        </dependency>

Правильнее конечно же через геттеры-сеттреры, так как изначально предполагалось, что есть только одна точка контроля - геттер/сеттер.
С другой стороны - все на усмотрение разработчика, можно и напрямую к полю.