Фишки Java 13

Все уже в курсе: Java 12 вышла, мои поздравления!
Можно выдохнуть и начинать готовиться к Java 13, которая уже не за горами.
Посмотрим, что нас ждет.

Сырые строки

Сырые строки, о которых я писал тут, не вошли в Jdk12 и перешли в плановый релиз Jdk13.
Очень интересная и полезная фича, на мой взгляд. Ждем!

Эра Прекрасной Гармонии

1 мая 2019 года новый император Японии наследный принц Нарухито взойдет на престол, ознаменовав этим начало новой эпохи летоисчисления в Японии - эры Рэйва, эры прекрасной гармонии!

Вы об этом знали? Я знал!

Потому что в Jdk13 вошло изменение, согласно которому при форматировании даты будет использоваться новое название эпохи "Reiwa".

Если мы выполним код:

import java.time.Month;
import java.time.chrono.JapaneseDate;

public class PrintJapaneseDate {
    public static void main(String[] args) {
        //7 апреля 2019г - Эпоха Хэйсэй
        JapaneseDate now = JapaneseDate.of(2019, Month.APRIL.getValue(), 7);
        System.out.println(now);

        //1 мая 2019г - Эпоха Рэйва
        JapaneseDate reiwa = JapaneseDate.of(2019, Month.MAY.getValue(), 1);
        System.out.println(reiwa);
    }
}

то на ранних версиях Java мы получим:

Japanese Heisei 31-04-07
Japanese Heisei 31-05-01

на Java 12, мы увидим:

Japanese Heisei 31-04-07
Japanese NewEra 1-05-01

и, наконец, на Java 13:

Japanese Heisei 31-04-07
Japanese Reiwa 1-05-01

Я рад, что Япония вступает в новую эру с таким милым обновлением=).

Удалена опция -XX:+AggressiveOpts 

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

При включении AggressiveOpts:

1. Увеличивался размер кэша для целых чисел (опция -XX:AutoBoxCacheMax);
2. Удешевляет механизм блокировки блока synchronized путем привязки объекта к потоку (опция -XX:BiasedLockingStartupDelay);
3. Оптимизирует операцию конкатенации строк (опция -XX:+OptimizeStringConcat);
4. Оптимизирует создание и копирование массивов путем замены соответствующего кода на машинные инструкции (опция -XX:+OptimizeFill);
5. Уменьшение количества автоупаковок целых чисел (опция -XX:+EliminateAutoBox);
6. Уменьшение памяти для строк, символы которых можно упаковать в один байт (опция -XX:+UseCompressedStrings);
7. Включение кэширования строк (опция -XX:+UseStringCache);
8. Уменьшение размера указателя внутри JVM, где это возможно (опция -XX:+UseCompressedOops);
9. Объединяет блоки synchronized для уменьшения количества операций захвата монитора (опция -XX:+EliminateLocks); 

В общем, включение опции AggressiveOpts приводило к изменению значений кучи параметров, положительный эффект от которых довольно спорен в ряде случаев. 

Теперь этой опции больше нет:

Unrecognized VM option 'AggressiveOpts'
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.

Изменено поведение декодера Unicode-последовательности

Класс UnicodeDecoder изменил свое поведение при обработке "некорректных" последовательностей в соответствии с изменениями в Unicode 7.

Изменено поведение классов Base64.Encoder и Base64.Decoder

При обработке больших массивов данных методы encode и decode генерировали невразумительные ошибки, типа NegativeArraySizeException, что усложняло диагностику проблемы. 

Теперь при проблемах выделения памяти, методы будут честно кидать OutOfMemoryError.

Удален экспериментальный режим совместимости с FIPS 140

Криптопровайдер SunJSSE имел экспериментальную возможность работать в соответствии с федеральным стандартом по обработке информации правительства США. 

Неизвестно, пользовался ли кто-то этой возможностью, но режим был удален, потому что "слишком усложнял код". Удобно=).

Изменено поведение класса StringBuffer

Раньше Javadoc конструктора StringBuffer(CharSequence) гласил:

If the length of the specified CharSequence is less than or equal to zero, then an empty buffer of capacity 16 is returned.

Однако, если выполнить вот такой код:

public class StringBufferTest {
    public static void main(String[] args) {
        CharSequence seq = new MyNegLenCharSeq();

        StringBuffer sb = new StringBuffer(seq);
        System.out.println(sb.capacity());
    }

    private static class MyNegLenCharSeq implements CharSequence {
        public char charAt(int i) {
            throw new UnsupportedOperationException();
        }

        public int length() {
            return -42;
        }

        public CharSequence subSequence(int st, int e) {
            throw new UnsupportedOperationException();
        }

        public String toString() {
            return "";
        }
    }
}

легко убедиться, что поведение класса StringBuffer не соответствует ожидаемому:

Exception in thread "main" java.lang.NegativeArraySizeException
 at java.lang.AbstractStringBuilder.(AbstractStringBuilder.java:68)
 at java.lang.StringBuffer.(StringBuffer.java:128)
 at java.lang.StringBuffer.(StringBuffer.java:157)
 at StringBufferTest.main(StringBufferTest.java:5)

В Java 13 в тексте ошибки указывается неверное отрицательное значение длины последовательности символов. А провокационную строчку из Javadoc убрали:

Exception in thread "main" java.lang.NegativeArraySizeException: Negative length: -42
 at java.base/java.lang.AbstractStringBuilder.(AbstractStringBuilder.java:101)
 at java.base/java.lang.StringBuffer.(StringBuffer.java:165)
 at StringBufferTest.main(StringBufferTest.java:5)

Удален пакет com.sun.net.ssl

Классы пакета com.sun.net.ssl были помечены, как устаревшие еще в Java 1.4. 

Если в более ранних версиях Java в файле java.security можно было найти строчки:

security.provider.1=sun.security.provider.Sun
security.provider.2=sun.security.rsa.SunRsaSign
security.provider.3=sun.security.ec.SunEC
security.provider.4=com.sun.net.ssl.internal.ssl.Provider
security.provider.5=com.sun.crypto.provider.SunJCE
security.provider.6=sun.security.jgss.SunProvider
security.provider.7=com.sun.security.sasl.Provider
security.provider.8=org.jcp.xml.dsig.internal.dom.XMLDSigRI
security.provider.9=sun.security.smartcardio.SunPCSC
security.provider.10=sun.security.mscapi.SunMSCAPI

где фигурировал указанный выше пакет, то в Java 12 это выглядит так:

security.provider.1=SUN
security.provider.2=SunRsaSign
security.provider.3=SunEC
security.provider.4=SunJSSE
security.provider.5=SunJCE
security.provider.6=SunJGSS
security.provider.7=SunSASL
security.provider.8=XMLDSig
security.provider.9=SunPCSC
security.provider.10=JdkLDAP
security.provider.11=JdkSASL
security.provider.12=SunMSCAPI
security.provider.13=SunPKCS11

К тому же в Java 12 появился механизм экспортируемых модулей, но пакет com.sun.net.ssl не экспортировался ни из одного из них.
Поэтому можно со спокойной совестью удалить его и забыть)).

Пакет javax.security.cert помечен, как устаревший

Вместо классов этого пакета нужно использовать их альтернативы из пакета java.security.cert.

Итого

На этом я закончу этот краткий обзор имеющихся на текущий момент изменений в Java 13. 

Мы еще в начале релизного цикла Java, поэтому самые интересные изменения еще впереди. Наберемся терпения и немного подождем новой и лучшей Java. 

Пока!