Deprecated
Два deprecated конструктора String — это:
• public String(byte[] ascii, int hibyte)
• public String(byte[] ascii, int hibyte, int offset, int count)
Это два конструктора из античных времён, которые задепрекейтили ещё аж в Java 1.1. Они конвертируют массив байт в строку, но позволяют указать 8 верхних бит символов.
Эти конструкторы не стоит использовать, потому что они не делают ничего такого, чего нельзя сделать с помощью нормальных конструкторов, принимающих byte[] или char[].
Однако эти конструкторы немного используются в самой стандартной библиотеке, поскольку работают немного быстрее ближайших аналогов. Например, один из этих конструкторов используется в новой реализации Double.toString() в Java 19, которая стала во много раз быстрее предыдущей. Но надо понимать, что подобные оптимизации люди применяют не от балды, а тщательно проверив и убедившись через бенчмарки, что код действительно становится быстрее. И выигрыш там, скорее всего, совсем микроскопический.
В практическом коде же, если вам надо эффективно сконвертировать массив латинских символов в строку, то не надо выпендриваться и нужно просто вызвать
Как видите, с конструкторами String всё довольно просто.
Два deprecated конструктора String — это:
• public String(byte[] ascii, int hibyte)
• public String(byte[] ascii, int hibyte, int offset, int count)
Это два конструктора из античных времён, которые задепрекейтили ещё аж в Java 1.1. Они конвертируют массив байт в строку, но позволяют указать 8 верхних бит символов.
Эти конструкторы не стоит использовать, потому что они не делают ничего такого, чего нельзя сделать с помощью нормальных конструкторов, принимающих byte[] или char[].
Однако эти конструкторы немного используются в самой стандартной библиотеке, поскольку работают немного быстрее ближайших аналогов. Например, один из этих конструкторов используется в новой реализации Double.toString() в Java 19, которая стала во много раз быстрее предыдущей. Но надо понимать, что подобные оптимизации люди применяют не от балды, а тщательно проверив и убедившись через бенчмарки, что код действительно становится быстрее. И выигрыш там, скорее всего, совсем микроскопический.
В практическом коде же, если вам надо эффективно сконвертировать массив латинских символов в строку, то не надо выпендриваться и нужно просто вызвать
new String(bytes, StandardCharsets.ISO_8859_1). Это будет почти то же самое по скорости, но будет выглядеть чисто и понятно.Как видите, с конструкторами String всё довольно просто.
🔥6
🤯 Данный код является валидным кодом на Java 19+ и компилируется.
Почему так:
1. Первый When – это имя класса.
2. Второй when – имя переменной (имеет тип When).
3. Третий when – это новое ключевое слово в Java 19, которое является контекстно-зависимым.
4. Четвёртый when – это имя переменной, которая была объявлена (см. пункт 2).
5. Пятый when() – метод класса When, возвращающий boolean.
6. Шестой when() – метод текущего класса.
#java19
Почему так:
2. Второй when – имя переменной (имеет тип When).
3. Третий when – это новое ключевое слово в Java 19, которое является контекстно-зависимым.
4. Четвёртый when – это имя переменной, которая была объявлена (см. пункт 2).
5. Пятый when() – метод класса When, возвращающий boolean.
6. Шестой when() – метод текущего класса.
🤯29👍5😁5😱3👎1
New candidate JEP: 431: Sequenced Collections
https://openjdk.org/jeps/431
Introduce new interfaces to represent collections with a defined encounter order. There are uniform APIs for accessing first and last elements, and for processing elements in reverse order.
#jep #java20
https://openjdk.org/jeps/431
Introduce new interfaces to represent collections with a defined encounter order. There are uniform APIs for accessing first and last elements, and for processing elements in reverse order.
#jep #java20
🤔5🤩2🤨1
⚡️ GraalVM CE переезжает в OpenJDK.
Пока никаких деталей нет кроме тех, что указаны в твите:
• Переезжает только GraalVM Community. GraalVM Enterprise, скорее всего, будет продолжать продаваться отдельно. В GraalVM EE больше оптимизаций, чем в GraalVM CE.
• GraalVM JIT и Native Image будут частью OpenJDK.
• GraalVM будет иметь тот же релизный цикл и модель лицензирования, что и OpenJDK (впрочем, у GraalVM CE и так был GPL v2, так что непонятно, что поменяется).
#graalvm
Пока никаких деталей нет кроме тех, что указаны в твите:
• Переезжает только GraalVM Community. GraalVM Enterprise, скорее всего, будет продолжать продаваться отдельно. В GraalVM EE больше оптимизаций, чем в GraalVM CE.
• GraalVM JIT и Native Image будут частью OpenJDK.
• GraalVM будет иметь тот же релизный цикл и модель лицензирования, что и OpenJDK (впрочем, у GraalVM CE и так был GPL v2, так что непонятно, что поменяется).
#graalvm
X (formerly Twitter)
GraalVM (@graalvm) on X
Excited about @GraalVM JIT and Native Image becoming part of OpenJDK!🚀
#JavaOne
#JavaOne
🔥10👏4
Про недавно опубликованную уязвимость в Apache Commons Text: https://www.securitylab.ru/analytics/534471.php.
TLDR: уязвимость действительно есть, но не настолько суровая, как Log4Shell. Но на всякий случай лучше обновить Commons Text до 1.10.0 (который кстати тоже остаётся уязвимым, но в меньшей степени).
TLDR: уязвимость действительно есть, но не настолько суровая, как Log4Shell. Но на всякий случай лучше обновить Commons Text до 1.10.0 (который кстати тоже остаётся уязвимым, но в меньшей степени).
🤔1
microJUG
⚡️ GraalVM CE переезжает в OpenJDK. Пока никаких деталей нет кроме тех, что указаны в твите: • Переезжает только GraalVM Community. GraalVM Enterprise, скорее всего, будет продолжать продаваться отдельно. В GraalVM EE больше оптимизаций, чем в GraalVM CE.…
На сайте Грааля вышел более подробный пост про вхождение GraalVM в состав OpenJDK. Особо ничего нового там нет. Много воды. Разве что сказано, что вхождение запланировано на 2023 год.
🥱9
Кто-нибудь когда-нибудь называл Джаву Ждавой? Неужели я первый это придумал только что?
(По-любому же должен был быть мем)
(По-любому же должен был быть мем)
🤡23🤨6😁1💊1
Прекратите использовать ArrayList
Я серьёзно. В 2022 году Java-программисту он не нужен практически никогда. Если в Java 8 ещё можно было оправдать его использование, потому что в стандартной библиотеке не было адекватной замены, то с Java 9 нужда в нём резко упала с введением неизменяемых коллекций.
Давайте я по полкам разберу все возможные варианты и покажу, как можно избежать использования ArrayList в большинстве случаев.
Мне нужно завести список, как это сделать?
Очень просто: заводите список с помощью List.of(). Либо если нужно создать список от существующей коллекции, то пишете List.copyOf(collection).
Пример:
Не вопрос. В Java 16 появилась возможность создавать иммутабельные списки с помощью Stream.toList(), который поддерживает null-элементы.
Пример:
Используйте Stream.builder().
Пример:
Ну а если мне всё-таки нужен изменяемый список? Мне надо хранить изменяемое состояние!
Используйте старый добрый метод Arrays.asList. Пример:
Вот только в этом случае используйте ArrayList. Если ни один из четырёх случаев выше вам не подходит (по моему личному опыту такое нужно чрезвычайно редко).
Помните, что наиболее правильный подход – это immutable by default. Это избавляет от большого класса ошибок и делает код легче для понимания. Начинайте решать задачу с использованием иммутабельности, и только если это не работает, переходите к мутабельности.
#arraylist
Я серьёзно. В 2022 году Java-программисту он не нужен практически никогда. Если в Java 8 ещё можно было оправдать его использование, потому что в стандартной библиотеке не было адекватной замены, то с Java 9 нужда в нём резко упала с введением неизменяемых коллекций.
Давайте я по полкам разберу все возможные варианты и покажу, как можно избежать использования ArrayList в большинстве случаев.
Мне нужно завести список, как это сделать?
Очень просто: заводите список с помощью List.of(). Либо если нужно создать список от существующей коллекции, то пишете List.copyOf(collection).
Пример:
var list = List.of(1, 2, 3);
var list2 = List.copyOf(col);Стоп, List.of() не поддерживает null-элементы, а мне это нужно!
Не вопрос. В Java 16 появилась возможность создавать иммутабельные списки с помощью Stream.toList(), который поддерживает null-элементы.
Пример:
var list = Stream.of(1, 2, null).toList();
А если мне нужно инициализировать список динамически? Я не могу использовать List.of/Stream.of, потому что не знаю количество элементов заранее!Используйте Stream.builder().
Пример:
var builder = Stream.<Integer> builder();Кстати, построение списка с помощью Stream.builder() эффективнее, чем через ArrayList. Об этом я писал тут.
builder.add(1);
builder.add(2);
if (condition) {
builder.add(3);
}
var list = builder.build().toList();
Ну а если мне всё-таки нужен изменяемый список? Мне надо хранить изменяемое состояние!
Используйте старый добрый метод Arrays.asList. Пример:
var list = Arrays.asList(1, 2, 3);Если нужно создать копию от существующей коллекции:
list.set(1) = 4;
var list = Arrays.asList(col.toArray(Integer[]::new))Мне нужен расширяемый список! Я хочу добавлять и удалять элементы!
Вот только в этом случае используйте ArrayList. Если ни один из четырёх случаев выше вам не подходит (по моему личному опыту такое нужно чрезвычайно редко).
Помните, что наиболее правильный подход – это immutable by default. Это избавляет от большого класса ошибок и делает код легче для понимания. Начинайте решать задачу с использованием иммутабельности, и только если это не работает, переходите к мутабельности.
#arraylist
👎31👍19🤔6🤮3🤡3⚡2❤1🔥1
Всего месяц остался до первой фазы Rampdown, а в JDK 20 до сих пор нет ни одного JEP'а. Понятно, что в релиз не могут не попасть всякие вторые инкубаторы и восьмые превью. Т.е. однозначно будут:
• JEP 433: Pattern Matching for switch (Fourth Preview)
• JEP 432: Record Patterns (Second Preview)
• JEP 434: Foreign Function & Memory API (Second Preview)
• JEP XXX: Virtual Threads (Second Preview)
• JEP XXX: Structured Concurrency (Second Incubator)
А вот новые фичи что-то не подвозят. Для меня наибольший интерес представляет JEP 430: String Templates (Preview), и он сейчас в активной разработке. Надеюсь, что он всё-таки успеет.
Второй – JEP 431: Sequenced Collections, и он тоже пока в разработке.
Ещё может попасть JEP 429: Scoped values (Incubator). Раньше он назывался Extent-Local Variables.
Итого, будет где-то 5-8 JEP'ов. Релиз будет вполне полноценным.
Ну и не забывайте, что даже если в релизе нет вообще ни одного JEP'а, то в любом случае присутствуют тысячи мелких улучшений, оптимизаций, исправлений багов и т.д. Например, будет ещё большее сокращение потребляемой памяти у G1. Так что повод обновляться до Java 20 будет!
#java20
• JEP 433: Pattern Matching for switch (Fourth Preview)
• JEP 432: Record Patterns (Second Preview)
• JEP 434: Foreign Function & Memory API (Second Preview)
• JEP XXX: Virtual Threads (Second Preview)
• JEP XXX: Structured Concurrency (Second Incubator)
А вот новые фичи что-то не подвозят. Для меня наибольший интерес представляет JEP 430: String Templates (Preview), и он сейчас в активной разработке. Надеюсь, что он всё-таки успеет.
Второй – JEP 431: Sequenced Collections, и он тоже пока в разработке.
Ещё может попасть JEP 429: Scoped values (Incubator). Раньше он назывался Extent-Local Variables.
Итого, будет где-то 5-8 JEP'ов. Релиз будет вполне полноценным.
Ну и не забывайте, что даже если в релизе нет вообще ни одного JEP'а, то в любом случае присутствуют тысячи мелких улучшений, оптимизаций, исправлений багов и т.д. Например, будет ещё большее сокращение потребляемой памяти у G1. Так что повод обновляться до Java 20 будет!
#java20
👍4🥱3🔥1🤯1
👍7🤔1
Полезное улучшение в Java 19: отдельная страница поиска по JavaDoc'у. До Java 19 можно было вводить строку поиска только в выпадающем меню. А сейчас можно, например, скинуть коллеге ссылку со строкой запроса: https://docs.oracle.com/en/java/javase/19/docs/api/search.html?q=map%20copyof.
Кроме того, теперь можно искать по нескольким словам. Например, если ввести "map copyof", то JavaDoc найдёт все сигнатуры, где встречаются и map, и copyof.
#java19 #javadoc
Кроме того, теперь можно искать по нескольким словам. Например, если ввести "map copyof", то JavaDoc найдёт все сигнатуры, где встречаются и map, и copyof.
#java19 #javadoc
👍12👌1