Всем привет!
Возвращаюсь с постами из вынужденного перерыва, связанного как обычно бывает с работой)
Задавались ли вы вопросом: какие типы данных использовать в Java API - примитивные или типы-обвертки (boxed)?
Однонозначного ответа как водится нет, но есть ряд правил.
Плюсы примитивных типов:
1) занимают меньше памяти, т.к нет накладных расходов на Java объекты. Какой величины эти расходы - можно почитать тут: https://www.baeldung.com/jvm-measuring-object-sizes или посмотреть с шутками и прибаутками и хорошей дозой хардкора тут https://www.youtube.com/watch?v=3BmznLJAgaA
Плюсы обверток:
1) могут использоваться в generic-ах. А generic-и лежат в основе всяких разных фреймворков. Если вы не уверены, что не используете такие - то вот примеры: Mockito, Truth и AssertJ (см. https://t.me/javaKotlinDevOps/51), Hibernate
2) могут использоваться для передачи null значений. Да, не всегда это правильно, чаще неправильно, но такие кейсы бывают.
И если исходя из сказанного выше возникает мысль - может ну ее, эту производительность, пусть будет универсальный готовый к будущим изменениям код, то вот еще два фактора:
1) если в процессе написания кода потребуется boxing из примитивного типа в обвертку и наоборот, то в этих строчках кода могут возникать необъяснимые NPE. Особенно "хороши" такие NPE до Java 14)))
Примеры:
а)
Boolean variable;
if (variable) {
}
б)
Integer boxed;
int i = boxed;
Т.е. имеет смысл посмотреть на чужие API, которые мы используем и прикинуть, как часто придется преобразовывать типы.
2) код в настоящее стал достаточно гибким. В том плане, что если 50 лет назад для отладки программы нужно было набить код на перфокарте и дождаться своей очереди для ее исполнения на сервере, а 30 лет назад исправить большую Asm или C программу было тем еще приключением, то сейчас при правильном разбиении на микросервисы, использовании практик чистого кода и главное написании модульных тестов отрефакторить код не сложно. Если у вас не так - предлагаю над этим задуматься)
Итого:
1) Если нужны generic-и и\или придется часто преобразовывать в boxed типы - имеет смысл использовать их везде в своем API.
2) Если важна производительность - примитивы там, где большие объемы данных.
3) В остальных случаях предлагаю присмотреться к примитивам.
Если концепция поменялась - всегда есть рефакторинг. Чуть сложнее с Java API, выставленным наружу - выпущенным в виде библиотеки. Тут нас спасет версионирование API.
#java #types
Возвращаюсь с постами из вынужденного перерыва, связанного как обычно бывает с работой)
Задавались ли вы вопросом: какие типы данных использовать в Java API - примитивные или типы-обвертки (boxed)?
Однонозначного ответа как водится нет, но есть ряд правил.
Плюсы примитивных типов:
1) занимают меньше памяти, т.к нет накладных расходов на Java объекты. Какой величины эти расходы - можно почитать тут: https://www.baeldung.com/jvm-measuring-object-sizes или посмотреть с шутками и прибаутками и хорошей дозой хардкора тут https://www.youtube.com/watch?v=3BmznLJAgaA
Плюсы обверток:
1) могут использоваться в generic-ах. А generic-и лежат в основе всяких разных фреймворков. Если вы не уверены, что не используете такие - то вот примеры: Mockito, Truth и AssertJ (см. https://t.me/javaKotlinDevOps/51), Hibernate
2) могут использоваться для передачи null значений. Да, не всегда это правильно, чаще неправильно, но такие кейсы бывают.
И если исходя из сказанного выше возникает мысль - может ну ее, эту производительность, пусть будет универсальный готовый к будущим изменениям код, то вот еще два фактора:
1) если в процессе написания кода потребуется boxing из примитивного типа в обвертку и наоборот, то в этих строчках кода могут возникать необъяснимые NPE. Особенно "хороши" такие NPE до Java 14)))
Примеры:
а)
Boolean variable;
if (variable) {
}
б)
Integer boxed;
int i = boxed;
Т.е. имеет смысл посмотреть на чужие API, которые мы используем и прикинуть, как часто придется преобразовывать типы.
2) код в настоящее стал достаточно гибким. В том плане, что если 50 лет назад для отладки программы нужно было набить код на перфокарте и дождаться своей очереди для ее исполнения на сервере, а 30 лет назад исправить большую Asm или C программу было тем еще приключением, то сейчас при правильном разбиении на микросервисы, использовании практик чистого кода и главное написании модульных тестов отрефакторить код не сложно. Если у вас не так - предлагаю над этим задуматься)
Итого:
1) Если нужны generic-и и\или придется часто преобразовывать в boxed типы - имеет смысл использовать их везде в своем API.
2) Если важна производительность - примитивы там, где большие объемы данных.
3) В остальных случаях предлагаю присмотреться к примитивам.
Если концепция поменялась - всегда есть рефакторинг. Чуть сложнее с Java API, выставленным наружу - выпущенным в виде библиотеки. Тут нас спасет версионирование API.
#java #types
Baeldung
Measuring Object Sizes in the JVM | Baeldung
Learn how to measure Java object sizes with various tools such as JOL, Java Agents, and the jcmd command-line utility