Зачем нужен загрузчик классов?

В Java используется динамическая загрузка классов. Ее выполняют загрузчики – наследники абстрактного класса ClassLoader. Кроме того, они же загружают и файлы-ресурсы.

Загрузка класса (точнее любого ссылочного типа) и всех его предков происходит автоматически перед его инициализацией. При этом используется тот лоадер, который загрузил текущий код. Таким образом, загрузка всех, даже встроенных классов – ленивая.

Вручную класс можно загрузить из конкретного загрузчика, передав аргументом его метода loadClass бинарное имя класса.

В URLClassLoader и стандартных загрузчиках JVM источником класса служит .class-файл. Другие загрузчики в своей реализации используют и другие источники: это может быть сетевой ресурс, или класс может генерироваться в рантайме. К примеру загрузчик из javassist специализируется на создании классов на лету.

В результате загрузки создается экземпляр класса Class. В отличие от обычных объектов, такие экземпляры хранятся не в куче, а в permgen/metaspace. Class может быть выгружен, когда загрузивший его ClassLoader стал мусором.

Java Guru🤓 #java

🚀 Стартуй в IT с Code Father: Оплата после трудоустройства !Освой Java-разработку без предоплаты — начни учиться сейчас, а плати только после трудоустройства.
Что вас ждёт?✅ 4 этапа обучения:
1.👨‍💻 Обучение с менторами-разработчиками:Твои задачи будут проверять менторы — действующие разработчики уровня middle и выше. Они не только оценивают правильность решений, но и дают рекомендации по улучшению кода, указывают на слабые места и помогают развивать профессиональные навыки.
2. 🧩Постепенное усложнение задач:Вы начнете с модуля java core где будете осваивать базовые основы языка.Тебя ждёт большое количество задач, но их сложность растёт плавно. Благодаря этому ты сможешь справиться со всеми заданиями и не потеряешь интерес к обучению.
3.🌟 Актуальные технологии и реальные проекты:Задачи и учебные материалы постоянно обновляются. Модуль pet-проектов основан на реальных задачах из разработки в крупнейших банках. После его завершения ты будешь готов к работе с самыми востребованными технологиями на рынке.
4.🏅 Уникальная подготовка к собеседованиям:Главная цель обучения — твоё трудоустройство. Наша система подготовки включает:
    📊Анализ 200+ собеседований, пройденных senior-разработчиками за последние 2 года.
    🧠Разбор самых частых теоретических вопросов, задач по live-кодингу и code review.
    📝Готовые ответы и стратегии прохождения интервью.
    🖋Помощь в составлении резюме.
✅ Стек технологий:Java Core, Spring (Boot, MVC), Hibernate, Git, Maven, SQL, Kafka, Docker 
✅ Поддержка менторовОбратная связь по коду, помощь с проектом, разбор ошибок, подготовка к собеседованиям.
Почему Code Father?
🔥Оплата после трудоустройства:
Оплата 17% от зарплаты только после трудоустройства .Нет скрытых платежей: Учёба начинается без вложений.Сообщество: Закрытый чат с кураторами и выпускниками.
🔥 Только актуальные технологии:Работаем с тем, что требуют компании: Spring Boot, Kafka, Docker, Spring Data JPA — без воды и устаревших инструментов.💼
🔥 Менторство 1:1:Каждый студент получает индивидуальную обратную связь от практикующих разработчиков.После такой подготовки ты станешь уверенным кандидатом и сможешь пройти собеседование в любую компанию. 🌍
👉Как начать? Узнать подробности || Наш Telegram
До встречи на курсе!

#реклама
О рекламодателе
erid: 2W5zFJmroeY

Чем отличается перегрузка от переопределения?

Полиморфизм – соль ООП. Перегрузка (overload) и переопределение (override) – два инструмента достижения полиморфного поведения в Java.

Перегрузкой реализуется ad-hoc-полиморфизм. Это значит «один и тот же» метод может работать с разными параметрами. С технической точки зрения это просто два разных метода, сигнатуры которых имеют одинаковое название, но разный набор параметров. Важно помнить, что для перегрузки не достаточно различий только модификаторов, возвращаемых типов и списков исключений.

Ad-hoc – не совсем настоящий полиморфизм, так как при нём используется раннее, или статическое связывание (early binding, static dispatch). Это значит, что для выбора конкретного варианта метода используется информация о типе переменной, а не объекта в ней лежащего, и происходит это еще при компиляции.

