Есть две функции

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

Однострочный калькулятор, искусство или порок?

Вы невнимательно читали условие, это решение вообще без строк.

всего 1 строку, т.е. всего 1у точку с запятой не считая пакеты и импорты

Разговор про Java 9 с Иваном Крыловым на jug.msk.ru

Ура, ура! Спасибо.

Разработка JDK 9 прошла фазу «Feature Complete»

Нифига. Модули про другое.

Разговор про Java 9 с Иваном Крыловым на jug.msk.ru

Все еще не вижу там этого доклада. Это я слепой или действительно не выложен?

DSL для регулярных выражений на Kotlin

Это да, потому и не стал цитировать пункт целиком. Более того, я боюсь что в этой войне его вообще не победить. Максимум, что можно было бы сделать (да и то хз как) — запретить форматировать конкретный кусок. Но, на мой взгляд, вторая проблема (динамический запрос) даже хуже.

А у вас хорошо получилось, статическая типизация — наше всё.

DSL для регулярных выражений на Kotlin

да и банальной проверки соответствия открывающих и закрывающих элементов нет, можно написать лишний .end();

Так можно же проверку сделать! Так что и лишний не напишешь, и не лишний не забудешь.

Как не писать лишнего

А по поводу питона — на мой взгляд убирание убирание инкапсуляции из языка — минус, а не плюс.

Как не писать лишнего

Поймите правильно, я не говорю что вы сделали какое-то говно. На самом деле, для самообразовательных/развлекательных целей это интересная штука. Я спорю лишь с тем, что jeta для практического использования чем-то лучше lombok. В силу ограничений, накладываемых выбором технологии (генерация новых исходников вместо модификации байткода имеющихся классов).

Как не писать лишнего

Похоже на какой то boiler-plate code, который вы не хотите видить в своих исходниках. Тогда Jeta это то, о чем вы всегда мечтали.

Да, конечно же все ради избавления от бойлерплейта. Только вот Jeta, в отличии от Lombok, не избавляет меня от бойлерплейта, а просто меняет его.

Вам вообще не будет дела что и как там генерится.

Я про другое. Вопрос в том, какие классы/методы предлагает мне идея при комплишене. И, если я напишу вызов метода руками, считает ли она что такого метода нет и надо выделить его красным. В вашем варианте сразу после того, как я поставил аннотацию, идея не начнет автоматически видеть новый метод (он ведь еще не сгенерирован). Сначала надо сделать билд.

Как не писать лишнего

избавляет от копи-пасты строки типа

Отвратительный пример. Никто никогда не копипастит логгер. В идее с помощью smart completion данная строчка пишется значительно быстрее чем "найти класс, из которого копипастить; скопировать; вернуться в исходный класс; вставить; заменить класс внутри getLogger". А на самом деле, если потратить 5 минут времени, то можно написать live template и после этого объявлять логгер как "logger<TAB>". Так что в данном конкретном примере ваше решение только все переусложняет.

Как не писать лишнего

Ага, 3 из 4 вопросов — это один и тот же "как оно работает?". У людей, не знакомых с annotation processing, этот же вопрос будет и про вашу либу. Менять байткод или генерить сорцы — уже следующий вопрос. Более того, подход с генерацией накладывает очень сильное ограничение — невозможность модификации своих классов. Рассмотрим, например, единственный пример с сайта (@Log). Если верить посту, то будет сгенерирован новый LogSample_Metacode, и потом еще надо будет руками вызвать у него apply, передав туда наш LogSample и еще какой-то провайдер, который тоже надо написать… Да еще и логгер внезапно стал публичным… В общем, нифига не равноценная замена private final (который еще и static обычно (хотя его-то как раз просто доделать в вашем варианте)).

Ну а 4й вопрос — так у вас те же проблемы, а на мой взгляд, так даже хуже. Т.к. если с lombok без плагина идея никогда не видит новых классов/методов, то у вас она видит с опозданием ровно на один билд.

IntelliJ IDEA 2016.3: Java 8 и ES6, улучшенные отладчик и интерфейс, и многое другое

Вот это да, идея позволяет себе компилировать код в нечто, отличающееся от того, что потом будет залито в прод. Свинство! Хоть отключили бы по дефолту.

IntelliJ IDEA 2016.3: Java 8 и ES6, улучшенные отладчик и интерфейс, и многое другое

deleted

Правильный полиморфный билдер на Java

Так там копипаста и не нужна если дженерики чуть аккуратнее написать.

class B1<T extends B1<T>> {
    public T fn1(String v) {
        return (T) this;
    }
}

class B2<T extends B2<T>> extends B1<T> {
    public T fn2(String v) {
        return (T) this;
    }
}

class B3<T extends B3<T>> extends B2<T> {
    public T fn3(String v) {
        return (T) this;
    }
}

class FB1 extends B1<FB1> {}
class FB2 extends B2<FB2> {}
class FB3 extends B3<FB3> {}

new FB3().fn1("1").fn2("2").fn3("3")

Лямбды и анонимные классы: кто больше жрёт

Неожиданно. А что там CPU ест?

Континуации в Java

Ха, только успел подумал что надо посоветовать переходить на котлин, как на тебе:

Так что лучше подождем, пока официально запилят корутины Kotlin-е.

«Команда разработки — самодостаточный организм»: SEMrush о Java и свободе выбора

В groovy по дефолту динамическая типизация, этого достаточно чтобы он не выстрелил.

Преобразование Method Reference в Method в языке Java

Я про другое. С методами класса Object просто вылетит ексепшн мол "я такое не умею" и все будет хорошо. А вот если у меня есть статический метод, который принимает Object, то внутри он может делать какой-нибудь side effect. И вызов unreference этот side effect успешно после себя оставит.

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

p.s. Но повторюсь. Решение прикольное (в хорошем смысле этого слова).

Преобразование Method Reference в Method в языке Java

Прикольно, но очень не нравится что делается вызов исходного метода. Если нам не повезет и он реально будет принимать Object, то мы на вызове unreference сначала сотворим side effect, а потом еще и замаскируем его с помощью RuntimeException("Something's wrong").