#prog #abnormalprogramming #java

Как заставить в Java 2 + 2 быть равным 5.

codegolf.stackexchange.com/questions/28786/write-a-program-that-makes-2-2-5/28818#28818

#prog #article #java

Статья о маленьких оптимизациях в Java (и в стандартной библиотеке, и в JVM). Статья интересная сама по себе, но я хочу обратить ваше внимание на проблемы в computeIfAbsent и removeIf, связанные с неограниченным алиасингом указателей.

#prog #java #quotes

#prog #java

AbstractSingletonProxyFactoryBean

Шутка ООП-хейтера? Отнюдь, суровая реальность Spring.

#prog #java

#prog #article

Системы типов #java и #scala являются unsound. Подробности в статье.

TL;DR:
Программа определяет тип class Constrain<A, B extends A> {} и метод upcast:

static class Bind<A> {
<B extends A>
A upcast(Constrain<A,B> constrain, B b) {
return b;
}
}

Этот метод просто апкастит значение типа B в значение типа A, используя значение типа Constrain<A, B> как материальное свидетельство того, что B действительно является подтипом A. К сожалению, ничто не мешает в качестве значения этого типа использовать null, что ломает логику системы типов, которая полагается на этот факт, а использования wildcard capture позволяет при помощи Constrain установить отношение субтипизации между двумя произвольным типами. Результат? Комбинация null-гого Constrain и upcast позволяет перевести значение любого типа в значение любого типа. Фактически — аналог std::mem::transmute, но без каких либо небезопасных фич и с корректно типизированным кодом.

И эта ошибка оставалась незамеченной 12 лет. А кто-то ещё говорит, что null — хорошая идея.

#prog #java

Немного о том, что это означает для рядовых программистов и почему это важно.

#prog #java #kotlin #scala #article

Well-Typed Programs Can Go Wrong: A Study of Typing-Related Bugs in JVM Compilers

В этой статье авторы отмечают, что усилия в тестировании компиляторов в основном направлены на отлов некорректных оптимизаций, при этом мало кто целенаправленно занимается отловом багов в фронтендах. Авторы выбрали 320 багов, связанных с типами, среди багов компиляторов Java, Scala, Kotlin и Groovy, и разобрались с тем, как они себя проявляют, какие фичи языка используют и как они фиксятся. Вооружившись этим знанием, они написали генератор тестовых программ, который смог найти 28 багов, из них 12 были новыми (то есть для них исправлений не было).

А ещё авторы отличились тем, что нормально выложили материалы по исследованию.

#prog #java #article

Java’s Checked Exceptions Are Just Weird Union Types

(thanks @oleg_log)

#prog #rust #cpp #java #article

A Rust Gem: The Rust Map API

#prog #java #article

Как мы запустили программу на Java без JavaVM, или немного про практический опыт применения GraalVM native image.

(thanks @bapho_bush)

#prog #java #python #article

Ладно бы система типов Java полна по Тьюрингу. Оказывается, к системе типов, задаваемых аннотациями типов Python, это тоже относится!

#prog #java #meme

#prog #abnormalprogramming #java #article

Сказка о типизации

#prog #java #go #meme

Source

#prog #rust #java #article

How We Migrated Our Static Analyzer From Java To Rust

Меня, правда, смущает, что правила анализа почему-то написаны на JavaScript.

<...>

We observed that the migration tripled our performance and resulted in a tenfold reduction in memory usage, <...>

To our surprise, we gained a firm grasp of the language and a clear idea of how our codebase would be mapped onto Rust within 10 days. <...> Within a month, the entire code analysis infrastructure was migrated from Java to Rust, and all customers were running on the new Rust analyzer.

<...>

Removing our dependency on the JVM and speeding up the analysis enabled us to embed the analyzer directly into the IDE. The very same lightweight and fast analyzer that runs in your CI/CD pipelines simultaneously reports coding errors and suggests fixes in your IDE in real time, <...>

#prog #go #java #article

NilAway: Practical Nil Panic Detection for Go

Инструмент для статического анализа кода на Go для обнаружения потенциальных разыменований nil-указателей. В отличие от прочих решений, решающих эту проблему, NilAway быстр, анализирует код между функциями (и даже между пакетами) и поддерживает инкрементальный анализ. При всём этом он не требует никаких аннотаций в коде.

А ранее Uber сделали аналогичный инструмент для Java, NullAway.

#prog #java #meme

#prog #java #article

3,200% CPU Utilization

TL;DR: несинхронизированный доступ к TreeMap привёл к тому, что связи между её внутренними узлами, которые обычно имеют древовидную структуру, образовали цикл, из-за чего треды зависали во время лукапа.

Автору также удалось воспроизвести этот спецэффект в C++ и в Go.

#prog

Для #java есть JEP 401: Value Classes and Objects (Preview). Value-объекты в данном случае — это объекты, у которых отсутствует идентичность. Это полезно, поскольку для многих классов, которые просто объединяют несколько полей вместе для удобства (например, LocalDateTime, или условной Point в графическом движке), наличие идентичности, отличной от совокупности значений, не имеет большого смысла.

На практике идентичность у объектов Java существует из-за того, что под них выделяется память в куче и, соответственно, у них есть уникальный адрес. Отсутствие такой идентичности позволяет генерировать более разумную реализацию оператора ==, а также делать то, что в JEP называется "heap flattening": изменение представление объекта, ссылки на который вместо хранения адреса выделенной памяти хранят значения полей объекта.

Всё это звучит хорошо, но, к сожалению, данная идея страдает от существующих элементов дизайна Java.

Первая — это повальная нуллабельность. Даже value-классы должны иметь возможность быть null, и это означает, что даже для сжатого представления один бит в ссылке должен отводиться под null-флаг. Как пишут сами авторы, массив из Integer, например, может хранить значения прямо в ссылках, но так как численные значения Integer занимают 32 бита и ещё один бит должен отводиться под null-флаг, на практике значения элементов массива будут занимать минимум по 64 бита. Это всё ещё выигрыш по сравнению с тем, что есть сейчас, поскольку это позволяет избежать индирекции на указателях и выделения 64 бита на заголовок каждого объекта в куче, но это всё ещё расточительно. Авторы явно признают эту проблему, и в разделе про дальнейшую работу есть ссылка на Null-restricted value class types JEP, но это пока лишь черновик.

Вторая проблема (которая, справедливости ради, была неочевидна индустрии на момент создания Java) — это отсутствие отслеживания алиасинга/перекрытия ссылок. В JEP авторы пишут:

Heap flattening must maintain the integrity of data. A flattened reference must always be read and written atomically, or it could become corrupted. On common platforms, this limits the size of most flattened references to no more than 64 bits.

Иными словами, выгоды от избегания аллокаций коснуться только очень маленьких объектов — особенно с учётом обязательного null-флага и паддинга под него. Но тут вообще стоит задать вопрос: зачем в принципе стоит требование атомарности обновлений ссылок? Атомарность нужна для того, чтобы избежать разрыва значений при одновременных обновлениях. Соответственно, если одновременных доступов нет, атомарность не требуется! Если бы в Java был механизм, который позволяет удостоверять, что доступ к значению уникален и остаётся уникальным в течение всего времени, пока значение остаётся достижимым (по крайней мере, для записи — многопоточное чтение безопасно и без атомарных операций), можно было бы использовать неатомарные операции для обновлений и избежать таким образом ограничений на размеры value-объектов. Можно считать это ещё одним примером к Fixing the next 10000 aliasing bugs, где инвариантом выступает целостность данных, и плюсом в копилку преимуществ отслеживания алиасинга для различных языков программирования.