По-явански

Боль мапперов Почему мапперы придумали — понятно: чтобы трансформировать данные из одного формата в другой, нужно представить их в каком-то виде. Работать непосредственно с потоком токенов или синтаксическим деревом и привязываться к формату сериализации никому не хочется, а особенно неприятно, если формат динамически типизирован (JSON, XML), а язык программирования — статически. Поэтому универсальной формой данных стали DTO и всевозможные их сочетания. Однако, код преобразования одних DTO в другие выглядит невыразительно, в нём легко ошибиться, а парсинг в промежуточные структуры избыточен. Что делать с этим императивным наследием махрового энтерпрайза? Жду ваши варианты в @javanese_questions

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

sidenote: JSON ужасно неэффективен, т. к. там постоянно повторяются имена полей объектов. JSON особенно неэффективен в Java, т. к. там UTF-16. Ещё JSON категорически неэффективен в XML (привет, SharedPreferences), т. к. каждая кавычка превращается в ".

Java hidden costs revisited Этот перевод я сделал раньше, чем канал в телеграме. Так что вот он ещё раз, исправленный и дополненный.

Форкнул и поправил план роста и развития для андроидщиков. Содержит как спорные и необязательные темы вроде Firebase, так и необходимые: языки, Java Core, Android SDK.

Любопытный блог, автор которого критикует Elegant Objects Егора Бугаенко и излагает своё видение ООП, которое называет Pragmatic Objects. The core principles of software design No DI containers, please

Написал несколько инспекций для IntelliJ IDEA / Android Studio: * атомик можно заменить на volatile, если используются только методы get и set * возвращаемое значение Enum.values() стоит кешировать Kotlin: * property delegation * не надо называть сущности ключевыми словами из Java * от инлайн-функции больше вреда, чем пользы, если внутри неё объявлены неинлайновые анонимные функции * функция не может быть заинлайнена в данной ситуации Android XML: * использование аттрибута темы <include layout="вот здесь"> Страница плагина

Я встречал два разных определения понятия Dependency Injection. 1. Пафосное название для передачи зависимостей.

new SomeServerApplication(
    new HttpServer("https", "example.com", 443),
    new DbConnectionPool(new JdbcConnection(...)),
    new HtmlResponseWriter(Charsets.UTF_8)
)

2. Передача зависимостей с помощью стороннего, «магического» (т. е. внеязыкового) механизма.

@Inject SomeServerApplication(params)

Некоторые споры и сломанные копья упираются не в разногласия между спорящими, а в разницу между определениями.

Хакатон. Разные люди, разные привычки и предпочтения. Кому-то понятна только Java с XML, т. е. нельзя просто так взять и выбрать Anko или Splitties View DSL для всего приложения. Но желание не писать легаси-код лично у меня побеждает, спонтанно получается вёрстка в коде. При этом сахар пишется на коленке и по мере необходимости — и получается очень простой и в небольших количествах.

Категорически согласен с этим господином: код должен в первую очередь кричать о том, что он делает, а не из каких компонентов состоит. https://youtu.be/YZstpc2939s?t=1564

Немного тезисов. Для рантайма, где дженерики стёрты и всё указатель, такие идиомы, как кодогенерация, макросы и рефлекшен неуместны. ProGuard не узнает, какие конвертеры в Gson используются, а какие будут только занимать место. Тонкий клиент или CRUD-приложение — частный случай дата-байндинга. Видео с #AppsConf2019: https://www.youtube.com/watch?v=Yx2VjW5G2GA Библиотека: Lychee, чат: @kotlin_lychee

Давно я ревью не делал. Здесь выполненное тестовое задание: валидатор банковских карт. Вывод из этого всего напрашивается один — упрощайте.

Отгадка заключается в том, что создание (неинициализированного) объекта и вызов его конструктора — это две разные инструкции.

private static SomeComponent inPlace(
    java.util.concurrent.Future<java.lang.String>
) throws java.lang.Exception;
 // выделение памяти
 0: new SomeComponent
 ...
 // вызов конструктора
13: invokespecial SomeComponent."<init>":(Ljava/lang/String;)V
16: areturn

private static SomeComponent withVariable(
    java.util.concurrent.Future<java.lang.String>
) throws java.lang.Exception;
 ...
 //выделение памяти
10: new SomeComponent
13: dup
14: aload_1
 // вызов конструктора
15: invokespecial SomeComponent."<init>":(Ljava/lang/String;)V
18: areturn

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

Половина ответа на вопрос:

private static SomeComponent inPlace(
    java.util.concurrent.Future<java.lang.String>
) throws java.lang.Exception;
 0: new SomeComponent
 3: dup
 4: aload_0
 5: invokeinterface java/util/concurrent/Future.get:()Ljava/lang/Object;
10: checkcast class java/lang/String
13: invokespecial SomeComponent."<init>":(Ljava/lang/String;)V
16: areturn

private static SomeComponent withVariable(
    java.util.concurrent.Future<java.lang.String>
) throws java.lang.Exception;
 0: aload_0
 1: invokeinterface java/util/concurrent/Future.get:()Ljava/lang/Object;
 6: checkcast class java/lang/String
 9: astore_1
10: new SomeComponent
13: dup
14: aload_1
15: invokespecial SomeComponent."<init>":(Ljava/lang/String;)V
18: areturn

Есть идеи, какой код отработает быстрее?

HeavyComponent inPlace(Future<String> f1) throws Exception {
    return new HeavyComponent(f1.get());
}

HeavyComponent withVariable(Future<String> f1) throws Exception {
    String s1 = f1.get();
    return new HeavyComponent(s1);
}

Считаем, что это инициализация графа зависимостей, а HeavyComponent — увесистый класс.

Hype-driven Android-development Коротко о том, куда катится индустрия и с чем придётся столкнуться инженеру при поиске проектов и коллег.

Я серьёзно подумал над своим поведением. С сегодняшнего дня буду уделять больше времени JEE, рефлексии, кодогенерации, спрингу, хибернейту, руму, даггеру, мокси, Android Architecture Components, RxJava — ведь это самые прекрасные проявления джавы, которые заслуживают большего внимания.

BitSet Странный предмет. По определению это вектор булеанов, специализированная версия List<Boolean>. По факту же от нормального листа эта штука очень сильно отличается: — не реализует ни Collection, ни List; — метод для узнавания размера называется length(), а size() возвращает немного другое значение; — методов add и remove нет; — метод set(length + x) не бросает исключение, а работает как add; — запись значений false в конец уменьшает length().