JPA Entity Graph - это механизм, предоставляемый JPA, который позволяет явно указывать, какие атрибуты сущности должны быть загружены или проигнорированы во время выполнения запросов к базе данных. Это может быть полезно для управления жадной загрузкой (eager loading) и ленивой загрузкой (lazy loading) связанных сущностей.

JPA Entity Graph предоставляет более гибкий и декларативный способ управления загрузкой связанных данных по сравнению с использованием параметра fetch в аннотациях связи с другими сущностями. Он также позволяет избежать проблем с N+1 запросами, когда множество связанных сущностей загружается в отдельных запросах.

В нашем примере мы создали именованный граф сущности (person-with-address), который включает атрибуты name из сущности Person и также включает атрибут address с дополнительным подграфом (address-subgraph), который включает атрибут city из сущности Address.

Далее мы используем getEntityGraph для получения ссылки на ранее созданный граф сущности, а затем передаем его в запрос find с использованием соответствующих свойств. Это позволяет загрузить только указанные атрибуты, что может быть полезно для оптимизации производительности и избежания избыточной загрузки данных.

Entity Graph можно так же создавать динамически используя метод createEntityGraph вместо getEntityGraph.

Чем отличаются эти два способа определения массива?

int[] array = new int[]{1,2,3}
int[] array = {1,2,3}

Ответ: ничем не отличается, эти два определения идентичны на уровне байт-кода.

Проблема N+1 (N+1 Issue) в JPA (Java Persistence API) возникает, когда при получении списка сущностей с их связанными сущностями (например, при использовании отношения OneToMany или ManyToOne), для каждой основной сущности выполняется дополнительный запрос для загрузки связанной сущности. Это приводит к выполнению N+1 запросов к базе данных, где N - количество основных сущностей.

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

Использование управления загрузкой, такого как JOIN FETCH или использование JPA Entity Graphs, позволяет предотвратить проблему N+1 и повысить производительность при работе с базой данных через JPA.

PrintStream является классом, предназначенным для удобного вывода различных типов данных в поток вывода. Он является подклассом OutputStream и предоставляет методы для вывода данных различных примитивных типов, строк и объектов в удобном для чтения текстовом формате.

В этом примере PrintStream используется для вывода данных как в консоль, так и в файл. Он обеспечивает удобный способ форматирования и вывода данных различных типов. Класс PrintStream также автоматически преобразует различные типы данных в их текстовое представление перед выводом.

SOLID — принципы объектно‑ориентированного программирования

SOLID — это аббревиатура пяти основных принципов проектирования в объектно‑ориентированном программировании — Single responsibility, Open-closed, Liskov substitution, Interface segregation и Dependency inversion.

В переводе на русский: принципы единственной ответственности, открытости / закрытости, подстановки Барбары Лисков, разделения интерфейса и инверсии зависимостей.

Аббревиатура SOLID была предложена Робертом Мартином, автором нескольких книг, широко известным в сообществе разработчиков. Следование принципам позволяет строить на базе ООП масштабируемые и сопровождаемые программные продукты с понятной бизнес‑логикой. Код, который написан с соблюдением принципов SOLID, проще понимать, поддерживать, расширять или изменять его функциональность.

Принцип единственной обязанности / ответственности (single responsibility principle / SRP) обозначает, что каждый объект должен иметь одну обязанность и эта обязанность должна быть полностью инкапсулирована в класс. Все его сервисы должны быть направлены исключительно на обеспечение этой обязанности.

Принцип открытости / закрытости (open-closed principle / OCP) декларирует, что программные сущности (классы, модули, функции и т. п.) должны быть открыты для расширения, но закрыты для изменения. Это означает, что эти сущности могут менять свое поведение без изменения их исходного кода.

Принцип подстановки Барбары Лисков (Liskov substitution principle / LSP) в формулировке Роберта Мартина: «функции, которые используют базовый тип, должны иметь возможность использовать подтипы базового типа не зная об этом».

