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

Как вы думаете, что общего у следующих вопросов: — Как подписаться на события GC и когда эти события приходят? — Сколько у вас в приложении сборщиков мусора по умолчанию? — Как инструментировать своё java-приложение и самому написать javaagent?

Для чего программисту нужны паттерны проектирования? Ответ, на первый взгляд, очевиден. Для того, чтобы проектировать. И это правда. Но я сейчас предложу менее очевидный вариант ответа, который, на мой взгляд, даже более важен, чем разработка хорошей архитектуры. Знание паттернов требуется программистам для общения. Продемонстрируем это на простом примере.

Этот пост для тех, кто устал писать запросы в JDBC template и хочет мощи, которая есть в Spring Data JPA-репозиториях, но не может/не готов использовать JPA. А также для тех, кто устал разрабатывать сущности с JPA/Hibernate и хочет более душевного и близкого «к железу» SQL. Как ни странно, но для решения этих противоречивых с первого взгляда вопросов есть один способ — Spring Data JDBC.

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

С появлением Spring Boot появилась масса возможностей для тестирования различных слоёв. Итак, у нас есть приложение c backend и UI. UI использует backend, а backend содержит следующий код:

Вы же знаете, что jar-файл это zip-архив? То есть, его можно unzip -d target my.jar распаковать и достать все class-файлы. А каждый class-файл это bytecode, который легко-легко можно декомпилировать и получить весь ваш проект с именами всех ваших классов и их переменных и методов. И кодом методов. То есть, совсем всё можно из jar-файла получить. Если, конечно, он не обфусцирован.

Принято считать, что многопоточность (multithreading) одна из самых сложных тем в программировании. В первой заметке мы постарались ответить на вопрос, почему так много разработчиков делают ошибки при создании приложений, которые работают более чем в одном потоке. В этой заметке разберём типы ошибок многопоточного доступа к данным: race condition и memory consistency errors. Но, перед тем как обсуждать ошибки доступа, давайте сначала разберёмся, что такое многопоточный доступ к данным.

Принято считать, что многопоточность (multithreading) — одна из самых сложных тем в программировании. Давайте разберёмся, почему так много разработчиков делают ошибки при создании приложений, которые работают более чем в одном потоке.

На первый взгляд может показаться, что приложение без функции public static void main(String[] args){...} бессмысленно. Ведь его нельзя запустить. Точнее его нельзя запустить через вызов java -jar name.jar.

И тем не менее, многие Java-разработчики регулярно пишут такие приложения. И запаковывают их не в jar-файлы, а в war-файлы. Давайте сегодня с этими war-файлами и разберёмся.