lany
0

PyCharm плохо анализирует?

lany
0

Когда я просто прохожу мимо этого места мне как-то наплевать, есть там табуляция или нет, я просто мимо проходил. Как это может действительно отвлекать?

lany
0

Так я и говорю, что скачет влево-вправо. И на вашей гифке именно влево-вправо и скачет, а не только идёт вверх-вниз. Что вы мне хотите этим показать из того, что я ещё не сказал?

lany
0

Ага, можно ещё Advanced Code Folding поставить, вообще другой язык будет :-)

lany
–1

Как перемещение может быть удобнее? Вот у меня курсор стоит в <|footer> и я хочу его перевести в <|/footer>. Я нажимаю четыре раза кнопку вниз, а курсор начинает при этом ещё влево-вправо скакать, отвлекая меня от сути моего действия. Это удобно?

lany
+2
Программу, пережившую многих тут дискутирующих, оказывается на «лишь бы отработало, всё равно на выброс» писали.

Не вижу противоречия. В жизни часто так бывает.

lany
0

У всех скил разный, но о первом нельзя не знать, если вы видели хотя бы пару предыдущих статей в таком формате от PVS-Studio. Конечно, каждая статья может для кого-то оказаться первой.

lany
+1

Разумеется, вы заметили опечатку, перед вами же две строчки кода, а не проект из тысячи файлов, в одном из которых опечатка. Зачем же был введён ненужный оператор? :-) В дизайне языка самое главное — не решить, что в него добавлять, а решить, что в него добавлять не стоит. С этим, кстати, очень большая проблема у груви (@RockPresident привет). Грувисты всегда хвастаются тем, что у них есть, но не могут похвастаться тем, чего у них нету. Котлин гораздо лучше именно потому, что в нём меньше фич. И то несмотря на юный возраст Котлина, в нём уже есть лишние вещи.

lany
0

С этими равенствами, кстати, я уже в Котлине обжёгся.


if(type === TYPE_VARIABLE || type === TYPE_PARAMETER || type == TYPE_FUNCTION || 
   type === TYPE_METHOD || type === TYPE_FIELD) { ... }

Заметили опечатку? В джаве такая опечатка невозможна, а в Котлине/Цейлоне — легко (и я их видел в реальном коде).

lany
+1
Если у человека в резюме стоит экзотический язык, например Common Lisp — с вероятностью процентов 90 это весьма приличный разработчик.

Либо он учился на математическом факультете, где учат только лиспу, умеет доказывать теоремы, но к практическому программированию не готов :-)

lany
0

Почему-то все про 4, 5 и 8 говорят. По-моему, идеальный отступ — два пробела. Один можно не заметить в некоторых случаях, а два в глаза бросается и при этом драгоценное место на экране не тратится.

lany
+3

Эк заминусовали-то. Мне в целом интересно почитать, что ещё накопали, но в чём-то kravtsov_dim прав. Например, разделы про "The 'pScint' pointer was utilized before it was verified against nullptr" я пролистываю, потому что такое реально в каждой статье есть и в каждой программе с 10-15-летней историей можно отыскать подобное. Это скучно. Но есть интересные ошибки и особенности C++, о которых я не знал (потому что не пишу на нём). Например, про ловлю исключений по значению. Пара интересных ошибок — уже не зря статью прочитал :-)

lany
+1

А вот тепеееерь действительно можно говорить, что выход (скорее всего будет) отложен:
http://mail.openjdk.java.net/pipermail/jdk9-dev/2017-May/005864.html

lany
0

Мне нужна неограниченная поставка барбарисок в офисе. Когда кончаются, я грущу.

lany
+2

А что у вас в табличке всё как попало написано? Язык программирования Java пишется с большой буквы. CSV, XML — только большими буквами. Или JUnit, или по крайней мере junit, но никак не Junit. Правильно — IntelliJ IDEA, а не Intellij Idea. Я уж молчу про javasist вместо javassist. Понимаете, это не просто придирки. Если человек со всем этим каждый день работает, у него написание этих слов в подкорке отложилось, неправильный регистр ему сразу бьёт в глаза. Профессионал бы не сделал такую табличку. А так складывается ощущение, что как раз не нормальный разраб будет, а «долдон начитает книжку по Java».


Кстати, javassist же устарел морально. Почему не ByteBuddy, например?

lany
0

Таки почему «из так называемого pool»? Никто его так не называет. Это так называемый integer cache — кэш целых чисел. И в документации, и в исходниках это называется кэш.

lany
0

Главное чтобы ваша IDE помнила и предупреждала при случае :-)

lany
+2

Подозреваю, что вы value types за аллокацию на стеке приняли. В девятке их всё равно не будет. И аллокация на стеке ортогональна value-типам. Джава уже давно умеет не то что на стеке аллоцировать, а в регистры раскидывать объект вообще без аллокации. Или в принципе избавиться от объекта, если позволяет ситуация.

