Спецификации пишутся людьми. И так же как в имплементациях тоже могут содержать ошибки. Если здравый смысл перевешивает спецификацию, то надо выбирать здравый смысл и исправлять спецификацию.
Мало ли что написано в спецификации. Когда юзер передаёт char[] в конструктор String, он ожидает, что конструктор будет работать согласно здравому смыслу. То есть как если бы String был реализован на массивах char'ов, как было в Java 8. А в Java 8 массив копировался единожды и никакого сломанного состояния это не могло вызвать.
В Java 9 же это поведение сломали: теперь массив копируется дважды. И теперь существует способ сломать строки, один из важнейших классов JDK. Раньше их нельзя было сломать, теперь - можно. Значит, это регресия. А значит, баг.
IDEA поддерживает 18 только в EAP вроде бы. 2021.3 не поддерживает. Eclipse как обычно добавит поддержку через 3 месяца (либо прямо сейчас можно скачать плагин). Maven автоматически должен работать с новыми версиями, там ничего специального не надо делать до этого. Gradle вроде ещё не поддерживает.
Перегрузка тут никак не мешает, потому что к Function<T, U> применима только String.toLowerCase(), но не String.toLowerCase(Locale).
А кто сказал, что я никуда не присваиваю? Если я хочу написать Comparator<String> cmp = Comparator.comparing(String::toLowerCase).reversed(), то работать не будет аналогично.
А при чём здесь Oracle JDK и Open Source? Oracle JDK это проприетарная и закрытая JDK, просто с довольно свободной лицензией. А если в отечественном ПО использовать OpenJDK с GPL, то этот пункт про санкции там не требуется выполнять.
Уточню, что поддержка в течение одного года после выхода следующей LTS означает, что обновления для Java 17 будут выходить как минимум 3 года, потому что Java 21 выходит через 2 года.
Интересно, что в джавадоке метода реализация без ветвления упомянута, причём ещё с Java 9
As implied by the above, one valid implementation of this method is given by the expression below
which computes a double with the same exponent and significand as the argument but with a
guaranteed zero sign bit indicating a positive value:
Double.longBitsToDouble((Double.doubleToRawLongBits(a)<<1)>>>1)
Странно, что только в Java 18 её догадались скопировать из джавадока в сам метод )))
Да, ждём
Актуально. JRE не может запускать нескомпилированные программы, потому что у него нет модуля jdk.compiler. Так что JDK всё ещё необходим для этого.
Спецификации пишутся людьми. И так же как в имплементациях тоже могут содержать ошибки. Если здравый смысл перевешивает спецификацию, то надо выбирать здравый смысл и исправлять спецификацию.
Мало ли что написано в спецификации. Когда юзер передаёт char[] в конструктор String, он ожидает, что конструктор будет работать согласно здравому смыслу. То есть как если бы String был реализован на массивах char'ов, как было в Java 8. А в Java 8 массив копировался единожды и никакого сломанного состояния это не могло вызвать.
В Java 9 же это поведение сломали: теперь массив копируется дважды. И теперь существует способ сломать строки, один из важнейших классов JDK. Раньше их нельзя было сломать, теперь - можно. Значит, это регресия. А значит, баг.
Только при чём здесь билдеры? Строки конструируются из массивов, а не из билдеров.
По-моему, в последнее время темп развития Котлина сильно замедлился, а Джавы – наоборот, ускорился
Ясно
А чем вас не устраивают аннотации JetBrains?
Николай Парлог (Java Developer Advocate в Oracle) считает, что первое preview Loom попадёт в JDK 20.
IDEA поддерживает 18 только в EAP вроде бы. 2021.3 не поддерживает.
Eclipse как обычно добавит поддержку через 3 месяца (либо прямо сейчас можно скачать плагин).
Maven автоматически должен работать с новыми версиями, там ничего специального не надо делать до этого.
Gradle вроде ещё не поддерживает.
Перегрузка тут никак не мешает, потому что к Function<T, U> применима только String.toLowerCase(), но не String.toLowerCase(Locale).
А кто сказал, что я никуда не присваиваю? Если я хочу написать Comparator<String> cmp = Comparator.comparing(String::toLowerCase).reversed(), то работать не будет аналогично.
String является Comparable
А ещё есть пример
Comparator.comparing(String::toLowerCase), который почему-то не компилируется в JavaА при чём здесь Oracle JDK и Open Source? Oracle JDK это проприетарная и закрытая JDK, просто с довольно свободной лицензией. А если в отечественном ПО использовать OpenJDK с GPL, то этот пункт про санкции там не требуется выполнять.
Java 11 уже обогнала 8 по популярности
Oracle JDK уже давно не самая популярная. Сейчас Oracle OpenJDK и AdoptOpenJDK/Adoptium более популярны.
А ещё обновления будут выходить 3 года, а не полгода, как это было для Java 9-16.
Уточню, что поддержка в течение одного года после выхода следующей LTS означает, что обновления для Java 17 будут выходить как минимум 3 года, потому что Java 21 выходит через 2 года.
А ещё у меня ошибка 404 при открытии "Moving the JDK to a Two Year LTS Cadence". У меня одного так?
Интересно, что в джавадоке метода реализация без ветвления упомянута, причём ещё с Java 9
Странно, что только в Java 18 её догадались скопировать из джавадока в сам метод )))