совсем не умеют признавать свои ошибки и баги в их продуктах
Я умею. Дофига багов, вообще глюкавище полное иногда релизим :( А кто не умеет? Можно более конкретный пример?
но искренно верят в свою исключительность и что их IDE одни из лучших
Так и есть. Наши IDE одни из лучших. Это показывают многие опросы и исследования, а также сам факт того, что IDE успешно продаются и наблюдается стабильный рост продаж даже в условиях когда гораздо более толстые конкуренты выкидывают на рынок бесплатные решения. Никакой слепой веры, голимые факты.
Самое главное они недостаточно понимают специфику работы конечных пользователей их IDE, и какие задачи они решают, будь-то живут в своей вселенной Jetbrains…
У наших IDE порядка 10 миллионов пользователей, большинство платных. Они все ошибаются? Пали жертвой агрессивного маркетинга? А может такое случиться, что как раз ваши потребности слишком специфичны и не укладываются в сценарии, которые нужны большинству (говоря русским языком, "пользователь хочет странного")?
Optional не решает проблему с null. Её лучше решают nullability-аннотации и в целом массовый отказ от null (non-null by default). Но, конечно, в Котлине это сделано красивее и удобнее.
Забавно, что цифры давления выглядят почти нормальными и не триггерят в голове ничего. Только они в паскалях, а не в миллиметрах ртутного столба (в привычных единицах было бы всего 5.5 вместо 750).
В дискуссии из упомянутого топика вы высказали позицию, что если хочется фич Ломбока, то лучше не использовать Ломбок, а выбрать другой язык. Потому что Ломбок как бы делает Джаву другим языком.
Да. От своих слов не отказываюсь.
Тем самым добавляя в Джаву синтаксический сахар, который вам не нравится ))
Скорее "поддерживая популярные технологии, даже если они кривые, потому что люди хотят". Мы в первую очередь делаем IDE удобную для всех, поэтому и поддерживаем. Но это не делает ломбок джавовее.
Я, кстати, тожеучаствовал в поддержке ломбоковских extension-методов в IntelliJ IDEA. Кстати, баги всё равно возможны. Наверняка ещё остались инспекции, квик-фиксы, рефакторинги, которые не ожидают такой подставы, что метод — вовсе не метод.
Интересно, что Stream.toList() появится в 16-й Java, причём будет там отличаться от Collectors.toList() (в отличие от последнего, возвращает неизменяемую коллекцию). Удачи потом баги фиксать.
Вы как-то сильно недооцениваете память программистов. В любом большом проекте есть тысячи внутренних методов, и знакомый с проектом программист обычно помнит и понимает, какой из них что делает, когда читает код. Редко когда требуется заглянуть в документацию. Да и в стандартной библиотеке тысячи методов, и в используемых библиотеках тоже. Пара новых ничего не усложняют. Конечно, было бы удобнее, если бы они появились в OpenJDK, но и свой утилитный класс это не большая проблема. При написании кода можно, кстати, стандартные шаблоны IDE переопределить, чтобы использовать новые методы автоматически.
Если класс не объявлен явно как final или sealed, то по логике вещей он как раз non-sealed.
Этот вопрос обсуждали, естественно. Смысл в том, что хорошего дефолта нет, а если сделать, что дефолт = non-sealed, то люди будут просто по забывчивости или лени открывать свои иерархии. Поэтому надо явно указывать.
Такие преобразования выполняются на платформенно-независимом IR задолго до кодогенерации, поэтому на ARM проблем быть не должно. Но если у кого-нибудь есть ARM под рукой, можете измерить. Что касается компиляции в нативный код — если это делать с помощью GraalVM, то она щёлкает боксинг как орехи уже давно. Там эскейп-анализ и скаляризация наголову выше, чем в C2. Они даже хвастались, что Objects.hash(i, j, k) будет работать с той же скоростью как и явный аналог типа ((31+i)31+j)31+k, то есть они и от массива-варарга, и он боксов в каждом элементе избавляются на раз.
Ну вот да. Я, кстати, не стал специально писать про смысл open в module-info, но и Реми, и Брайан сами про это упомянули. Maccimo, иди ворвись и скажи им, что они не потрудились :-)
Со словом open другая проблема — это уже ключевое слово! Да-да, только оно используется исключительно в файлах module-info.java, означая, что в данном модуле все классы доступны в рантайме (к примеру, для грязного рефлекшна). Кажется, что это может привнести некоторую путаницу: если класс объявлен open, это может быть воспринято в том же контексте (другим модулям разрешено лазить в потроха класса).
Везде заговор!
Я умею. Дофига багов, вообще глюкавище полное иногда релизим :( А кто не умеет? Можно более конкретный пример?
Так и есть. Наши IDE одни из лучших. Это показывают многие опросы и исследования, а также сам факт того, что IDE успешно продаются и наблюдается стабильный рост продаж даже в условиях когда гораздо более толстые конкуренты выкидывают на рынок бесплатные решения. Никакой слепой веры, голимые факты.
У наших IDE порядка 10 миллионов пользователей, большинство платных. Они все ошибаются? Пали жертвой агрессивного маркетинга? А может такое случиться, что как раз ваши потребности слишком специфичны и не укладываются в сценарии, которые нужны большинству (говоря русским языком, "пользователь хочет странного")?
Видимо, вы мало знакомы с развесистыми кодовыми базами. У нас довольно скромно по сравнению с некоторыми компаниями, которые активно используют Java.
В Котлин можно написать val notNullValue = calculateNullableValue() ?: return. Как вам тут поможет map и flatMap?
Optional не решает проблему с null. Её лучше решают nullability-аннотации и в целом массовый отказ от null (non-null by default). Но, конечно, в Котлине это сделано красивее и удобнее.
Скорее new Foo<Bar> ctrl+alt+v, остальное само допишется.
Забавно, что цифры давления выглядят почти нормальными и не триггерят в голове ничего. Только они в паскалях, а не в миллиметрах ртутного столба (в привычных единицах было бы всего 5.5 вместо 750).
График температуры лучше бы заскриншотить в градусах Цельсия. Таки не для американцев пишете.
Теоретически должен справиться. Практически вы можете сами написать бенчмарк и проверить :-)
Спасибо!
Да. От своих слов не отказываюсь.
Скорее "поддерживая популярные технологии, даже если они кривые, потому что люди хотят". Мы в первую очередь делаем IDE удобную для всех, поэтому и поддерживаем. Но это не делает ломбок джавовее.
Хм. При чём тут мой бог? Ничего не понял.
Я, кстати, тоже участвовал в поддержке ломбоковских extension-методов в IntelliJ IDEA. Кстати, баги всё равно возможны. Наверняка ещё остались инспекции, квик-фиксы, рефакторинги, которые не ожидают такой подставы, что метод — вовсе не метод.
Интересно, что Stream.toList() появится в 16-й Java, причём будет там отличаться от Collectors.toList() (в отличие от последнего, возвращает неизменяемую коллекцию). Удачи потом баги фиксать.
Вы как-то сильно недооцениваете память программистов. В любом большом проекте есть тысячи внутренних методов, и знакомый с проектом программист обычно помнит и понимает, какой из них что делает, когда читает код. Редко когда требуется заглянуть в документацию. Да и в стандартной библиотеке тысячи методов, и в используемых библиотеках тоже. Пара новых ничего не усложняют. Конечно, было бы удобнее, если бы они появились в OpenJDK, но и свой утилитный класс это не большая проблема. При написании кода можно, кстати, стандартные шаблоны IDE переопределить, чтобы использовать новые методы автоматически.
Не забываем про обратную совместимость.
Я говорил про свой собственный тип-обёртку, а не Integer. Читай внимательнее.
Этот вопрос обсуждали, естественно. Смысл в том, что хорошего дефолта нет, а если сделать, что дефолт = non-sealed, то люди будут просто по забывчивости или лени открывать свои иерархии. Поэтому надо явно указывать.
Я же тебе сказал, в amber-spec-comments, даже ссылку приложил.
Такие преобразования выполняются на платформенно-независимом IR задолго до кодогенерации, поэтому на ARM проблем быть не должно. Но если у кого-нибудь есть ARM под рукой, можете измерить. Что касается компиляции в нативный код — если это делать с помощью GraalVM, то она щёлкает боксинг как орехи уже давно. Там эскейп-анализ и скаляризация наголову выше, чем в C2. Они даже хвастались, что Objects.hash(i, j, k) будет работать с той же скоростью как и явный аналог типа ((31+i)31+j)31+k, то есть они и от массива-варарга, и он боксов в каждом элементе избавляются на раз.
Ну вот да. Я, кстати, не стал специально писать про смысл open в module-info, но и Реми, и Брайан сами про это упомянули. Maccimo, иди ворвись и скажи им, что они не потрудились :-)
Ну так и быть, вкинул слово 'open'. А то Maccimo вряд ли сам напишет. Посмотрим.
Со словом
openдругая проблема — это уже ключевое слово! Да-да, только оно используется исключительно в файлах module-info.java, означая, что в данном модуле все классы доступны в рантайме (к примеру, для грязного рефлекшна). Кажется, что это может привнести некоторую путаницу: если класс объявленopen, это может быть воспринято в том же контексте (другим модулям разрешено лазить в потроха класса).