lany
0

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

lany
+2

А вот почему не стоит переходить. Компилятор до ума довели, вопросов нет. Но поддержка в IDE страдает. Каждый раз, когда я влезаю в Котлин, напарываюсь на какую-нибудь неприятность вроде этой. Тонна Java-инспекций в Котлине не работает, хотя имеет смысл, если активно используешь всякие Java API.

lany
+6

С аллокацией на стеке? Вы про что и кто это обещал? Что-то из разряда "слышал звон".

lany
+1
Если вижу в заголовке восклицательные знаки и надписи, что все сломалось и ничего не работает, ничего не запускается, то да, на такие вопросы стараюсь отвечать в первую очередь.

Лайфхак: хотите, чтобы на ваш запрос в саппорт быстрее ответили? Добавьте больше восклицательных знаков и в сабжекте напишите, что всё сломалось.

lany
0

Заметь, кстати, что аллокация гигабайта каждые три секунды замедлила программу всего на 2.5% (что вообще не превышает погрешность) по сравнению с программой без аллокаций. Этот комментарий для тех, кто кричит, что garbage collector'ы тормозят безбожно :-)

lany
0

У нас за 377 рублей на яндексе можно не менее 20 километров проехать. Если в москвах прожить нельзя, значит новосибирские таксисты в глубокий минус работают :-)

lany
+1

Новосибирские яндекс-таксисты ноют, что по 25% отдают. Может врут, конечно, я свечку не держал. Говорят, дальние поездки совсем не выгодны. Предпочитают договориться с пассажиром и закончить поездку досрочно, чтобы меньше отдавать.

lany
+4

Плюсанул статью авансом, но у меня к ней много придирок :-)


Во-первых, измерять такую системно-зависимую штуку явно стоит на разных ОС. И уж как минимум, упомянуть в статье, к какой ОС относятся результаты.


Во-вторых, вывод, что clock.instant() дороже, чем clockMicros, неверен. На графиках диапазон результатов с учётом рисок погрешности существенно пересекается, однозначно говорить о победе одного варианта над другим нельзя.


В-третьих, если хочется убедиться, что аллокаций не происходит (то есть escape-анализ работает), надо аллокации и измерять (например, через -prof:gc), а не по наносекундам делать косвенный вывод. Вполне возможно, что аллокация и происходит, просто tlab-аллокация очень быстрая (об этом ты сам говорил на JPoint), и разница не превышает погрешность. А GC тоже может работать очень быстро, так как выживших объектов вообще нет. Scavenger посещает только живые объекты от рутсета, которые попадают в то же поколение (определяется сравнением адреса с границами поколения). Как только все живые объекты (инфраструктура джавы и самого бенчмарка) запромотились на первой сборке, каждая последующая минорная сборка будет выкидывать весь Eden целиком, даже не пробегаясь по нему, а просто проверяя, что ни один объект из рутсета не указывает в Eden. Конечно, если голосовать вслепую, я всё же верю в escape-анализ здесь, но инженер не должен верить, а должен измерять :-)


Наконец, даже если ClockUTC.micros() выдал 1494398039238498, нельзя сделать вывод, что точность повысилась. Кто знает, может последние цифры просто рандомные или обновляются редко? Здесь полезен бенчмарк на гранулярность, который наш любимый Лёша делал несколько лет назад. Вот для nanotime на Windows у Алексея получаются интересные результаты. Хотя там не нолики на конце, но гранулярность вовсе не 1 нс, а где-то 370 нс. Подобная информация прекрасно дополнила бы эту статью. Вообще, конечно, раз проводишь исследование, стоит ознакомиться с предыдущими работами на эту тему, и Nanotrusting the Nanotime тут просто напрашивается быть номером один в литературном обзоре :-)

lany
0

В данном случае, если вы требуете конкретную сигнатуру, как раз лучше сделать инлайнинг, чем мутные аннотации:


inline BigInteger multiply(long x, long y) throws Throwable {
  return (BigInteger)Intrinsics.invokedynamic(MULT, "foo", x, y);
}

Однако часть рулезности invokedynamic ещё и в самой полиморфной сигнатуре. К примеру то самое, о чём я писал — если переданы два инта, то можно дополнительно оптимизировать, а здесь получится, что они сразу расширятся до лонгов.

lany
0

Ну методы с полиморфной сигнатурой уже существуют. Если разрешить определять такие пользовательские методы и инлайнить их во время компиляции, то можно как-то это решить. Понятно, что красивое решение придумать сложно. Но вот задача сообщества в том и состоит, чтобы придумывать красивые решения и продавливать их.

lany
0

Да, в текущем прототипе есть такая проблема. Но ведь никто не сказал, что так и будет всегда. Если есть идеи лучше, высказывайтесь в мейлинг-листе! От Intrinsics. уже сейчас легко избавиться статическим импортом. Я пытаюсь протолкнуть мысль, что BootstrapSpecifier может быть параметризован возвращаемым типом, и тогда удастся обойтись без каста, что уже полдела. Пока не проталкивается.