Если в классе объявлены два перегруженных метода, а аргумент в вызове подходит под оба, случится ошибка компиляции. В примере выше компилятор не может выбрать между вариантами метода println с параметром char[] и со String, так как null может быть и тем и другим.

Переопределение (override) дает полиморфизм подтипов. Это реализация/подмена метода нефинального родительского класса или интерфейса. С помощью этого механизма достигается поведение, когда экземпляр хранится под типом родителя, но реализация методов используется специфичная для этого конкретного подтипа. Пример:
List<String> list = new LinkedList<>();
list.add(“foo“);


Здесь метод add вызывается общий для всех списков, но добавлен будет именно элемент связного списка.

Выбор конкретного метода происходит в последний момент, в процессе работы программы, в зависимости от типа объекта. Это называется позднее или динамическое связывание методов (late binding, dynamic dispatch).

Переопределение имеет непосредственное отношение к принципу подстановки Лисков (LSP): в хорошем объектно-ориентированном коде для вызывающего кода переопределенный метод не должен быть отличим от оригинального.

Переопределенный метод принято снабжать аннотацией @Override. Ее отсутствие допускается, но компиляция не перегружающего метода с такой аннотацией приведет к ошибке.

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

Статические методы нельзя переопределить, можно только перегрузить.

Java Guru🤓 #java

Когда Class.getClassLoader вернет null?

Этот вопрос поднимает две темы. Первая – класс Class в целом. Экземпляры Class<T> представляют runtime-описание типов. В терминах этого описания перечисления считаются классами, аннотации – интерфейсами. В основном приходится взаимодействовать с метаклассами при работе с рефлексией или загрузчиками.

По большей части эти экземпляры класса Class состоят из содержимого .class-файла. Создаются они только внутри класслоадера. Особенности их хранения в памяти обсуждаются в предыдущем посте.

Вторая тема для разговора здесь – особенности класса Class для примитивов, массивов и void. Для получения таких экземпляров используется тот же синтаксис, что и для обычных классов: void.class, int.class, float[][].class. Конструкция foo.class – это не обращение к члену, а литерал класса.

Для void типом-параметром T выступает специальный неинстанциируемый тип java.lang.Void. Тип-параметр примитива – соответствующий класс-враппер. Хотя для самого класса-враппера будет отдельный экземпляр Class. То есть int.class != Integer.class.

Метод getClassLoader обычного класса или интерфейса вернет загрузчик, который его загрузил. null может вернуться для загруженного bootstrap-класслоадером типа. Для массива возвращается то же, что для типа его элементов. Для примитивов и void результатом всегда будет null.

Java Guru🤓 #java

Как узнать, является ли A подтипом B?

В Java доступны три способа проверки совместимости типов. Функционально они ничем не отличаются, применяются для разных наборов аргументов. В порядке убывания быстродействия:

instanceof – бинарный оператор, самый быстрый и самый используемый. Если есть экземпляр A и можно указать B явно, выбирать надо его. Если A (точнее тип хранящей экземпляр A переменной) и B не из одной цепочки наследования – экземпляр точно не может быть подтипом B и компиляция упадет с ошибкой inconvertible types.

Class::isInstance – метод принимает параметром объект типа A. Его стоит выбрать, когда экземпляр A в наличии, но B – неизвестный на этапе компиляции тип. То есть, для переменных A a и Class bClass, можем проверить bClass.isInstance(a).

Class::isAssignableFrom – принимает Class<A>. Единственное, что остается, если экземпляра A нет. bClass.isAssignableFrom(aClass).

Есть еще четвертый способ – имея экземпляр типа A привести его к B. Если типы были несовместимы, приведение выбросит ClassCastException. Это во всех смыслах плохой способ, построению логики программы на исключениях нет оправдания. Подробная аргументация описана в Effective Java Item 57.

Java Guru🤓 #java

Что вернётся, если отправить GET-запрос на /test?

В чём отличия интерфейса от абстрактного класса?

Главное отличие – это семантика. Интерфейсы появились еще до Java, как важная концепция ООП. Смысл интерфейса – некое поведение, описание свойства. Причем если придерживаться принципа сегрегации интерфейсов, это описание единственного аспекта поведения.

Класс, даже абстрактный – это комбинация всех свойств и их реализаций, которыми определяются сущности некоторой категории (собственно, класса).

