Неужели этот код накидан на скорую руку и никто не хочет им заниматься?
Нет, этот код писали и переписывали очень долго и обсуждали с кучей людей, и ругались. И в Java 10 ещё допереписывали. Это выверенная и продуманная реализация.
Вот это очень неожиданно. Почему нельзя было просто всегда возвращать false? Зачем тут проверка на null. Это мне остается непонятным.
Throws: NullPointerException — if the specified element is null and this collection does not permit null elements (optional)
Коллекция поддерживает null-элементы? Нет. Значит, по контракту имеет право кидать NPE. Зачем это сделано? Если вы случайно вызовете на ней contains(null) (что не очень имеет смысл) вы вместо тихого false словите громкое исключение и сразу же поймёте, что в коде ошибка.
Мне одному кажется, что это заведомо рудиментарная вещь?
Пока неясно, но мне видится польза в том, что у вас один и тот же JAR-файл с разной версией JDK может работать с разной степенью эффективности без приседаний с рефлекшном. Представьте, что в новой версии JDK появился метод, который сделает код вашей библиотеки более быстрым. Однако напрямую использовать вы его не можете, потому что обещаете совместимость с предыдущей версией JDK. Можно собирать два джарика для разных версий JDK, но это очень неудобно и неэффективно. Пользователь не сможет автоматом получить преимущества, просто задеплоив приложение на сервер с более новой JDK: ему придётся иметь опциональные зависимости в проекте и знать при сборке, какая версия JDK будет на целевом сервере. Да и автору библиотеки неудобно поставлять несколько сборок. Если таких отличий немного, обычно втыкают грязный рефлекшн, а не плодят несколько версий библиотеки. С Multi-Release JARs можно обойтись без рефлекшна. Хотя неизвестно что лучше, потому что сборка проекта усложняется и поддержка в IDE далека от идеала. Время покажет.
Общее впечатление: я так понимаю, эволюция Java Api остановилась, и будущие изменения будут затрагивать по большей части JVM?
Вряд ли. Java 10 — это первый полугодовой релиз. До этого все колбасили большие фичи, стараясь изо всех сил их впихнуть в девятку, которую делали три с лишним года. А в эти полгода задела больших фич, которые можно пускать в продакшн, не осталось, поэтому релиз по большей части проходной. Но это не значит, что над большими фичами не работают, просто они будут позже.
Помню ещё в прошлом веке в ранние версии форумов ikonboard вставляли [img]file:///c:/con/con[/img], роняя ОС бедолагам с Windows 98, которые заходили в тему. Ничего в мире не меняется...
Как обычно, напоминаю, что не все изменения сидят в JEP'ах. Особенно то что касается стандартной библиотеки. Добавлено много приятных мелочей. Коллекторы toUnmodifiableList/Map/Set, например. Или методы вроде List.copyOf, которые создают неизменяемую копию коллекции (или не создают, если на вход уже подан неизменяемый список).
Нагуглил Solhint, который что-то умеет. В частности, ругается на любое использование block.blockhash. Это, конечно, слишком глупо, но лучше чем ничего. И даже плагин к IDEA имеется.
Обычно изменённый после рефакторинга код форматируется в соответствии с текущими настройками стиля. Даже если фрагмент исходного кода переиспользуется, и он изначально не соответствовал стилю, то он тоже переформатируется.
Ну так существенная часть моего патча состояла в том, чтобы определить, когда можно доверять значениям из массива, а когда нельзя. Собственно в dataflow может один вызов добавился. Визитор и вам написать пришлось, так что вы всё-таки что-то сделали специально ;-)
Ну, положим, вы кривите душой. Вам специально пришлось подрубать Spoon, генерировать JNI-обёртки с помощью Swig'а и чёрт знает что ещё. А вот давайте блэкбокс-тестирование проведём, мне интересно. Вот вам исходник A и исходник B. Сохраняются ли варнинги в этих случаях?
Нет, этот код писали и переписывали очень долго и обсуждали с кучей людей, и ругались. И в Java 10 ещё допереписывали. Это выверенная и продуманная реализация.
Открываем контракт класса Collection и читаем:
Коллекция поддерживает null-элементы? Нет. Значит, по контракту имеет право кидать NPE. Зачем это сделано? Если вы случайно вызовете на ней
contains(null)
(что не очень имеет смысл) вы вместо тихого false словите громкое исключение и сразу же поймёте, что в коде ошибка.Пока неясно, но мне видится польза в том, что у вас один и тот же JAR-файл с разной версией JDK может работать с разной степенью эффективности без приседаний с рефлекшном. Представьте, что в новой версии JDK появился метод, который сделает код вашей библиотеки более быстрым. Однако напрямую использовать вы его не можете, потому что обещаете совместимость с предыдущей версией JDK. Можно собирать два джарика для разных версий JDK, но это очень неудобно и неэффективно. Пользователь не сможет автоматом получить преимущества, просто задеплоив приложение на сервер с более новой JDK: ему придётся иметь опциональные зависимости в проекте и знать при сборке, какая версия JDK будет на целевом сервере. Да и автору библиотеки неудобно поставлять несколько сборок. Если таких отличий немного, обычно втыкают грязный рефлекшн, а не плодят несколько версий библиотеки. С Multi-Release JARs можно обойтись без рефлекшна. Хотя неизвестно что лучше, потому что сборка проекта усложняется и поддержка в IDE далека от идеала. Время покажет.
Вряд ли. Java 10 — это первый полугодовой релиз. До этого все колбасили большие фичи, стараясь изо всех сил их впихнуть в девятку, которую делали три с лишним года. А в эти полгода задела больших фич, которые можно пускать в продакшн, не осталось, поэтому релиз по большей части проходной. Но это не значит, что над большими фичами не работают, просто они будут позже.
Английская википедия говорит
Не находите, что "получил 3 года" — это совсем не то же самое, что "три года условно и 720 часов общественных работ"?
Притащить Криса в Сибирь! Вы круты, жму руку!
Я тут младенца убаюкиваю, не до докладов, честно.
Шипилёва не завезли в этот раз? :-)
Видал я код квалифицированных математиков. Частенько он очень плох.
Помню ещё в прошлом веке в ранние версии форумов ikonboard вставляли
[img]file:///c:/con/con[/img]
, роняя ОС бедолагам с Windows 98, которые заходили в тему. Ничего в мире не меняется...HotSpot всегда входил в OpenJDK
Нагуглил Solhint, который что-то умеет. В частности, ругается на любое использование
block.blockhash
. Это, конечно, слишком глупо, но лучше чем ничего. И даже плагин к IDEA имеется.Интересно, а для Solidity IDE со статическим анализатором ещё не придумали? Штуки вроде block.blockhash(block.number) бегут ловятся статически.
Обычно изменённый после рефакторинга код форматируется в соответствии с текущими настройками стиля. Даже если фрагмент исходного кода переиспользуется, и он изначально не соответствовал стилю, то он тоже переформатируется.
Ну так существенная часть моего патча состояла в том, чтобы определить, когда можно доверять значениям из массива, а когда нельзя. Собственно в dataflow может один вызов добавился. Визитор и вам написать пришлось, так что вы всё-таки что-то сделали специально ;-)
Заметку я читал, конечно, она тут совсем ни при чем. Отсутствие варнинга как раз ожидаемо. Откуда же dataflow знает про джавовые уровни доступа?
Ну, положим, вы кривите душой. Вам специально пришлось подрубать Spoon, генерировать JNI-обёртки с помощью Swig'а и чёрт знает что ещё. А вот давайте блэкбокс-тестирование проведём, мне интересно. Вот вам исходник A и исходник B. Сохраняются ли варнинги в этих случаях?
Arrays.asList
-то ты не проверил.Здесь вы сильно драматизируете.
А это просто враньё.
Надо, кстати, проверить. Теоретически его итератор добили до состояния, когда он может удалиться полностью escape-анализом в плотном цикле.
Ну так кури сорцы :D