lany
0

Ну можно как минимум hardware performance counters заиспользовать, они стабильнее. Количество выполненных инструкций, например, считать. Хотя суперстабильности всё равно не будет. JIT-компилятор в Java, например, легко выдаст неустойчивый результат в зависимости от гонки между потоками. То есть гонка на ранней стадии работы программы повлияет на сгенерированный ассемблерный код, который будет с вами до конца работы программы и может дать вполне ощутимую разницу в производительности.


А тут ещё в IO многое упирается. На рамдиске наверняка будут существенно другие результаты. Поэтому замеры чисто процессорного времени непрактичны.

lany
0

О, DrJava. Забавная поделка, никогда не слышал о ней.

lany
+4

Почему же не были? В чём-то согласились с RedHat, в чём-то нашли компромисс. Какие-то вещи технически сложны и при этом могут быть реализованы в будущих версиях, поэтому их отложили. Какие-то вещи концептуально не подходят для JPMS.


Например, RedHat топит за циклические зависимости. Конечно, с точки зрения поддержки легаси-кода это может быть важно, но с точки зрения нормальной архитектуры — бред. Не можешь избавиться от циклов — не переходи на JPMS. Тут, я считаю, Марк правильно не прогибается. Вот pjBooms рассказывал в красках на JBreak, что не так с циклическими зависимостями в OSGi. Вроде бы они есть, но это хрупкий песчаный замок: порядок инициализации циклически-зависимых OSGi-модулей оказался зависим от неспецифицированных деталей реализации процесса загрузки классов в HotSpot. Приложения, которые хотят циклические зависимости, как правило, ещё и на этот порядок закладываются. Немного меняешь процесс загрузки классов в JVM (не нарушая спецификацию), и большие OSGi-приложения вроде Eclipse (привет IBM) дохнут, не успев запуститься. А другие большие приложения, но не OSGi (типа IntelliJ IDEA) продолжают работать. И если я правильно понял, в рамках спецификации OSGi проблема в принципе неразрешима. Если тащить циклические зависимости в JPMS, придётся тащить и эту проблему. Даже если предположить, что в JPMS протащат циклические зависимости, никто не будет реализовывать Jigsaw, чтобы он эмулировал в точности поведение OSGi. А значит, существующие OSGi-приложения всё равно развалятся и их всё равно придётся переделывать. А раз переделывать, то лучше и циклы выкорчевать, тогда порядок инициализации станет стабильным.

lany
+1

Потому что они высказались. По крайней мере RedHat высказывал конкретные претензии множество раз. Почитайте мейлинг-лист jpms-spec-observers. В первую очередь сообщения от Дэвида Ллойда и ответы от Марка. Там уже не первый год отнюдь не дружелюбное общение.

lany
+6

Из какой конкретно строки в оригинальной статье вы сделали вывод, что «Выход Java 9 — новой версии платформы — был отложен»? Что-то я не вижу этого в явном виде. Более того, статья написана неделю назад, задолго до конца голосования, когда исход был ещё неясен. Официально об откладывании Java 9 никто пока не объявил. Захотелось заголовок погромче сделать? :-)

lany
0

Каждое упоминание Intrinsics.invokedynamic вставляет инструкцию invokedynamic, а она уже сохраняет точку вызова, привязанную к конкретному месту в байткоде, что по большому счёту есть лениво инициализируемое статическое поле в этом классе.


MULT для удобства сделан, можно его заинлайнить в точки использования, эффект будет тот же, только ещё больше энтерпрайза.

lany
0

Ну так напиши в мейлинг-лист о своём наболевшем :-) Как я понимаю, AOT-компиляция Oracle тоже интересует.

lany
+5

Ещё есть волшебный ключик --permit-illegal-access.

lany
+3

Если вы мыслите в масштабах Вселенной, вас больно укусит теория относительности, ещё до машин времени. Абсолютной шкалы времени в принципе нет, и с этим надо жить.

lany
+1

Альтернативный вариант:


if(x == NULL) { ... }
else {
  assert(x != NULL);
  ...
}

Так вы и документировали вторую ветку (на случай если первая разрастётся), и добавили отладочную проверку. Можно бы было ещё так:


if(x == NULL) { ... }
else {
  assert(x != NULL); // PVS-Studio: static assert
  ...
}

Комментарий специального вида после ассерта должен указывать, что PVS-Studio в состоянии статически вывести, что этот ассерт всегда истинный. Если со временем окажется, что это не так (например, условие в верхнем if поменяется, а про else все забудут), то PVS-Studio начнёт ругаться, что больше не может вывести истинность утверждения, помеченного комментарием.

lany
+2

Нет-нет, я не с целью поддеть вас, у меня исключительно профессиональный интерес ;-)