mayton2019

Имеет смысл расти вширь. Тоесть изучать технологии виртуализации Docker/Kubernetes, сети, протоколы и особенности ОС linux (на которой я предполагаю все что ты пишешь будет работать). Имеет смысл понимать как работает тонкая диагностика linux чтобы решать performance issues. Я убежден что большинству Java-разрабов этого знания не хватает.

Kotlin изучать я считаю не имеет смысла. JSP процессы улучшают Java язык таким образом что Kotlin не сильно будет отличаться в будущем.

Scala - язык с очень высоким порогом входа и вряд-ли для микро-сервисов тебе что-то новое принесет. Это - скорее к BigData или к специфичным фреймворкам (Play). Ну ... или нужно быть очень сильным фанатом ФП чтобы разрабатывать на Scala то что вобщем-то и так прекрасно разрабатывается на Java.

Задача решается довольно просто. Это булевы операции над углами и окружностями.
В данной задаче сложностью является следующие вопросы
1) Как ЗАДАНА окружность?
2) Как задан угол?
3) Как задан квадрант? Или прямая. Или полу-плоскость.
После того как мы узнаем это - сможем легко описать цветовую область. Например голубой сегмент окружности описывается как:
- пересечение окружности с полу-плоскостью
или
- пересечение двух полу-плоскостей

Если это Брюс Эккель - то я читал ее в 2013 году. Тогда хорошо зашла. Но я не знаю насколько книга актуальна для современной Java. После того как сообщество перешло на такой бешеный темп создания релизов - то книги стали устаревать быстрее.

В задаче есть 2 смысла. Первое это собственно алгоритмизация. Показать преподавателю как вы умеете декомпозировать задачу на примитивные шаги. И показать оптимизации. StringBuilder к примеру. И второй смысл - просто решить задачу например используя JavaStreams. Это будет красивее. Компактнее. Но показать алгоритмизацию будет неудобно.

Что за вертикальная палочка? Зачем она?

ALTER TABLE sl.lesson {
    DROP CONSTRAINT lesson_timetable_id_fkey |
    DROP COLUMN timetable_id
}

А это что?

liquibase.exception.ValidationFailedException: Validation Failed:

Изменял change-sets грязными руками? Этого нельзя делать. То что установлено в репо - маркируется контрольной суммой и нельзя фиксить задним числом. Создаёшь новый changeset который исправляет.

Вот например CPU вырос в два раза, а чем при этом занимается наше Java-приложение, какие запросы отрабатывает, непонятно.

Так не бывает. Если вы разрабатываете этот софт - то вы соотв. знаете какие changes заходили в последнем релизе.

Если вы прям вообще-вообще невкурсе где у вас нагрузка или bottleneck - то это плохо, друзья. Вы не знаете свой код. И почему случилось так что вы раньше этого не знали - непонятно. Вобщем главный совет - будьте familiar to your code. И вам не понадобиться бегать и в день релиза искать профилировщики.

+1 к тому что написал Владимир. Все верно.

А так?

<p>${message}</p>

@tailrec
def getDrinksWithStep(g : Int, step : Int, i : Int = 1, r : Int = 0) : Int = 
  if (i <= g) getDrinksWithStep(g, step, i + step, r + i) else r

Консюмер вычитывает сообщение, передает его на обработку и если происходит ошибка , то кафка консьюмер откатывает и оставляет незакомиченным.

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

Программирование Андроид весьма специфично. Там JVM не такая.
Поэтому я тоже задам вопрос - под какую Java автор хочет разрабатывать.

У современных IDE количество фич исчислятеся тысячами а если ставить плагины то еще на порядки. И вообще спор на тему IDE он не совсем технический а скорее - спор вкусов. Кому арбузы нравятся а кому дыни. Без конкретной аргументации ибо невозможно дать точное определение вкусам.

Но если кодить конкртено под Андроид систему то надо смотреть в первую очередь ту IDE которую рекомендует производитель.

А как выглядит слово Ромич в hex-редакторе? Исходник я имею в виду.

Вопрос звучит так. Где находится класс ApplicationListener.class ?

Его надо подключить к проекту. Ищи его.

Не очень понятно какая решается задача. Если это школьная лабораторная на тему изучения Exceptions - то нормально.

Но обычно на исключения строятся такие кейсы которые неудобно ловить проверкой условия. Например ошибки I/O. И логика обработки этих ошибок обычно глобальна. Например целая процедура завершается когда нет доступа к сети. И безразлично где конкретно процедура упала. Нет сети - сразу на выход.

И тут надо не 2 попытки делать а цикл do-while:

do {
   input = askForInput();
} while(input < 0);

Кроме того sc.nextInt() бросает 3 вида исключений которые ты как-то не заметил. Их тоже надо отработать.

Поскольку ты тегнул вопрос "JAVA" то имеет смысл просто начать изучение сразу по книгам Брюса Эккеля и Хостмана.
Вот в разрезе того как они описывают ООП - тебе будет достаточно. Еще посмотри на книгу Шаблонов проектирования (от Банды четырех) и Рефакторинг с шаблонами от Джоша Кериевски.

Читать чистую ООП - теорию я тебе не советую. Там нет того что тебе понадобиться.

У Java из коробки нет проблем с поддержкой национальных кодовых страниц. Все строки - поддерживают диапазон Unicode. Проблема может быть у Visual Studio Code и у ваших исходников.