Java | Фишки и трюки

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

Полезный пост для тех, кто хочет стать Java-разработчиком с нуля или вырасти до уровня Middle+ без вложений 👇🏻 Школа IT Mentor открывает набор на курс «Java-разработчик» - оплата обучения происходит только после трудоустройства. Первая зарплата - от 150 000 рублей. 💸 На курсе тебя ждут: - Java Core, JDBC, HIBERNATE, SPRING(Core, MVC, Security), SPRING BOOT, GIT, - погружение в процесс разработки на реальном проекте - от системы управления до тестирования, - подготовка к собеседованиям и гарантия трудоустройства: не нашел работу - ничего не должен, - помощь в составлении резюме и карьерные консультации, - сообщество студентов вашего уровня, которое не сгорает даже после прохождения обучения. Курс подойдет тем, кто хочет войти в IT, cтудентам ВУЗов и выпускникам образовательных программ, которые затрудняются найти работу. Junior- и Middle- программистам, которые хотят выйти на новый уровень дохода. Разработчикам из других ниш, которые хотят перейти в backend-разработку. 🔥 👉🏻 Переходи на сайт, чтобы оставить заявку на обучение и подробнее ознакомиться с программой. Количество мест ограничено. Рассматриваются кандидаты от 18 до 50 лет. »Перейти на сайт Реклама. ИП Тюльников ИНН 526223159257.

⌨️ Class Loaders В Java, Class Loader (загрузчик классов) является частью Java Runtime Environment (JRE), которая ответственна за загрузку классов в виртуальную машину Java (JVM) во время выполнения программы. Class Loader осуществляет поиск и загрузку классов в память JVM по их именам. Class Loader имеет иерархическую структуру и состоит из трех основных типов: 1️⃣ Bootstrap Class Loader (Загрузчик базовых классов): Этот загрузчик является частью ядра JVM и отвечает за загрузку системных классов Java, таких как java.lang.Object, java.lang.String и другие. Он является самым высоким в иерархии загрузчиком. 2️⃣ Extension Class Loader (Загрузчик расширений): Этот загрузчик наследуется от Bootstrap Class Loader и загружает классы из расширенной библиотеки Java (расположенной в директории jre/lib/ext). 3️⃣ Application Class Loader (Загрузчик приложений): Также известный как System Class Loader, этот загрузчик загружает классы из путей, указанных в переменной окружения CLASSPATH. Он также загружает классы из текущего рабочего каталога приложения. Когда Java-программа запускается, система Class Loader следует иерархии загрузки классов. Если класс не найден в одном загрузчике, система пытается найти его в следующем в иерархии. Процесс загрузки класса включает в себя три этапа: 1️⃣ Загрузка (Loading): Загрузчик находит байт-код класса и загружает его в память. 2️⃣ Связывание (Linking): На этом этапе проводится проверка байт-кода, выделение памяти для статических полей, и разрешение ссылок на другие классы. 3️⃣ Инициализация (Initialization): Выполняются статические блоки кода и инициализируются статические переменные. Класс ClassLoader предоставляет методы для динамической загрузки классов во время выполнения. Работа с Class Loader'ами может быть полезной, например, при реализации механизмов плагинов и динамической загрузки классов.

Не трогайте, это на Новый год! Профессия «Java-разработчик» 🎁 🎊 Получите скидку до 30 000 р. и кэшбек на карту до 25 000 р. при успешном прохождении обучения! Освойте язык крупного бизнеса и финансовых технологий и научитесь разрабатывать веб-приложения на фреймворке Spring. Уже во время обучения вы вступите в программу «Карьерный трек», чтобы найти свою первую работу в IT.  Вы научитесь подбирать правильные структуры для хранения и обработки данных, познакомитесь с автоматизированным тестированием и напишите свои первые модульные тесты. 📌 Пройдите 5 бесплатных уроков и поймите, подходит ли вам профессия! Реклама. АНПОО "ХЕКСЛЕТ КОЛЛЕДЖ". ИНН 7839056670.

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

⌨️ Управление доступом к членам класса Модификаторы уровня доступа определяют, могут ли другие классы использовать определенное поле или вызывать определенный метод. Существует 4 уровня доступа: private Указывает, что доступ к члену возможен только в его собственном классе. package-private (нет явного модификатора) Указывает, что доступ к члену только внутри своего собственного пакета. protected Указывает, что доступ к члену возможен только внутри его собственного пакета (как в случае с package-private) и, кроме того, для подкласса его класса в другом пакете. public Указывает, что доступ к члену возможен отовсюду.

Как быстро собрать такую форму оплаты? Легко! Фронтенд гайд, это канал для верстальщиков, в котором публикуют: ✓ Готовый код ✓ Макеты для верстки ✓ Тесты на знание кода Ускорь работу над своим проектом!

Тысячи слитых книг по разработке и дизайну! Книжки айтишки - хранилище лучших книг, здесь вы скачаете всё абсолютно бесплатно! HTML - (121 книга); CSS - (98 книг); Python - (301 книга); Java - (137 книг); JavaScript - (302 книги); Figma - (76 книг); Unity - (56 книг); И много других Успей подписаться, ссылка действует 24ч!

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) — модули верхних уровней не должны зависеть от модулей нижних уровней, а оба типа модулей должны зависеть от абстракций; сами абстракции не должны зависеть от деталей, а вот детали должны зависеть от абстракций.

⚡ Когда мне говорят, что Java слишком простой язык, я показываю канал Java Learning Здесь я научился: ▪️ Разрабатывать высоконагруженные серверные приложения ▪️ Управлять сложными базами данных ▪️ Организовывать эффективную многопоточную обработку данных ▪️ Проходить технические собеседования в ведущие IT-компании Самый необычный канал про Java, подписывайся – @Java_per_month

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

Java Developer — мастхев для любого джависта За ручку проведём тебя к первому офферу, расскажем о сложных вещах простыми словами и научим смеяться с айтишных мемов. ➡️ Подписывайся и прокачивай свои навыки

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

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

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

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

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.

Параметр fetch в аннотациях @ManyToOne, @ManyToMany, @OneToOne, @OneToMany определяет как будет загружаться связанная сущность: вместе с загрузкой родительской сущности или в момент обращения к аннотированному полю. Этот параметр может принимать два значения: EAGER: при загрузке родительской сущности будет загружена и дочерняя сущность. Это один SQL-запрос с выбором родительской сущности к которой присоединяется (LEFT JOIN) дочерняя. LAZY: при загрузке родительской сущности, дочерняя сущность загружена не будет. Вместо нее будет создан proxy-объект. С помощью этого proxy-объекта Hibernate будет отслеживать обращение к этой дочерней сущности и при первом обращении загрузит ее в память. Какой же использовать? Если сущности не большие и связей не много, а проект не сильно нагруженный, то можно использовать EAGER, иначе нагрузка на БД может быть большой и в результате приложение может стать задумчивым. Но LAZY не панацея, например мы можем выбрать список сущностей и что то с ними делать в цикле обращаясь к полю LAZY, в результате мы получим дополнительный запрос на каждый элемент списка, что так же увеличит нагрузку на БД. В данном случае нужно выбрать это поле как EAGER. Получается что у нас могут быть разные варианты использования выбранной сущности. Как же быть? Первое что приходит в голову это сделать набор сущностей которые смотрят на одну и ту же таблицу, но в которых параметр fetch задан по разному, в зависимости от использования сущности. Но такой способ выглядит криво: дублирование кода, проблемы с передачей сущности в методы (классы сущностей все разные). В следующих постах поговорим о том как этого избежать. Не переключайте канал.