Отсюда вытекает естественность и необходимость множественного наследования для интерфейсов. Опыт таких языков как C++ показал, что множественное наследование классов не нужно и проблемно (см. проблема ромбовидного наследования). По факту же обычно нужно всего лишь переиспользование кода, что не относится к ООП и реализуется в некоторых языках «интерфейсами с независимым состоянием» – примесями.
В Java интерфейс в отличие от абстрактного класса не может иметь состояния. Реализация поведения же допустима только в двух случаях: для статических методов, и default для обычных. Статические методы являются частью всего класса, а не экземпляров. Дефолтная реализация, как говорилось ранее, добавлена только как хак для сохранения совместимости.

В интерфейсах, как публичных описаниях, не имеют смысла и запрещены непубличные члены. Отсюда синтаксическое отличие: модификатор public, как и abstract для методов или static для полей, можно не писать. Запрещены и модификаторы, несовместимые с abstract: final, synchronized и прочие.

На уровне скомпилированного байткода тоже есть небольшие различия: интерфейс помечается флагом ACC_INTERFACE а для класса генерируется конструктор по-умолчанию.

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

Java Guru🤓 #java

Что будет результатом запуска кода?

Что если оба реализуемых интерфейса объявляют один и тот же метод?

Если объявление полностью одинаково – нет никакой проблемы, класс-реализация должен просто определить этот метод.

Когда у обоих интерфейсов объявлены методы с одинаковой сигнатурой, но разными возвращаемыми типами – всё зависит от того, какие именно эти типы.

Переопределение метода (override) еще с Java 5 ковариантно относительно возвращаемого типа. То есть, в наследнике тип результата метода может быть наследником: super метод возвращает Number, @Override метод возвращает Integer.

Если типы не связаны отношением наследования, например String и Long – такой класс невозможно реализовать.

Для примитивов никакой ковариантности возвращаемого типа нет. Даже если типы совместимы относительно присваивания: int→long, int→Integer. В любом из таких случаев будет ошибка о несовместимости возвращаемых типов, для примитивов они должны совпадать в точности.

Если различие в части throws, методы объявлены выбрасывающими разные типы исключений. Правила здесь те же, что для возвращаемых типов – работает ковариантность. Отличие лишь в том, что исключений примитивных типов не бывает, а даже для не являющихся родителем и наследником исключений всегда есть вариант, удовлетворяющий обоим – отсутствие выбрасываемых исключений вообще.

Java Guru🤓 #java

Как изменить значение приватного финального поля?

Стоит сразу сказать, это очень плохая практика. Такое изменение грубо нарушает принципы сокрытия данных, и потенциально ломает инвариантность состояния объекта.

Для этого трюка необходимо прибегнуть к использованию Reflection API.

Сначала получим дескриптор поля – экземпляр класса Field. У объекта метакласса Class<X> интересующего нас класса вызовем метод getDeclaredField(). Просто getField() не сработает, потому что он работает только с публичными полями. Параметром передается строка с именем поля.

Полученного экземпляра Field уже достаточно для доступа к изменяемым приватным полям. Перед обращением требуется сделать его доступным, вызвав setAccessible(true).

Сам доступ осуществляется методами get*() и set*(). Так как Field представляет дескриптор поля класса, без привязки к конкретному экземпляру класса, экземпляр передается параметром в методы доступа. Для статического поля передается null.

Чтобы побороть неизменяемость финального поля, нужно снять его модификатор final. Все модификаторы поля хранятся в поле modifiers дескриптора. То есть, нужно также с помощью рефлекшена сделать доступным и обновить поле уже объекта Field.

Поле modifiers хранит модификаторы в виде битовой маски. Для изменения придется прибегнуть к битовым операторам.

Полный код установки значения 42 в поле myField объекта myObject выглядит так:

Field field = myObject.class.getDeclaredField( "myField" );
field.setAccessible( true );
Field modifiersField = Field.class.getDeclaredField( "modifiers" );
modifiersField.setAccessible( true );
modifiersField.setInt( field, field.getModifiers() & ~Modifier.FINAL );
field.setInt(myObject, 42);

Java Guru🤓 #java

Приведите примеры операций со стримами

Самые часто используемые

Java Guru🤓 #java

При вызове метода executeTask() три раза, сколько экземпляров TaskProcessor будет создано?