• Все о String.intern()
    +2

    Если кто забредёт сюда, не читайте этот бред выше, который я восемь лет назад написал. Был маленький, глупый.

  • Мифы о кэше процессора, в которые верят программисты
    +1
    если два разных потока в любом месте системы читают с одного и того же адреса памяти, то они никогда не должны одновременно считывать разные значения.

    Что-то после слова "одновременно" возникли сомнения в квалификации автора. Во многопоточной среде понятие одновременности довольно расплывчато и вообще не нужно.

  • Проверка исходного кода свободного графического редактора Krita 4.0
    0

    Интересно, а если метод виртуальный, вы делаете выводы, что у него нет побочных эффектов на основании реализации? Или смотрите всех доступных наследников? Что если анализируется код библиотеки и предполагается наличие наследников вне зоны видимости анализатора?

  • Характер Kotlin
    0

    Конкретно это и в джаве работает. Корутины для этого не нужны.

  • Характер Kotlin
    0

    Есть вариант с asSequence, если вас это не устраивает. Впрочем, он особо не отличается от Java Stream API.

  • IntelliJ IDEA 2018.1 — улучшенный анализ кода, поддержка частичных коммитов Git, Android Studio 3.0 и многое другое
    +2

    Покажите конкретный пример

  • Полный перечень intrinsic-функций в HotSpot в JDK 7, 8, 9 и 10
    +1

    О да, насчёт fillInStackTrace совсем не удивлён. Нам его тоже приходится специально обрабатывать, например, при выводе чистоты методов по байткоду. Слишком уж он вездесущ, чтобы его просто проигнорировать.

  • Изменения в стандартной библиотеке Java 10
    +1

    Вы, наверно, давно учились. Это же обычный паттерн-матчинг, просто в Java пока нет синтаксиса для него. Оптимизация частного случая конкретной реализации без изменения семантики — прекрасное применение instanceof. Альтернатива — паттерн visitor, который сегодня уже кажется бойлерплейтом.

  • Java 10 General Availability
    +2

    javah из старых версий не съест скомпилированный в новую версию класс. Впрочем, Котлин пока новее восьмёрки версии не выдаёт. Таргетить на 9-10 Котлину, наверно, смысла и нет. А вот если в 11 нестмейты выкатят, Котлин от этого выиграет.

  • Java 10 General Availability
    +2

    И валидацию параметров конструктора ломбок прикрутит? Если у меня class Range { private final int from, to; } и инвариант from <= to, куда мне инвариант впихнуть?

  • Java 10 General Availability
    +1
    Можно! Главное — головой думать, когда программируешь, а не фэншуем заниматься.
  • Java 10 General Availability
    +2
    Парсинг версии пофиксали.
  • Java 10 General Availability
    +2
    Блин, а я публичные поля оставляю просто.
  • Java 10 General Availability
    +1

    Хотя, конечно, вру. "Some initial work on supporting JDK10" звучит совсем неубедительно.

  • Java 10 General Availability
    +2

    На самом деле проапдейтили, даже в CHANGELOG написали, только поленились выпустить свежую версию почему-то. А вообще ты донат занёс людям или только требовать умеешь? ;-)

  • Текущая разработка Kotlin
    +1

    Вот на совести разработчика — это сделает язык дырявым. Простой пример:


    fun test() {
        val x: String
        run { x = "Hello" }
        println(x.length)
    }
    
    fun <R> run(block: () -> R): Unit {
        contract {
            callsInPlace(block, EXACTLY_ONCE)
        }
        //return block() бугагашечка
    }

    В результате, если мы поверили контракту, но не проверили его, то в методе test() мы получаем обращение к неинициализированной локальной переменной — то, чего, например, в Java не может быть никогда и ни за что.


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

  • Текущая разработка Kotlin
    0
    Они не стопроцентно работают, их можно обмануть.
  • Java 10 General Availability
    +3
    Так нечего было им пользоваться :-) Понятно, что такие шибко хакерские вещи, которые прямо скажем ломают джаву изнутри, сами очень хрупкие.
  • Java 10 General Availability
    +2
    потому что на стабильной 2017.3.5 не поддерживается этот language level.

    Если я правильно помню, там был более хитрый алгоритм: надо просто написать var x = "foo", а когда подсветит красным, там есть квик-фикс на нём. Так-то в 2017.3 у нас уже всё работало. Но вообще да, проще на 2018.1 уже перейти.

  • Текущая разработка Kotlin
    0

    Интересно, а компилятор проверит, что обещания контракта метод действительно выполняет или примет их на веру?

  • Редактор TECO: EMACS, я твой отец
    0
    TECO сам себе IDE! Можно прямо в нём писать TECO-программы, тут же выполнять и отлаживать, не выходя наружу и не запуская внешние процессы.
  • Вредный Кейворд «Interface»
    0

    Если в контракте написано, что "метод add добавляет элемент, а метод addAll добавляет все элементы", то базовый класс волен поменять реализацию и использовать, либо не использовать add внутри addAll, этим он контракт не нарушает.

  • Вредный Кейворд «Interface»
    –1
    Нарушил контракт наследник: переопределил метод, делая помимо добавления элемента дополнительную логику, не предусмотренную контрактом (оповещение слушателей).
  • Редактор TECO: EMACS, я твой отец
    +1
    Как-то совершенно случайно получилось, что древняя виртуалка с Кубунтой была под рукой. Так-то я вообще виндузятник :D
  • Разбор перформансных задач с JBreak (часть 2)
    +1
    Я думаю, какой-нибудь jlink проще научить обновлять байткод в таких ситуациях. Все же пользуются jlink начиная с Java 9 ;-)
  • Вредный Кейворд «Interface»
    +2
    Не все клиенты вашего класса могут быть вам доступны. А если доступны все и всегда (у вас не библиотека, а приложение, которое не подразумевает сторонних плагинов), то необходимость выделения виджета без нотификаций вызывает ещё больше вопросов. Ключевой принцип ООП — инкапсуляция. В том числе она означает, что пока существующий класс сохраняет свой контракт, приложение не должно ломаться. Добавление нового метода или изменение реализации addAll через add не изменяет существующий контракт, но ломает приложение.
  • Разбор перформансных задач с JBreak (часть 2)
    0
    Ну так потому что уже особо не надо: JEP-280 срабатывает в подавляющем большинстве случаев (кроме модуля java.base и вручную написанных StringBuilder'ов). По сути дела и существующую оптимизацию если удалить, сильно хуже не станет.
  • Вредный Кейворд «Interface»
    +3

    Самое интересное, что в MyObservableWidget вы должны будете переопределить все методы MyWidget, изменяющие состояние, чтобы вызвать в них notify(). При этом вы попадаете на жёсткую зависимость от реализации MyWidget. При добавлении нового метода в MyWidget, который изменяет состояние, вам придётся изменять MyObservableWidget, иначе ничего вас не спасёт от багов. А если метод вроде addAll вместо ручной реализации в новой версии начнёт в цикле вызывать add, вы пришлёте миллион эвентов вместо одного (либо обратное произойдёт, тогда вы в новой версии вообще не пришлёте эвент). В этой ситуации невозможность множественного наследования и необходимость вручную делегировать пару методов к какому-нибудь подобию javax.swing.event.EventListenerList — это наименьшая из ваших проблем. Я считаю, если вы не используете аспекты или что-то аналогичное (а я совсем не призываю их использовать), то вы не сможете сделать изменяемую структуру данных отдельно от нотификаций, а потом прикрутить нотификации в дочернем классе. Вообще наследование конкретных классов плохо пахнет. Если вам при этом приходится переопределить реализацию N методов (например, "все методы, которые изменяют состояние"), вы точно ищете себе проблемы. На это напоролся, например, EclipseLink, который расширил ArrayList, переопределив все методы, а в Java 8 — сюрприз — появились новые методы.

  • Разбор перформансных задач с JBreak (часть 2)
    0
    И вот тут-то JIT-компилятор может хорошо покуражиться

    JIT-то тут при чём? Основную работу делает собственно фабрика, генерируя цепочку методхэндлов, которые сперва считают суммарную длину всех строк, затем выделяют один массив точно нужного размера и всовывают его в строку через небезопасный конструктор.

  • Производительность и рантаймы на конференции JPoint 2018
    +3
    Ёлки, что-то столько классных докладов заявлено, разрываться придётся…
  • Алексей Рагозин о Java Mission Control на jug.msk.ru
    +1
    Я один заметил, что на титульном слайде не весь экран опечатка — hitchKiker вместо hitchhiker? Если да, то мне приз!
  • Хардкорные Java/JVM задачки
    +3

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

  • Хардкорные Java/JVM задачки
    +1
    Ну да, через bootstrap можно и java.lang.Class подменить, тогда все четыре варианта будут возможны :D
  • Хардкорные Java/JVM задачки
    +4

    В четвёртой задаче я рассуждал, что ничего не мешает создать свой класс class java.lang.Integer implements Iterable и загрузить кастомным класслоадером. Ну или в bootstrap classpath подсунуть. Нет?

  • Почему GitHub не поможет нанять разработчика
    +1
    Я бы в резюме явно написал «контрибутил в такие-то и такие-то проекты, список моих коммитов в этих проектах вот по ссылке». Разумеется, выбрав только наиболее значительные и релевантные планируемому месту работы, чтобы сэкономить время потенциальному работодателю.
  • Задача про forEach(ps::println) от СКБ Контур
    +5
    Вы думаете, обычный AOT-компилятор вам будет выдавать код одинаковой производительности на разный профиль? Вы компилируете с использованием рантайм-профиля?
  • Задача про forEach(ps::println) от СКБ Контур
    0
    > И, кстати, в вызов метода checkIndex передавать надо, наверное, index:

    Да, спасибо.

    > почти двукратное «торможение» параллельных стримов

    970 против 806 — это почти двукратное? У вас одна итерация существенно быстрее. Явно процессор другой. Возможно, с улучшенной хардварной поддержкой криптографии. Можно усложнить функцию и посмотреть, что получится. Ну и количество ядер хотя бы указывайте. Вряд ли меньше четырёх, но мало ли.
  • Мозаика в ванной и диофантовы уравнения
    0

    Звучит разумно, спасибо за комментарий!

  • Мозаика в ванной и диофантовы уравнения
    +1

    В задаче с окантовкой ширины в одну клетку (и вообще фиксированной ширины) такие тройки не подойдут. А разбирая более общую задачу я это ниже отметил:


    Кстати, как и с пифагоровыми тройками, в нашей задаче любое количество кратных решений.
  • Мозаика в ванной и диофантовы уравнения
    +2
    Проблема ещё в том, что я и не математик вовсе. Поэтому с большой вероятностью всё что я придумываю в математике — это велосипеды. Но как гимнастика для мозгов вполне годится.