• Научиться программировать становится сложнее
    0
    Если бы разработкой софта занимались квалифицированные математики

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

  • Знаковый символ: iOS denial of service
    +1

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

  • Первый релиз-кандидат OpenJDK 10!
    0

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

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

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

  • Предсказание случайных чисел в умных контрактах Ethereum
    0

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

  • JavaParser. Корёжим код легко и непринуждённо
    +1

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

  • 31 февраля
    0

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

  • 31 февраля
    0

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

  • 31 февраля
    0

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

  • Даже в Java 9 ArrayList всё ещё можно (и нужно) улучшать
    0

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

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

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


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

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

  • Даже в Java 9 ArrayList всё ещё можно (и нужно) улучшать
    0
    и обойтись без перебора итератором.

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

  • Даже в Java 9 ArrayList всё ещё можно (и нужно) улучшать
    0
    в каких условиях интринсификация не срабатывает.

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

  • Даже в Java 9 ArrayList всё ещё можно (и нужно) улучшать
  • Даже в Java 9 ArrayList всё ещё можно (и нужно) улучшать
    +1

    Кстати, пометка HotSpotIntrinsicCandidate не означает, что это на самом деле интринсик, и уж точно не «позволяет ВМ создавать для них высокопроизводительный машинный код». Чтобы сделать интринсик одной пометки мало. И помечено существенно больше методов, чем на самом деле интринсиков (на то оно и «candidate»). Поэтому закладываться на это не стоит.


    Кстати, можно ещё приложиться к Arrays.asList. Там вроде SubList вообще специально не реализован, а мог бы быть.

  • Даже в Java 9 ArrayList всё ещё можно (и нужно) улучшать
    +4

    А-а-а, ты везде!!! Приходишь на работу — там новые фичареквесты от тебя. Идёшь почитать, что в джаве делается, а там письма от тебя в мейлинг-листе. Хочешь передохнуть, заглядываешь на Хабр, и тут ты!!!

  • Статический анализ и property-based тестирование: вместе мы сила
    +2

    Ну сами они волшебным образом не заработают, конечно. Но я бы не сказал, что прямо всех инспекций. Вот с лямбдами до сих пор попадаются недоработки. Например, раньше если в поддереве искался return, то только классы надо было игнорировать, а теперь ещё и лямбды. Некоторые инспекции могут быть не обновлены и принять return внутри лямбды за выход из неё. Хотя их уже мало осталось. А есть способ лучше?

  • Java с ассемблерными вставками
    +5

    Странно, что здесь не упоминается ни JNR, ни тем более JNR-x86asm, а ведь это неплохое решение, которое уже работает. А ещё стоит покопать в проект Panama, Володю Иванова потыкать. Они там тоже ассемблер прямо в джаве пишут, причём почти без накладных расходов на переход туда и обратно.

  • Статический анализ и property-based тестирование: вместе мы сила
    +1

    Да, эта будет только для джавы. Кросс-языковые инспекции (Java-Kotlin) есть, но пока очень мало. Там же не только синтаксис, но и семантика существенно различна. Например, в Java мы всегда считаем, что плюс не создаст побочных эффектов (строго говоря, может, если вызовется странный toString), а в Котлине плюс может быть перегружен. Тонкостей множество даже между такими близкими языками.

  • Статический анализ и property-based тестирование: вместе мы сила
    +3

    Я пока не особо оценил Котлин. Кроме того, я занимаюсь поддержкой языка Java, поэтому для догфудинга разумно самому писать на этом же языке.

  • Объект в футляре или Optional в Java 8 и Java 9. Часть 2: «Как это делается в Java 8»
    0

    Да, на мой взгляд проще понять ー Optional без всяких аналогий, чем вникнуть в эту уйму объектов и взаимодействий между ними…

  • Объект в футляре или Optional в Java 8 и Java 9. Часть 1: «Как без него прожить?»
    0

    Про Optional уже были статьи на Хабре. Например, вот постарее или вот совсем недавно. Когда пишете новую статью, полезно хотя бы себе самому ответить, что она добавит к уже существующим статьям, а в чём повторится.

  • Optional: Кот Шрёдингера в Java 8
    0

    Не совсем красиво я выразился, пожалуй. Нулевые функции — это читерство, а вот функции, принимающие или возвращающие null — вполне законны. Очевидно, что flatMap должно соответствовать операции bind. Вопрос: какая операция соответствует операции return? Предположим, что Optional.ofNullable. Тогда f = Optional::of нарушает закон (return v) >>= f ≡ f v для v = null. В терминах Java слева Optional.ofNullable(null).flatMap(f) => empty(), а вот f.apply(null) — NPE. Ладно, предположим, что return — это Optional.of. Тогда возьмём f = Optional::ofNullable и снова получим несоответствие.


    Более интересные эффекты проявляются с операцией map (аналог хаскеловского fmap). Пусть есть две функции:


    UnaryOperator<Object> f = x -> null;
    UnaryOperator<Object> g = x -> "foo";

    Возьмём произвольный непустой Optional opt. Композиция fmap подразумевает, что opt.map(f).map(g) эквивалентно opt.map(g.compose(f)), а это не так: первый — это всегда empty, а второй — это Optional.of("foo").

  • Chromium: шестая проверка проекта и 250 багов
    0
    Флаг truncated должен быть равен true, если текст слишком длинный, то есть если выполняется условие if (len > kMaxShortPrintLength).

    Я это понял, глядя глазами в код в течение минуты. Но ведь наверняка у вас на условии if (len > kMaxShortPrintLength) есть ещё одна сработка вроде "expression 'len > kMaxShortPrintLength' is always false". Разве нет? Если так, то сразу становится очевидно, что вторая сработка — следствие первой, надо просто в каждом методе смотреть предупреждения по порядку.

  • Я смоделировал цену биткойна за весь 2018 год. Вы не поверите в результат (прим. перевод. и будете правы)
    +1
    Потому что всегда есть риск переобучения, даже ненарочный. К примеру, вы придумали алгоритмы A, B, C, D. Обучили их все на данных 2016 года и проверили на данных 2017. A, B, C не сработали, а D показал какую-то корреляцию. Вы идёте и рекламируете всем алгоритм D, говорите, что он хорошо предсказывает. Хотя на самом деле в выборке из достаточно большого количества случайных алгоритмов всегда найдётся такой, который при обучении на данных 2016-го года продемонстрирует с данными 2017-го года корреляцию не хуже некоторой наперёд заданной. Вот надо оценить, при создании этого алгоритма сколько вы алгоритмов перепробовали (если к примеру, вы варьировали некоторый настроечный параметр алгоритма, то каждое значение настроечного параметра — это по сути новый алгоритм). Если вы в процессе создания предсказывающего алгоритма перебрали на порядки меньше алгоритмов, чем требуется по теории вероятности, чтобы случайно предсказать результат, то, возможно, ваш алгоритм не полное фуфло. К сожалению, не каждый учёный делает такие выводы. Не каждый вообще фиксирует все свои ошибочные шаги и несработавшие идеи, а без этого не оценишь шансы переобучения. Ведь если бы любая из несработавших идей случайно сработала, вы бы на ней остановились, поэтому их наличие повлияло на результат.
  • Как новичку сделать вклад в open source проект с 20К звездами?
    +1
    Количество стразиков в профиле проекта тут совершенно роли не играет.

    Думаю, количество звёзд коррелирует с забюрократизированностью проекта.

  • Пылесосим код IDEA Ultimate с помощью анализа потоков данных
    0
    Честно говоря, я больше опасался комментариев вроде «У… да ваша IDEA — глюкавище, как можно было такие баги допустить».
  • Пылесосим код IDEA Ultimate с помощью анализа потоков данных
    +2

    https://www.jetbrains.com/help/idea/running-inspections-offline.html


    А если у вас правильный CI, то всё будет работать из коробки :-)

  • Как новичку сделать вклад в open source проект с 20К звездами?
    0
    В проектах где много открытых тикетов и авторы сами заинтересованы в новых контрибьюторах, обычно есть какой-нибудь специальный тэг на тикетах типа «good first issue» — несложная вещь, до которой просто руки не дошли, но новичок вполне может с ней справиться.

    Но помните, что не все проекты вообще заинтересованы в новых контрибьюторах.
  • Как новичку сделать вклад в open source проект с 20К звездами?
    0
    Вы меня неправильно поняли. Опечатка в интерфейсе — это «действительно баг». А использование в коде одной конструкции вместо другой, которая такой же длины, такой же понятности и, вероятно, даёт исчезающе малый прирост производительности, — это косметика. Я про косметику в коде, а не в том как приложение выглядит для пользователя.
  • Пылесосим код IDEA Ultimate с помощью анализа потоков данных
    0

    Да, со скриншотами не очень получилось. Шрифт явно не подходящий. В следующий раз учту :-)

  • Пылесосим код IDEA Ultimate с помощью анализа потоков данных
    0

    Если метод статический, скорее всего контракт сам выведется. Посмотрите по ctrl+q.

  • Пылесосим код IDEA Ultimate с помощью анализа потоков данных
    0

    Есть контракты, но они довольно ограничены. Здесь можно написать @Contract("null -> false"), и это будет учитываться. А вот информация о длине массива во внешний метод не попадёт.

  • Пылесосим код IDEA Ultimate с помощью анализа потоков данных
    +2

    Не распознают люди сарказм, вот и минусуют, прости их :-)

  • Как новичку сделать вклад в open source проект с 20К звездами?
    +1

    Мелочи жизни, так тоже можно писать. Главное чтобы "'" не превратилось в ''' :D

  • Как новичку сделать вклад в open source проект с 20К звездами?
    0

    В наши дни особо пачкаться не стоит. Оба вызова интринсифицируются, для обоих есть специальный узел в IR. Я бы не заморачивался возможными различиями в производительности.


    Надо помнить, что у такого pull-requesta есть и минусы. Например, засоряется история коммитов, усложняется git blame. Автоматизированные системы, которые назначают ответственного за исключение или предлагают ревьювера для кода, могут предложить человека, который внёс такую косметическую правку, а не реального автора кода.

  • Как новичку сделать вклад в open source проект с 20К звездами?
    +4

    Я всё же стараюсь не лезть в новый проект с косметикой, а найти действительно баги. Статический анализ тут тоже помогает. Вот, например, мой pull-request в JIT-компилятор Graal. Признаюсь, я даже не собрал его, когда закидывал пулл-реквест. Там своя доморощенная система сборки, никакой maven/gradle/ant/etc., которая к тому же плохо работала под виндой, её тоже чинить пришлось.

  • Optional: Кот Шрёдингера в Java 8
    0

    Уже третье ложное утверждение в комментариях к этой теме:


    в том что Optional является монадой

    Нет, java.util.Optional не является монадой, так как не соблюдает композицию байндинга (смотрите законы монад).

  • Optional: Кот Шрёдингера в Java 8
    0

    Кстати, в исходниках нашего проекта 116 вхождений ofNullable и 46 вхождений of. В общем-то of тоже нужен частенько.