В Java, как известно, inline-методов нет. Но такое понятие существует в других языках, исполняющихся на JVM. Например, в Scala или Kotlin. Во время компиляции вызов такого метода заменяется на его тело, как если бы разработчик написал этот код вручную.

Прекрасный инструмент для добавления синтаксического сахара и создания проблемно-ориентированных языков (DSL) малой ценой, но как это всё отлаживать?

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

Как-то раз мне понадобилось несколько наборов строк с коллизией по хеш-коду. То есть таких, чтобы значение String::hashCode() совпадало для всех строк в наборе.

Блуждание по интернету не дало результатов, примеров было мало и все они довольно однообразны. Поиск по словарям подарил забавную пару "javascript's".hashCode() == "monocle".hashCode(), но практической пользы не принёс. Полный перебор не рассматривался в виду скорой тепловой смерти вселенной.

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

Вопрос в стиле головоломок с offline-конференций: Что выведет этот код при запуске?

import java.util.concurrent.atomic.AtomicInteger;

public class Disturbed {

    public static void main(String... args) {
        AtomicInteger counter = new AtomicInteger(1);
        System.out.println(
            "First two positive numbers: " +
            counter + 
            ", " +
            counter.incrementAndGet()
        );
    }

}

Помедитируйте немного над кодом и приходите за ответом под кат.

Счётчик новых комментариев — очень удобная вещь, особенно для статей с оживлённой дискуссией.

Но он не идеален:

Случайно обновив страницу или закрыв вкладку мы теряем информацию о непрочитанных комментариях. Тратить время на ручной поиск новых комментариев вряд ли кто-то согласится.

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

Часть первая, теоретическая | Часть вторая, практическая

---

Продолжаем поиск максимального возможного количества значений в перечислении.
На этот раз сосредоточимся на практической стороне вопроса и посмотрим, как на наши достижения будут реагировать IDE, компилятор и JVM.

Часть первая, теоретическая | Часть вторая, практическая

---

По мотивам твита от Evgeny Mandrikov aka godin:


В нём он задаётся вопросом, какое максимальное количество значений может быть определено в перечислении (enum) в Java. После ряда экспериментов и применения чёрной магии ConstantDynamic (JEP 309) автор вопроса приходит к числу 8191.

В серии из двух статей поищем теоретические пределы числа элементов в перечислении, попробуем к ним приблизиться на практике и попутно выясним, чем может помочь JEP 309.

ZeroNights 2017 Crackme №3 — довольно простое задание, но, тем не менее, и в нём есть несколько интересных моментов и сова.

Под катом — дизассемблирование, декомпиляция, pull request в IntelliJ IDEA и ни единого запуска отладчика.