Спецификации пишутся людьми. И так же как в имплементациях тоже могут содержать ошибки. Если здравый смысл перевешивает спецификацию, то надо выбирать здравый смысл и исправлять спецификацию.
Мало ли что написано в спецификации. Когда юзер передаёт 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 её догадались скопировать из джавадока в сам метод )))
А вот Алан Кей, создатель ООП, говорит об обратном, сами объекты менее важны, чем сообщения.
То, что создал Алан Кей, мало имеет отношения к тому, что сейчас принято называть ООП. То самое ООП, которое он создал, это скорее модель акторов типа Akka или Erlang. Мне удобнее мыслить в терминах интерфейсов и классов, и там нет никаких сообщений (по крайней мере first-class), а есть инкапсуляция, наследование и полиморфизм.
В Rust есть инкапсуляция, наследование и полиморфизм, но это не ООП язык.
Ну и что? Самокат – это транспортное средство, но транспортное средство – это не обязательно самокат.
стараться не прибегать к мутабельности, и смысл ФП — разные вещи. ФП — это скорее отсутствие состояния, а вовсе не иммутабельность
Какая-то каша. Сначала вы про чистые функции говорите, теперь вот почему-то уже это отсутствие состояния. Вообще иммутабельность, отсутствие состояния и чистые функции – это вовсе не взаимоисключающие понятия. Скорее наоборот, это тесно связанные вещи, и если используешь что-то одно, то, скорее всего, ты автоматически получаешь другое. Если ты используешь только иммутабельность, то у тебя 99% кода будет чистым. И если ты пишешь только чистые функции, то у тебя, почти всё будет иммутабельное.
И в том же Хаскеле кстати вполне себе есть наследование, полиморфизм и инкапсуляция
Откуда в Хаскелле наследование? Тайпклассы – это не наследование. Это реализация интерфейса, что совсем не то же самое. Полиморфизм там есть, но другой. В ООП это подтиповой полиморфизм, а там параметрический.
Актуально. 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 её догадались скопировать из джавадока в сам метод )))
То, что создал Алан Кей, мало имеет отношения к тому, что сейчас принято называть ООП. То самое ООП, которое он создал, это скорее модель акторов типа Akka или Erlang. Мне удобнее мыслить в терминах интерфейсов и классов, и там нет никаких сообщений (по крайней мере first-class), а есть инкапсуляция, наследование и полиморфизм.
Ну и что? Самокат – это транспортное средство, но транспортное средство – это не обязательно самокат.
Какая-то каша. Сначала вы про чистые функции говорите, теперь вот почему-то уже это отсутствие состояния. Вообще иммутабельность, отсутствие состояния и чистые функции – это вовсе не взаимоисключающие понятия. Скорее наоборот, это тесно связанные вещи, и если используешь что-то одно, то, скорее всего, ты автоматически получаешь другое. Если ты используешь только иммутабельность, то у тебя 99% кода будет чистым. И если ты пишешь только чистые функции, то у тебя, почти всё будет иммутабельное.
Откуда в Хаскелле наследование? Тайпклассы – это не наследование. Это реализация интерфейса, что совсем не то же самое. Полиморфизм там есть, но другой. В ООП это подтиповой полиморфизм, а там параметрический.