All streams
Search
Write a publication
Pull to refresh
632
0
Тагир Валеев @tagir_valeev

Программист

Send message
Неужели этот код накидан на скорую руку и никто не хочет им заниматься?

Нет, этот код писали и переписывали очень долго и обсуждали с кучей людей, и ругались. И в Java 10 ещё допереписывали. Это выверенная и продуманная реализация.


Вот это очень неожиданно. Почему нельзя было просто всегда возвращать false? Зачем тут проверка на null. Это мне остается непонятным.

Открываем контракт класса Collection и читаем:


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 — это первый полугодовой релиз. До этого все колбасили большие фичи, стараясь изо всех сил их впихнуть в девятку, которую делали три с лишним года. А в эти полгода задела больших фич, которые можно пускать в продакшн, не осталось, поэтому релиз по большей части проходной. Но это не значит, что над большими фичами не работают, просто они будут позже.

Так вот, за свою шутку Сэми получил 3 года.

Английская википедия говорит


but paying a fine of $20,000 USD, serving three years of probation, working 720 hours of community service

Не находите, что "получил 3 года" — это совсем не то же самое, что "три года условно и 720 часов общественных работ"?

Я тут младенца убаюкиваю, не до докладов, честно.

Шипилёва не завезли в этот раз? :-)

Если бы разработкой софта занимались квалифицированные математики

Видал я код квалифицированных математиков. Частенько он очень плох.

Помню ещё в прошлом веке в ранние версии форумов ikonboard вставляли [img]file:///c:/con/con[/img], роняя ОС бедолагам с Windows 98, которые заходили в тему. Ничего в мире не меняется...

HotSpot всегда входил в OpenJDK

Как обычно, напоминаю, что не все изменения сидят в JEP'ах. Особенно то что касается стандартной библиотеки. Добавлено много приятных мелочей. Коллекторы toUnmodifiableList/Map/Set, например. Или методы вроде List.copyOf, которые создают неизменяемую копию коллекции (или не создают, если на вход уже подан неизменяемый список).

Нагуглил Solhint, который что-то умеет. В частности, ругается на любое использование block.blockhash. Это, конечно, слишком глупо, но лучше чем ничего. И даже плагин к IDEA имеется.

Интересно, а для Solidity IDE со статическим анализатором ещё не придумали? Штуки вроде block.blockhash(block.number) бегут ловятся статически.

Обычно изменённый после рефакторинга код форматируется в соответствии с текущими настройками стиля. Даже если фрагмент исходного кода переиспользуется, и он изначально не соответствовал стилю, то он тоже переформатируется.

Ну так существенная часть моего патча состояла в том, чтобы определить, когда можно доверять значениям из массива, а когда нельзя. Собственно в dataflow может один вызов добавился. Визитор и вам написать пришлось, так что вы всё-таки что-то сделали специально ;-)

Заметку я читал, конечно, она тут совсем ни при чем. Отсутствие варнинга как раз ожидаемо. Откуда же dataflow знает про джавовые уровни доступа?

Ну, положим, вы кривите душой. Вам специально пришлось подрубать Spoon, генерировать JNI-обёртки с помощью Swig'а и чёрт знает что ещё. А вот давайте блэкбокс-тестирование проведём, мне интересно. Вот вам исходник A и исходник B. Сохраняются ли варнинги в этих случаях?

Arrays.asList-то ты не проверил.

Стандартная либа джавы — это огромное количество ОЧЕНЬ плохо, буквально на отстаньте написанного кода, который работает С ОГРОМНЫМИ затратами.

Здесь вы сильно драматизируете.


в виде конвейерных массивов, которые генерятся после КАЖДОЙ операции, будь то filter(), map() или что-то еще.

А это просто враньё.

и обойтись без перебора итератором.

Надо, кстати, проверить. Теоретически его итератор добили до состояния, когда он может удалиться полностью escape-анализом в плотном цикле.

в каких условиях интринсификация не срабатывает.

Ну так кури сорцы :D

Information

Rating
Does not participate
Location
Новосибирск, Новосибирская обл., Россия
Registered
Activity