Что такое ковариантность и контравариантность?
Формально, ковариантность/контравариантность типов – это сохранение/обращение порядка наследования для производных типов. Проще говоря, когда у ковариантных сущностей типами-параметрами являются родитель и наследник, они сами становятся как бы родителем и наследником. Контравариантные наоборот, становятся наследником и родителем.
Легче всего осознать эти понятия на примерах:
🟢 Ковариантность: List<Integer> можно присвоить в переменную типа List<? extends Number> (как будто он наследник List<Number>).
🟢 Контравариантность: в качестве параметра метода List<Number>#sort типа Comparator<? super Number> может быть передан Comparator<Object> (как будто он родитель Comparator<Number>)
Отношение типов «можно присвоить» – не совсем наследование, такие типы называются совместимыми (отношение «is a»).
Существует еще одно связанное понятие – инвариантность. Инвариантность – это отсутствие свойств ковариантности и контрвариантности. Дженерики без вайлдкардов инвариантны: List<Number> нельзя положить ни в переменную типа List<Double>, ни в List<Object>.
Массивы ковариантны: в переменную Object[] можно присвоить значение типа String[].
Переопределение методов начиная с Java 5 ковариантно относительно типа результата и типов исключений.
Java Guru🤓 #java
Формально, ковариантность/контравариантность типов – это сохранение/обращение порядка наследования для производных типов. Проще говоря, когда у ковариантных сущностей типами-параметрами являются родитель и наследник, они сами становятся как бы родителем и наследником. Контравариантные наоборот, становятся наследником и родителем.
Легче всего осознать эти понятия на примерах:
Отношение типов «можно присвоить» – не совсем наследование, такие типы называются совместимыми (отношение «is a»).
Существует еще одно связанное понятие – инвариантность. Инвариантность – это отсутствие свойств ковариантности и контрвариантности. Дженерики без вайлдкардов инвариантны: List<Number> нельзя положить ни в переменную типа List<Double>, ни в List<Object>.
Массивы ковариантны: в переменную Object[] можно присвоить значение типа String[].
Переопределение методов начиная с Java 5 ковариантно относительно типа результата и типов исключений.
Java Guru🤓 #java
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥8👍4❤2
Что такое bridge method?
В Java отсутствует ковариантность переопределенных методов по параметрам – их типы должны совпадать с типами параметров метода в родительском классе. Когда дженерик параметр конкретизируется в наследнике, методы с аргументами этого дженерик типа больше не совпадают в байткоде – в наследнике тип конкретный, а в родителе стертый до верхней границы.
Проблема решается простым и безопасным кастом. Компилятор генерирует новый метод, который совпадает по сигнатуре с родительским. В его теле параметр кастуется и вызов делегируется в пользовательский метод. Это и называется bridge методом.
Bridge method можно увидеть с помощью рефлекшна. Его имя совпадает с оригинальным методом, но параметр имеет тип, в который сотрется дженерик родителя. Этот метод будет помечен флагом synthetic, что значит, что он написан не программистом а компилятором.
Попытка написать такой же метод вручную приведет к ошибке компиляции.
Java Guru🤓 #java
В Java отсутствует ковариантность переопределенных методов по параметрам – их типы должны совпадать с типами параметров метода в родительском классе. Когда дженерик параметр конкретизируется в наследнике, методы с аргументами этого дженерик типа больше не совпадают в байткоде – в наследнике тип конкретный, а в родителе стертый до верхней границы.
Проблема решается простым и безопасным кастом. Компилятор генерирует новый метод, который совпадает по сигнатуре с родительским. В его теле параметр кастуется и вызов делегируется в пользовательский метод. Это и называется bridge методом.
Bridge method можно увидеть с помощью рефлекшна. Его имя совпадает с оригинальным методом, но параметр имеет тип, в который сотрется дженерик родителя. Этот метод будет помечен флагом synthetic, что значит, что он написан не программистом а компилятором.
Попытка написать такой же метод вручную приведет к ошибке компиляции.
Java Guru🤓 #java
🔥13👍5❤3
Что такое heap pollution?
Как было сказано ранее, массивы в Java ковариантны. А значит, можно обратиться к объекту типа String[] через переменную типа Object[], и положить туда например Integer. Такой код скомпилируется, но в момент записи произойдет ArrayStoreException.
Дженерики защищены инвариантностью. Если попытаться положить List<Object> в List<String>, эта же по сути ошибка произойдет уже на этапе компиляции.
Heap pollution – ситуация, когда эта защита не срабатывает, и переменная параметризованного типа хранит в себе объект, параметризованный другим типом. Простейший пример:
Документация гарантирует, что при компиляции всего кода целиком, heap pollution не может возникнуть без варнинга этапа компиляции.
Heap pollution может произойти в двух случаях: при использовании массивов дженериков и при смешивании параметризованных и raw-типов.
Raw types – это параметризованные типы без указания параметра. Пример с raw types, приводящий к heap pollution, уже был описан выше:
Использовать raw types не надо вообще, причины подробно изложены в главе 26 Effective Java. Если информация о дженериках не нужна, используется символ wildcard (<?>).
Компилятор не даст создать массив параметризованного типа, это приведет к ошибке generic array creation. Картинка выше иллюстрирует, к чему это могло бы привести.
Параметризованный тип varargs-аргумента метода вызывает ту же проблему, т.к. varargs – не что иное как параметр-массив. Вот почему он так же приводит к предупреждению компилятора «possible heap pollution». Если вы уверены что риска нет, с Java 7 это предупреждение заглушается аннотацией @SafeVarargs.
Java Guru🤓 #java
Как было сказано ранее, массивы в Java ковариантны. А значит, можно обратиться к объекту типа String[] через переменную типа Object[], и положить туда например Integer. Такой код скомпилируется, но в момент записи произойдет ArrayStoreException.
Дженерики защищены инвариантностью. Если попытаться положить List<Object> в List<String>, эта же по сути ошибка произойдет уже на этапе компиляции.
Heap pollution – ситуация, когда эта защита не срабатывает, и переменная параметризованного типа хранит в себе объект, параметризованный другим типом. Простейший пример:
List<String> strings = (List) new ArrayList<Integer>();
Документация гарантирует, что при компиляции всего кода целиком, heap pollution не может возникнуть без варнинга этапа компиляции.
Heap pollution может произойти в двух случаях: при использовании массивов дженериков и при смешивании параметризованных и raw-типов.
Raw types – это параметризованные типы без указания параметра. Пример с raw types, приводящий к heap pollution, уже был описан выше:
List<String> strings = (List) new ArrayList<Integer>();
Использовать raw types не надо вообще, причины подробно изложены в главе 26 Effective Java. Если информация о дженериках не нужна, используется символ wildcard (<?>).
Компилятор не даст создать массив параметризованного типа, это приведет к ошибке generic array creation. Картинка выше иллюстрирует, к чему это могло бы привести.
Параметризованный тип varargs-аргумента метода вызывает ту же проблему, т.к. varargs – не что иное как параметр-массив. Вот почему он так же приводит к предупреждению компилятора «possible heap pollution». Если вы уверены что риска нет, с Java 7 это предупреждение заглушается аннотацией @SafeVarargs.
Java Guru🤓 #java
👍8🔥5❤3
Как работает вывод типов?
Для начала разберемся, что такое вывод типов. Type inference – это способность компилятора догадаться, какой тип нужно подставить, и сделать это за вас. На обычном интервью никто не спросит детали алгоритма вывода типов, достаточно будет сказать, что вывод происходит статически, только на основании типов аргументов и ожидаемого типа результата. По сути, вопрос заключается не в «как работает?», а «что это и когда возникает?».
Первое, что многим приходит в голову при фразе «вывод типов» – diamond operator <>. Он появился в Java с версии 7. Его применяют к конструкторам дженерик классов, чтобы отличать требование автоматического вывода типа от raw type.
С Java 9 diamond operator заработал и для анонимных классов.
Для дженерик методов можно указывать параметр явно, но diamond синтаксически недопустим – вывод и так сработает по умолчанию.
В Java 10 для вывода типа локальной переменной добавлено ключевое слово var. Работает это так же, как в большинстве современных языков – ключевое слово ставится вместо типа при объявлении.
Типы выводимых параметров лямбда-выражения также можно не указывать. С Java 11 вместо типа указывается ключевое слово var. Такой синтаксис дает возможность добавлять параметру модификаторы и аннотации.
Java Guru🤓 #java
Для начала разберемся, что такое вывод типов. Type inference – это способность компилятора догадаться, какой тип нужно подставить, и сделать это за вас. На обычном интервью никто не спросит детали алгоритма вывода типов, достаточно будет сказать, что вывод происходит статически, только на основании типов аргументов и ожидаемого типа результата. По сути, вопрос заключается не в «как работает?», а «что это и когда возникает?».
Первое, что многим приходит в голову при фразе «вывод типов» – diamond operator <>. Он появился в Java с версии 7. Его применяют к конструкторам дженерик классов, чтобы отличать требование автоматического вывода типа от raw type.
С Java 9 diamond operator заработал и для анонимных классов.
Для дженерик методов можно указывать параметр явно, но diamond синтаксически недопустим – вывод и так сработает по умолчанию.
В Java 10 для вывода типа локальной переменной добавлено ключевое слово var. Работает это так же, как в большинстве современных языков – ключевое слово ставится вместо типа при объявлении.
Типы выводимых параметров лямбда-выражения также можно не указывать. С Java 11 вместо типа указывается ключевое слово var. Такой синтаксис дает возможность добавлять параметру модификаторы и аннотации.
Java Guru🤓 #java
❤7👍5🔥3
Что означает ArrayStoreException?
Это исключение значит, что программа попыталась сохранить в массив значение неправильного типа. Такая попытка становится возможно из-за ковариантности массивов.
Ковариантность позволяет работать с массивом по типу массива родителей. Например, через приведение к Object[] можно попытаться положить любой объект в любой массив:
Компилятор гарантирует, что когда вы берете элемент из массива, он будет представителем типа элементов самого этого массива. Не важно какого типа переменная его хранит. Именно для обеспечения этой гарантии работает проверка типа времени выполнения, которая и выбрасывает ArrayStoreException.
Ситуация похожа на проблему heap pollution в случае дженериков. Только для этого случая такая проблема возникает реже, потому что работает проверка этапа компиляции:
// Ошибка компиляции – дженерики инвариантны!
List<Object> x = new ArrayList<String>();
Java Guru🤓 #java
Это исключение значит, что программа попыталась сохранить в массив значение неправильного типа. Такая попытка становится возможно из-за ковариантности массивов.
Ковариантность позволяет работать с массивом по типу массива родителей. Например, через приведение к Object[] можно попытаться положить любой объект в любой массив:
Object x[] = new String[3];
x[0] = new Integer(0);
Компилятор гарантирует, что когда вы берете элемент из массива, он будет представителем типа элементов самого этого массива. Не важно какого типа переменная его хранит. Именно для обеспечения этой гарантии работает проверка типа времени выполнения, которая и выбрасывает ArrayStoreException.
Ситуация похожа на проблему heap pollution в случае дженериков. Только для этого случая такая проблема возникает реже, потому что работает проверка этапа компиляции:
// Ошибка компиляции – дженерики инвариантны!
List<Object> x = new ArrayList<String>();
Java Guru🤓 #java
❤7🔥4👍3
Можно ли выбрасывать исключение generic-типа?
Короткий ответ – да. Как в большинстве каверзных вопросов про дженерики, ответ становится очевидным если подумать, во что сотрутся типы-параметры.
Чтобы объявить, что метод выбрасывает исключение обобщенного типа T, этот тип T должен быть объявлен расширяющим Throwable. Именно в Throwable в таком случае сотрется T при компиляции. Также в качестве типа-верхней границы можно использовать любого наследника Throwable:
Java Guru🤓 #java
Короткий ответ – да. Как в большинстве каверзных вопросов про дженерики, ответ становится очевидным если подумать, во что сотрутся типы-параметры.
Чтобы объявить, что метод выбрасывает исключение обобщенного типа T, этот тип T должен быть объявлен расширяющим Throwable. Именно в Throwable в таком случае сотрется T при компиляции. Также в качестве типа-верхней границы можно использовать любого наследника Throwable:
class MyClass<T extends IOException> {
void foo() throws T {
// ...
}
}Java Guru🤓 #java
👍11🔥3
Дженерики в исключениях – что можно, а что нельзя?
1. Можно выбрасывать исключение generic-типа.
Тип-параметр T может использоваться в throws, переменная типа T может использоваться в throw. Недавно мы уже говорили об этом.
2. Нельзя использовать дженерик в catch.
Множественные блоки catch должны идти без повторений, в определенном порядке – от специфичного класса к более базовому. Стирание типов-параметров в связи с этими правилами добавило бы путаницу, не неся особой пользы.
3. Нельзя параметризовать класс-исключение типами.
Если вы попытаетесь скомпилировать конструкцию вида class MyException<T> extends Throwable {}, то увидете ошибку generic class may not extend java.lang.Throwable.
4. Можно реализовывать исключением generic-интерфейс.
Исключение вполне может быть например Comparable или Iterable. Механизм обработки исключений работает на классах, никак не затрагивая интерфейсы.
Java Guru🤓 #java
1. Можно выбрасывать исключение generic-типа.
Тип-параметр T может использоваться в throws, переменная типа T может использоваться в throw. Недавно мы уже говорили об этом.
2. Нельзя использовать дженерик в catch.
Множественные блоки catch должны идти без повторений, в определенном порядке – от специфичного класса к более базовому. Стирание типов-параметров в связи с этими правилами добавило бы путаницу, не неся особой пользы.
3. Нельзя параметризовать класс-исключение типами.
Если вы попытаетесь скомпилировать конструкцию вида class MyException<T> extends Throwable {}, то увидете ошибку generic class may not extend java.lang.Throwable.
4. Можно реализовывать исключением generic-интерфейс.
Исключение вполне может быть например Comparable или Iterable. Механизм обработки исключений работает на классах, никак не затрагивая интерфейсы.
Java Guru🤓 #java
❤11👍3🔥3
Наш чатик с вакансиями и резюме, присоединяйся: https://t.iss.one/job_java
Telegram
Java Job - Вакансии и резюме
Наш канал по Java @javalib
Вакансии Java, также можете скидывать свои резюме!
Купить звёзды: @PremiumBot
Вакансии Java, также можете скидывать свои резюме!
Купить звёзды: @PremiumBot
👍4❤3🔥2
Как ограничить upcasting типа-параметра?
Задача: запретить этому методу принимать параметры разных типов:
То есть, нужно разрешить вызывать pair(Foo, Foo), но запретить pair(Foo, Bar).
Upcasting – приведение к типу-родителю. String → Object, Integer → Number.
Дело в том, что у любых двух классов есть общий предок: как минимум Object. Если вызвать этот метод с параметрами String и Boolean – согласно правилам вычисления типа-границы, параметр T будет стерт в Object.
Использовать super тоже не поможет: для этого нужно знать заранее, какой именно тип будет передаваться.
Фокус в том, что на этапе компиляции это невозможно. Объект любого типа всегда является объектом типа-родителя (отношение is a). Это фундаментальное правило ООП, которое невозможно нарушить. К тому же, подобный метод нарушал бы принцип подстановки Лисков.
Единственная возможность добиться желаемого поведения – с помощью getClass() сравнивать классы объектов в рантайме.
Java Guru🤓 #java
Задача: запретить этому методу принимать параметры разных типов:
<T> void pair(T a, T b) {}
То есть, нужно разрешить вызывать pair(Foo, Foo), но запретить pair(Foo, Bar).
Upcasting – приведение к типу-родителю. String → Object, Integer → Number.
Дело в том, что у любых двух классов есть общий предок: как минимум Object. Если вызвать этот метод с параметрами String и Boolean – согласно правилам вычисления типа-границы, параметр T будет стерт в Object.
Использовать super тоже не поможет: для этого нужно знать заранее, какой именно тип будет передаваться.
Фокус в том, что на этапе компиляции это невозможно. Объект любого типа всегда является объектом типа-родителя (отношение is a). Это фундаментальное правило ООП, которое невозможно нарушить. К тому же, подобный метод нарушал бы принцип подстановки Лисков.
Единственная возможность добиться желаемого поведения – с помощью getClass() сравнивать классы объектов в рантайме.
Java Guru🤓 #java
🔥7❤4👍3🤔1
Как передать runtime информацию о generic-типе?
Когда вы проектируете API-метод библиотеки, иногда логика его реализации может зависеть от указанного клиентом типа. Особенно часто с этой задачей встречаются при разработке парсеров. Например, библиотека Jackson превращает JSON в объект заданного класса. На интервью этот вопрос можно встретить в виде практической задачи.
Первое, что приходит в голову для решения – дженерик-параметр. Такой подход не сработает, потому что тип будет стёрт во время компиляции, а логика будет происходить позже, во время выполнения.
Решение, которое сработает для многих случаев – объявление в методе аргумента типа Class<T>. Пользователь будет передавать в него значение Foo.class или fooInstance.getClass(). Проблемы с ним начинаются, когда становится нужно передать generic-тип. Синтаксис .class не поддерживает дженерики, а .getClass() от экземпляров List<String> и List<Integer> вернет один и тот же объект-описание сырого типа List.
На помощь приходит техника, описанная в предыдущей публикации.
1. Объявляется generic класс-обертка над типом: TypeInformation<T>;. Наш метод будет принимать информацию о типе в виде экземпляра этой обертки.
2. В обертку добавляется конструктор с видимостью protected. Теперь можно создавать объекты только наследников, но не самого этого типа.
3. Пользователь будет передавать экземпляр анонимного наследника обертки: new TypeInformation<List<String>>() {}.
4. Внутри вызов getClass().getGenericSuperclass() вернет ParameterizedType. Это будет описание типа родителя анонима, то есть самой обертки. Из него с помощью getActualTypeArguments() можно достать рантайм-информацию о значении дженерика (о List<String>).
Java Guru🤓 #java
Когда вы проектируете API-метод библиотеки, иногда логика его реализации может зависеть от указанного клиентом типа. Особенно часто с этой задачей встречаются при разработке парсеров. Например, библиотека Jackson превращает JSON в объект заданного класса. На интервью этот вопрос можно встретить в виде практической задачи.
Первое, что приходит в голову для решения – дженерик-параметр. Такой подход не сработает, потому что тип будет стёрт во время компиляции, а логика будет происходить позже, во время выполнения.
Решение, которое сработает для многих случаев – объявление в методе аргумента типа Class<T>. Пользователь будет передавать в него значение Foo.class или fooInstance.getClass(). Проблемы с ним начинаются, когда становится нужно передать generic-тип. Синтаксис .class не поддерживает дженерики, а .getClass() от экземпляров List<String> и List<Integer> вернет один и тот же объект-описание сырого типа List.
На помощь приходит техника, описанная в предыдущей публикации.
1. Объявляется generic класс-обертка над типом: TypeInformation<T>;. Наш метод будет принимать информацию о типе в виде экземпляра этой обертки.
2. В обертку добавляется конструктор с видимостью protected. Теперь можно создавать объекты только наследников, но не самого этого типа.
3. Пользователь будет передавать экземпляр анонимного наследника обертки: new TypeInformation<List<String>>() {}.
4. Внутри вызов getClass().getGenericSuperclass() вернет ParameterizedType. Это будет описание типа родителя анонима, то есть самой обертки. Из него с помощью getActualTypeArguments() можно достать рантайм-информацию о значении дженерика (о List<String>).
Java Guru🤓 #java
👍10🔥7❤2😱2
Зачем нужна Java Serialization? Как сделать класс сериализуемым?
Сериализация – это сохранение типа и состояния объекта в бинарном виде для последующего сохранения/передачи и десериализации. Для сериализации используется интерфейс Serializable (Externalizable), и цель записи/источник чтения ObjectInputStream/ObjectOutputStream (ObjectInput/ObjectOutput).
Класс сериализуем, если:
🟢 Реализует маркерный интерфейс Serializable;
🟢 Все поля сериализуемые или помечены модификатором transient (иначе рантайм выбросит NotSerializableException).
Протокол стандартной сериализации описан в документации.
Сериализационная форма может, и в некоторых случаях для корректной работы должна быть кастомизирована. Правильная форма содержит только логическое представление данных, без деталей о физической реализации.
Для описания полей сериализационной формы в javadoc-документации используется тэг @serial. Для документации генерирующего нестандартную сериализационную форму метода используется @serialData. Эти тэги имеют смысл и для приватных членов, так как эффективно такие члены – часть публичного API.
Нестатические внутренние классы не должны быть сериализуемыми. Статические поля как поля класса а не инстанса несериализуемы.
Java Guru🤓 #java
Сериализация – это сохранение типа и состояния объекта в бинарном виде для последующего сохранения/передачи и десериализации. Для сериализации используется интерфейс Serializable (Externalizable), и цель записи/источник чтения ObjectInputStream/ObjectOutputStream (ObjectInput/ObjectOutput).
Класс сериализуем, если:
Протокол стандартной сериализации описан в документации.
Сериализационная форма может, и в некоторых случаях для корректной работы должна быть кастомизирована. Правильная форма содержит только логическое представление данных, без деталей о физической реализации.
Для описания полей сериализационной формы в javadoc-документации используется тэг @serial. Для документации генерирующего нестандартную сериализационную форму метода используется @serialData. Эти тэги имеют смысл и для приватных членов, так как эффективно такие члены – часть публичного API.
Нестатические внутренние классы не должны быть сериализуемыми. Статические поля как поля класса а не инстанса несериализуемы.
Java Guru🤓 #java
Please open Telegram to view this post
VIEW IN TELEGRAM
❤4🔥4👍2
Зачем используется Serial Version UID? Что если не определить его?
Сериализуемый класс явно или неявно, но всегда имеет serialVersionUID. Это число типа long, которое представляет собой «версию» сериализационной формы класса. Если при сериализации/десериализации значения serialVersionUID не совпадают – будет выброшено InvalidClassException.
Для совпадающих версий работает мощная поддержка эволюции класса – совместимые изменения, такие как добавление или удаление полей, не приводят к InvalidClassException.
Неявное значение вычисляется автоматически в рантайме, и включает в себя информацию о имени типа, списке родителей и полей (с точностью до коллизии). По смыслу это похоже на хэш-сумму класса. Соответственно, при любом изменении класса значение изменится, и поддержка эволюции окажется бесполезной.
Всегда лучше явно указывать любое значение serialVersionUID, и изменять только в тех редких случаях, когда требуется сломать совместимость с предыдущими версиями. Стандартная утилита JDK serialver умеет «угадывать» авто-генерированное значение. Она используется чтобы зафиксировать значение для включения поддержки эволюции созданного ранее класса.
Явное значение устанавливается в переменную static final long serialVersionUID.
Java Guru🤓 #java
Сериализуемый класс явно или неявно, но всегда имеет serialVersionUID. Это число типа long, которое представляет собой «версию» сериализационной формы класса. Если при сериализации/десериализации значения serialVersionUID не совпадают – будет выброшено InvalidClassException.
Для совпадающих версий работает мощная поддержка эволюции класса – совместимые изменения, такие как добавление или удаление полей, не приводят к InvalidClassException.
Неявное значение вычисляется автоматически в рантайме, и включает в себя информацию о имени типа, списке родителей и полей (с точностью до коллизии). По смыслу это похоже на хэш-сумму класса. Соответственно, при любом изменении класса значение изменится, и поддержка эволюции окажется бесполезной.
Всегда лучше явно указывать любое значение serialVersionUID, и изменять только в тех редких случаях, когда требуется сломать совместимость с предыдущими версиями. Стандартная утилита JDK serialver умеет «угадывать» авто-генерированное значение. Она используется чтобы зафиксировать значение для включения поддержки эволюции созданного ранее класса.
Явное значение устанавливается в переменную static final long serialVersionUID.
Java Guru🤓 #java
👍7❤5🔥3
Какими методами настраивается сериализация?
Интерфейс Serializable пуст, но есть ряд методов, добавив которые в сериализуемый класс можно добиться изменения этапов процесса сериализации и десериализации.
readObjectNoData() используется для инициализации класса-родителя, который при сериализации оригинального объекта еще не был родителем. Подробное объяснение.
readObject(ObjectInputStream s) переопределяет стандартную десериализацию.
Методы readObject* похожи на конструктор. Как и конструктор, они подвержены проблеме виртуального вызова. Как и конструктор, они используются для поддержания инвариантов класса (только для случая десериализации).
writeObject(ObjectOutputStream s) используется для записи собственной сериализационной формы.
Object readResolve() может использоваться для реализации какого-либо порождающего паттерна при десериализации. Даже при его использовании объект сначала будет десериализован, поэтому рекомендуется вместе с этим методом помечать все поля transient. Видимость этого метода для наследника определяет, будет ли наследник вызывать его.
Для подмены объекта при записи добавляется симметричный метод Object writeReplace().
Интерфейс Externalizable дает инструмент полной подмены реализации сериализации. Рассмотрим его в следующих постах.
Java Guru🤓 #java
Интерфейс Serializable пуст, но есть ряд методов, добавив которые в сериализуемый класс можно добиться изменения этапов процесса сериализации и десериализации.
readObjectNoData() используется для инициализации класса-родителя, который при сериализации оригинального объекта еще не был родителем. Подробное объяснение.
readObject(ObjectInputStream s) переопределяет стандартную десериализацию.
Методы readObject* похожи на конструктор. Как и конструктор, они подвержены проблеме виртуального вызова. Как и конструктор, они используются для поддержания инвариантов класса (только для случая десериализации).
writeObject(ObjectOutputStream s) используется для записи собственной сериализационной формы.
Object readResolve() может использоваться для реализации какого-либо порождающего паттерна при десериализации. Даже при его использовании объект сначала будет десериализован, поэтому рекомендуется вместе с этим методом помечать все поля transient. Видимость этого метода для наследника определяет, будет ли наследник вызывать его.
Для подмены объекта при записи добавляется симметричный метод Object writeReplace().
Интерфейс Externalizable дает инструмент полной подмены реализации сериализации. Рассмотрим его в следующих постах.
Java Guru🤓 #java
👍4🔥4❤3
Как сериализация работает с наследованием?
Когда Serializable класс имеет цепочку родителей, пока эти родители тоже Serializable, десериализация объекта идет от родителя к наследнику, в обход конструктора. Вместо него вызываются методы readObject (readObjectNoData). Но как только встречается первый предок, не реализующий интерфейс Serializable, инициализация для него возвращается в нормальное русло – вместо readObject вызывается конструктор без аргументов. Если такого конструктора нет, или он объявлен private, исполнение выбросит InvalidClassException.
При сериализации несериализуемые предки просто игнорируются.
Если класс несериализуемый и не предоставляет достаточного доступа к своему логическому состоянию для наследников, правильно реализовать его наследника сериализуемым может быть невозможно.
Популярный вопрос на тему – как когда сериализуешь объект класса-наследника, избежать сериализации его родительской части. Единственный способ добиться этого – кастомизировать сериализационную форму, определив собственную реализацию writeObject(), либо используя интерфейс Externalizable.
Открытость класса для наследования делает неприменимым паттерн serialization proxy (который рассмотрим позднее).
Java Guru🤓 #java
Когда Serializable класс имеет цепочку родителей, пока эти родители тоже Serializable, десериализация объекта идет от родителя к наследнику, в обход конструктора. Вместо него вызываются методы readObject (readObjectNoData). Но как только встречается первый предок, не реализующий интерфейс Serializable, инициализация для него возвращается в нормальное русло – вместо readObject вызывается конструктор без аргументов. Если такого конструктора нет, или он объявлен private, исполнение выбросит InvalidClassException.
При сериализации несериализуемые предки просто игнорируются.
Если класс несериализуемый и не предоставляет достаточного доступа к своему логическому состоянию для наследников, правильно реализовать его наследника сериализуемым может быть невозможно.
Популярный вопрос на тему – как когда сериализуешь объект класса-наследника, избежать сериализации его родительской части. Единственный способ добиться этого – кастомизировать сериализационную форму, определив собственную реализацию writeObject(), либо используя интерфейс Externalizable.
Открытость класса для наследования делает неприменимым паттерн serialization proxy (который рассмотрим позднее).
Java Guru🤓 #java
🔥6❤4👍1
В чем разница между Serializable и Externalizable?
При записи Serializable класса весь контроль над сериализацией достается JVM. С помощью определения специальных методов можно кастомизировать его части. Метод readObject при этом обычно начинается с вызова стандартной части сериализации – ObjectInputStream.defaultReadObject().
Интерфейс Externalizable расширяет Serializable и добавляет методы записи и чтения writeExternal и readExternal. Входной и выходной потоки-аргументы в них представлены более абстрактно чем в специальных методах – интерфейсами ObjectInput и ObjectOutput.
Этот интерфейс позволяет реализовать полностью свой механизм сериализации, стандартно запишется только идентификатор класса. Никакой автоматической работы с классом-родителем также не предусмотрено. Методы readObject и writeObject игнорируются. Ключевое слово transient эффекта на Externalizable не имеет.
Externalizable объект в отличие от Serializable десерализуется не в обход конструктора, так что должен иметь конструктор без аргументов.
Java Guru🤓 #java
При записи Serializable класса весь контроль над сериализацией достается JVM. С помощью определения специальных методов можно кастомизировать его части. Метод readObject при этом обычно начинается с вызова стандартной части сериализации – ObjectInputStream.defaultReadObject().
Интерфейс Externalizable расширяет Serializable и добавляет методы записи и чтения writeExternal и readExternal. Входной и выходной потоки-аргументы в них представлены более абстрактно чем в специальных методах – интерфейсами ObjectInput и ObjectOutput.
Этот интерфейс позволяет реализовать полностью свой механизм сериализации, стандартно запишется только идентификатор класса. Никакой автоматической работы с классом-родителем также не предусмотрено. Методы readObject и writeObject игнорируются. Ключевое слово transient эффекта на Externalizable не имеет.
Externalizable объект в отличие от Serializable десерализуется не в обход конструктора, так что должен иметь конструктор без аргументов.
Java Guru🤓 #java
👍9🔥5❤1
Что такое serialization proxy?
Serialization proxy (посредник сериализации) – это паттерн, который дает простой способ определить собственную сериализационную форму.
1️⃣ Внутри целевого класса объявляется вложенный класс-посредник;
2️⃣ В посреднике объявляются поля, описывающие логическую структуру объекта (собственно, сериализационную форму);
3️⃣ Добавляется конструктор посредника, принимающий экземпляр оригинального класса и инициализирующий все эти поля;
4️⃣ Оба класса помечаются интерфейсом Serializable;
5️⃣ В методе writeReplace оригинального класса инстанциируется и возвращается прокси от this;
6️⃣ Симметричные действия совершаются для чтения – в классе-посреднике реализуется метод readResolve;
7️⃣ В основном классе добавляется readObject, который выбрасывает исключение – это защитит от чтения без прокси.
Пример кода реализации.
Java Guru🤓 #java
Serialization proxy (посредник сериализации) – это паттерн, который дает простой способ определить собственную сериализационную форму.
Пример кода реализации.
Java Guru🤓 #java
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5🔥5❤3🌭1
Назовите проблемы стандартной сериализации
Стандартная сериализация Java при всей своей гибкости обладает рядом проблем.
Дефолтная сериализация фактически добавляет все приватные поля в экспортируемый интерфейс, и ограничивает будущую гибкость реализации. От этого спасает serialization proxy.
Десериализация работает как скрытый конструктор, мимо настоящего, который обеспечивает консистентность состояния. Не сработают даже инициализаторы: поле, определенное как int foo=42, после десериализации будет хранить значение 0.
Сериализация усложняет тестирование – между разными версиями класса должна соблюдаться семантическая совместимость. Эта проблема актуальна для любой реализации персистентного хранения объектов.
Неаккуратно определенная десериализация создает дыры в безопасности. Например, сериализация объекта со слишком глубоким графом объектов-полей может привести к StackOverflowError. Злоумышленник положит вашу систему, подставив такой искусственный объект. Для защиты от различных уязвимостей в Java 8 добавлен механизм сериализационного фильтрования.
Встроенная реализация сериализует все классы одинаково хорошо. Естественно, за универсальность нужно платить, и для каждого частного случая производительность не идеальна и может быть улучшена частной реализацией.
Java Guru🤓 #java
Стандартная сериализация Java при всей своей гибкости обладает рядом проблем.
Дефолтная сериализация фактически добавляет все приватные поля в экспортируемый интерфейс, и ограничивает будущую гибкость реализации. От этого спасает serialization proxy.
Десериализация работает как скрытый конструктор, мимо настоящего, который обеспечивает консистентность состояния. Не сработают даже инициализаторы: поле, определенное как int foo=42, после десериализации будет хранить значение 0.
Сериализация усложняет тестирование – между разными версиями класса должна соблюдаться семантическая совместимость. Эта проблема актуальна для любой реализации персистентного хранения объектов.
Неаккуратно определенная десериализация создает дыры в безопасности. Например, сериализация объекта со слишком глубоким графом объектов-полей может привести к StackOverflowError. Злоумышленник положит вашу систему, подставив такой искусственный объект. Для защиты от различных уязвимостей в Java 8 добавлен механизм сериализационного фильтрования.
Встроенная реализация сериализует все классы одинаково хорошо. Естественно, за универсальность нужно платить, и для каждого частного случая производительность не идеальна и может быть улучшена частной реализацией.
Java Guru🤓 #java
👍5🔥4❤3
Как в Java разобрать JSON?
JSON – на ряду с XML, самый популярный текстовый формат передачи данных. Существует великое множество библиотек для работы с ним, здесь перечислены самые популярные.
🟢 Gson – решение от Google. В простом случае, максимально просто в применении. Популярно в Android.
🟢 org.json – Простое решение для работы с атрибутами из JSON-строки. Не умеет сериализовать из объекта в JSON и обратно.
🟢 Jackson – библиотека, знакомая всем любителям Spring Framework. Широкий простор конфигурации. Может использоваться в Java EE (в составе JAX-RS), хорошо подходит для сложных web-приложений.
🟢 JSONP – один из компонентов Java EE. Есть как стриминговая версия (экономит память при больших документах), так и обычная (когда нужно работать с документом целиком). Можно взять реализацию Glassfish, или любого другого сервера приложений. Решение «от производителя», как часто бывает, не самое популярное.
На разных данных эти решения могут показывать различную производительность, поэтому чтобы выбрать библиотеку исходя из быстродействия, нужно замерять скорость работы на конкретном приложении. Большинство готовых сравнений, которые вы найдете, заангажированы в пользу библиотеки автора этого сравнения.
Java Guru🤓 #java
JSON – на ряду с XML, самый популярный текстовый формат передачи данных. Существует великое множество библиотек для работы с ним, здесь перечислены самые популярные.
На разных данных эти решения могут показывать различную производительность, поэтому чтобы выбрать библиотеку исходя из быстродействия, нужно замерять скорость работы на конкретном приложении. Большинство готовых сравнений, которые вы найдете, заангажированы в пользу библиотеки автора этого сравнения.
Java Guru🤓 #java
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥7❤2👍1
Чем отличается блокирующее чтение от неблокирующего?
В контексте Java речь в этом вопросе идет о блокирующем/неблокирующем чтении из потоков данных.
Классы блокирующего чтения находятся в пакете java.io. Вы наверняка много раз сталкивались с ними, работая с файлами и консольным вводом-выводом (классы Reader, IOException, InputStream). При блокирующем чтении тред останавливается, пока не получит из потока необходимые данные. Для этих самых распространенных случаев использование неблокирующего чтения не несет пользы, потому что сама запись пользователем консоли и жестким диском будет последовательной.
Чтение данных из сетевого подключения – другое дело. Обычно программа обрабатывает данные быстрее, чем работает сеть. Возникают паузы, в которые поток блокирующего чтения стоит в ожидании, не принося пользы. К тому же серверное приложение работает со многими параллельными подключениями.
Блокирующее чтение можно распараллеливать на потоки, читая в пулле. Но делать это нужно вручную, а количество одновременных подключений будет всё ещё ограничено количеством потоков-обработчиков, потоки буду всё ещё останавливаться без дела.
Для случаев, когда в вашем приложении ожидается большое количество подключений, был добавлен пакет стандартной библиотеки java.nio. С помощью NIO один тред может обслуживать несколько сетевых соединений одновременно, и переключаться между ними не теряя времени на ожидание данных.
IO использует потоки. данные приходят последовательно, и сами нигде не сохраняются. Если вы не обеспечили буферизацию вручную, нет возможности откатиться назад и прочитать уже пришедшие данные еще раз.
NIO сразу читает данные в буфер. Вы можете перемещаться по этому буферу перечитывая уже прочитанную ранее информацию. Плата за это – необходимость вручную следить, что буфер заполнен достаточным объемом данных для обработки, и что он не переполнился.
В этой статье приводится показательная аналогия. Блокирующее чтение – это телефонный разговор, неблокирующее – переписка в чате. Делая телефонный звонок, вы ждете пока собеседник ответит, можете «обрабатывать» только один звонок одновременно, получаете ответы сразу и не можете переслушать услышанный но забытый ответ. В мессенджере вы ведете несколько чатов одновременно, обращаетесь к истории переписки, но ответы на ваши сообщения приходят не всегда сразу, а порядок их получения неоднозначен.
Java Guru🤓 #java
В контексте Java речь в этом вопросе идет о блокирующем/неблокирующем чтении из потоков данных.
Классы блокирующего чтения находятся в пакете java.io. Вы наверняка много раз сталкивались с ними, работая с файлами и консольным вводом-выводом (классы Reader, IOException, InputStream). При блокирующем чтении тред останавливается, пока не получит из потока необходимые данные. Для этих самых распространенных случаев использование неблокирующего чтения не несет пользы, потому что сама запись пользователем консоли и жестким диском будет последовательной.
Чтение данных из сетевого подключения – другое дело. Обычно программа обрабатывает данные быстрее, чем работает сеть. Возникают паузы, в которые поток блокирующего чтения стоит в ожидании, не принося пользы. К тому же серверное приложение работает со многими параллельными подключениями.
Блокирующее чтение можно распараллеливать на потоки, читая в пулле. Но делать это нужно вручную, а количество одновременных подключений будет всё ещё ограничено количеством потоков-обработчиков, потоки буду всё ещё останавливаться без дела.
Для случаев, когда в вашем приложении ожидается большое количество подключений, был добавлен пакет стандартной библиотеки java.nio. С помощью NIO один тред может обслуживать несколько сетевых соединений одновременно, и переключаться между ними не теряя времени на ожидание данных.
IO использует потоки. данные приходят последовательно, и сами нигде не сохраняются. Если вы не обеспечили буферизацию вручную, нет возможности откатиться назад и прочитать уже пришедшие данные еще раз.
NIO сразу читает данные в буфер. Вы можете перемещаться по этому буферу перечитывая уже прочитанную ранее информацию. Плата за это – необходимость вручную следить, что буфер заполнен достаточным объемом данных для обработки, и что он не переполнился.
В этой статье приводится показательная аналогия. Блокирующее чтение – это телефонный разговор, неблокирующее – переписка в чате. Делая телефонный звонок, вы ждете пока собеседник ответит, можете «обрабатывать» только один звонок одновременно, получаете ответы сразу и не можете переслушать услышанный но забытый ответ. В мессенджере вы ведете несколько чатов одновременно, обращаетесь к истории переписки, но ответы на ваши сообщения приходят не всегда сразу, а порядок их получения неоднозначен.
Java Guru🤓 #java
👍7🔥6❤3
Какой метод интерфейса Мар возвращает множество ключей из карты?
Anonymous Quiz
13%
keys()
13%
entryKeys()
19%
getKeys()
44%
keySet()
11%
entrySet()
👍7🔥4❤3🌭2