Принцип разделения интерфейса (interface segregation principle / ISP) в формулировке Роберта Мартина: «клиенты не должны зависеть от методов, которые они не используют». Принцип разделения интерфейсов говорит о том, что слишком «толстые» интерфейсы необходимо разделять на более маленькие и специфические, чтобы клиенты маленьких интерфейсов знали только о методах, которые необходимы им в работе. В итоге, при изменении метода интерфейса не должны меняться клиенты, которые этот метод не используют.

Принцип инверсии зависимостей (dependency inversion principle / DIP) — модули верхних уровней не должны зависеть от модулей нижних уровней, а оба типа модулей должны зависеть от абстракций; сами абстракции не должны зависеть от деталей, а вот детали должны зависеть от абстракций.

JIT-компилятор

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

JIT-компилятор является ключевым элементом виртуальной машины Java (JVM). Он компилирует байт-код часто вызываемых методов в машинный код во время выполнения. Следовательно, он отвечает за оптимизацию программ Java.

JVM автоматически отслеживает, какие методы выполняются. Как только метод становится пригодным для JIT-компиляции, его планируется компилировать в машинный код. Этот метод так же известен как горячий метод. Эта компиляция в машинный код происходит в отдельном потоке JVM. В результате он не прерывает выполнение текущей программы. После компиляции в машинный код, метод работает быстрее.

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

Метод dropWhile был введен в интерфейсе Stream в JDK 9. Этот метод позволяет пропускать элементы в начале потока данных, пока они удовлетворяют определенному условию, и возвращает новый поток, начиная с первого элемента, который не соответствует условию.

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

Класс Properties

В Java класс Properties представляет собой таблицу хэш-значений ключ-значение. Он является частью пакета java.util, и обычно используется для работы с конфигурационными файлами, настройками приложений и другими данными в формате ключ-значение.

Некоторые методы класса Properties:

setProperty(String key, String value) - добавление или изменение значения ключа.

getProperty(String key) - получение значения по ключу.

load(InputStream in) - загрузка свойств из InputStream.

store(OutputStream out, String comments) - сохранение свойств в OutputStream.

defaults(Properties defaults) - устанавливает значения по умолчанию, которые будут использоваться при поиске значения для ключа, если оно не найдено в текущих свойствах.

Пример файла Properties:

version=1.0
name=TestApp

Цепочка методов (Method chaining) — это общий синтаксис для нескольких вызовов методов в объектно-ориентированных языках программирования. Каждый метод возвращает объект, что позволяет объединить вызовы в один оператор без необходимости использования переменных для хранения промежуточных результатов.

Пример для String:

text = text
        .trim()
        .replace("?", "")
        .replace(" ", "-")
        .toLowerCase();

Для того чтобы сделать такую штуку в своем классе, нужно что бы каждый метод возвращал из метода ссылку на текущий объект (this).

Ромб

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

   *   
  ***  
 ***** 
*******
 ***** 
  ***  
   *   

Алгоритм: поместим центр координат в центр ромба, в результате для каждой из 4х плоскостей мы увидим закономерность: там где сумма x и y (без знака) меньше или равна половине размерности ромба, там стоит *, иначе пробел.

HttpClient представляет собой класс, введенный в Java 11, который предоставляет более современный и гибкий способ для выполнения HTTP-запросов и обработки HTTP-ответов. Он заменяет устаревший HttpURLConnection и предоставляет более удобный интерфейс для работы с сетевыми операциями.

HttpClient также поддерживает асинхронные операции, позволяя выполнять запросы асинхронно с использованием CompletableFuture.

Контракт метода hashCode

Для реализации хэш-функции в спецификации языка определены следующие правила:

1️⃣ вызов метода hashCode один и более раз над одним и тем же объектом должен возвращать одно и то же хэш-значение, при условии что поля объекта, участвующие в вычислении значения, не изменялись.

2️⃣ вызов метода hashCode над двумя объектами должен всегда возвращать одно и то же число, если эти объекты равны (вызов метода equals для этих объектов возвращает true).

3️⃣ вызов метода hashCode над двумя неравными между собой объектами должен возвращать разные хэш-значения. Хотя это требование и не является обязательным, следует учитывать, что его выполнение положительно повлияет на производительность работы хэш-таблиц.