Наверняка большинство сколько-нибудь опытных программистов знакомы с паттерном Builder. Он позволяет сделать инициализацию структур данных более наглядной, гибкой при этом сохраняя такое полезное их свойство как неизменяемость (immutability). Вот классический пример с первой страницы выдачи гугла на запрос «java builder pattern example». При всех своих преимуществах, самый главный недостаток данной реализации паттерна — в два раза больше кода, по сравнению с обычным плоским бином. Если генерация этого дополнительного кода не проблема для любой популярной IDE, то редактировать такой класс становится достаточно утомительно и читабельность страдает в любом случае.

Большинство моих профессиональных Java проектов за последнее десятилетие были основаны на Spring или JEE. Обе платформы развиваются достаточно уверенно, однако все ещё страдают от различных проблем.

Spring и JEE по-прежнему остаются золотыми стандартами для масштабных Java-проектов и больших команд разработчиков, трудящихся над сложными enterprise-решениями. Однако, неизбежным следствием зрелости Java-сообщества стала частичная потеря прежнего энтузиазма и инновационности, что существенно ударило по авторитету обоих.

Когда долго и серьезно используешь какой-либо инструмент, неминуемо возникают претензии к нему — неудобства, с которыми сперва миришься, но в какой-то момент понимаешь, что проще один раз исправить, чем все время страдать. Хорош тот инструмент, который позволяет «допилить» сам себя.

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

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

Можно поискать какие-то короткие конструкции языка, которые компилируются в длинные цепочки байткода, но линейный прирост меня не устраивал. Я сразу подумал про компиляцию finally-блоков: про неё уже писали на Хабре. Если вкратце, то для каждого finally-блока при непустом try-блоке создаётся минимум два варианта в байткоде: для случая нормального завершения try-блока и для случая завершения с исключением. В последнем случае исключение сохраняется в новую локальную переменную, выполняется код finally, затем исключение достаётся из локальной переменной и перебрасывается. А что если внутри finally снова разместить try-finally и так далее? Результат превзошёл все ожидания.

Хочу поделиться простым, но, на мой взгляд, интересным способом поиска мест порождения пожирателей памяти при использовании минимального набора инструментов, которые всегда доступны под рукой – логи и jVisualVM.

Мы разрабатываем систему электронного документооборота, которая предназначена для работы десятков тысяч пользователей. При эксплуатации системы в течение нескольких месяцев столкнулись с ситуацией, когда серверу стало просто не хватать памяти, при том, что изменений в системе, за которые можно было бы зацепиться, не было. Да и тестовая копия системы не вызывает подозрений.

В Java для введения порядка среди определённых объектов можно написать компаратор — класс, содержащий функцию compare, которая сравнивает два объекта. Альтернативой компаратору является естественный порядок объектов: объект реализует интерфейс Comparable, который содержит метод compareTo, позволяющий сравнить этот объект с другим. Сравнивающая функция должна вернуть 0, если объекты равны, отрицательное число (обычно -1), если первый объект меньше второго, и положительное число (обычно 1), если первый больше. Обычно реализация такой функции не представляет сложностей, но имеется один случай, о котором многие забывают.

Сравнение используется различными алгоритмами от сортировки и двоичного поиска до поддержания порядка в сортированных коллекциях вроде TreeMap. Эти алгоритмы завязаны на три важных свойства сравнивающей функции: рефлексивность (сравнение элемента с самим собой всегда даёт 0), антисимметричность (сравнение A с B и B с A должны дать разный знак) и транзитивность (если сравнение A с B и B с C выдаёт одинаковый знак, то и сравнение A с C должно выдать такой же). Если сравнивающая функция не удовлетворяет этим свойствам, алгоритм может выдать совершенно непредсказуемый результат. Причём скорее всего вы не получите никакого исключения, просто результат будет неверный.

Как обнаружилось, несоблюдение этих свойств — не такая уж редкая ситуация. Проблема возникает при сравнении вещественных чисел — float или double.

Ключевое слово assert (проверка) появилось в Java 1.4. Мне кажется, многие до сих пор стараются его избегать, или заворачивать в утилитные статические методы с возможностью быстро поменять assert condition : message; на

if (!condition)
    throw new AssertionError(message);

по всему коду. Кто-то боится, что проверки недостаточно надежные, и если кто-то забудет их включить, какие-то баги останутся незамеченными. Кто-то, наоборот, маниакально думает о производительности: если кто-то включит проверки для подсистемы/библиотеки, написанной ребятами из первой группы, и забудет исключить пакеты или классы «производительной» библиотеки, исполнение будет замедленно бесполезными вычислениями.

Хотя, по-моему, ничего страшного в проверках нет, их можно и нужно расставлять по коду как можно щедрее. Во-первых, как я уже упомянул (но для кого-то это может оказаться в новинку), проверки можно гибко настраивать (включать/отключать в пакетах и отдельных классах) как из командной строки при запуске JVM, так и программно (через ClassLoader), так что если вы вдруг захотите включить проверки в одной системе и выключить — в другой, это уж точно решаемая проблема.

Во-вторых, иногда хочется проверять не тривиальные условия вроде какая-то булева переменная == false или true, а поддерживать некоторое проверочное состояние внутри класса и сверяться с ним в методах. С помощью трюка с assert можно добиться этого практически бесплатно при исполнении с отключенными проверками.

Java разработчикам привет.

Делюсь легковесной (3kb) библиотекой, единственная и основная задача которой — кидать ворнинги от Java компилятора.

Использование очень простое: пишите аннотацию Warning(«Reason text here») и при компиляции будет выдан ворнинг (сборка при этом не останавливается).

// some code...

@Warning("Refactor as soon as possible please")
public void someCodeWhichYouNeedAtTheMomentButYouWantToRefactorItLater() {
    // bad stuff going on here...
}

Использован Annotation Processor API.

Гитхаб: https://github.com/pushtorefresh/javac-warning-annotation (опубликовано в mavenCentral)

Надеюсь, будет полезно.

P.S. В большинстве случаев лучше заводить задачу в тасктрекере вместо использования данной аннотации, но для некоторых вещей такой вариант вполне уместен.

В этой статье я хочу поговорить про интеграцию Apache Lucene и Hibernate Search. Если быть более точным, то про один из механизмов Hibernate Search, который может здорово увеличить производительность на проекте с полнотекстовым поиском.

Спешу поделиться с коллегами накопленным опытом при разработке для Android Wear.

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

Продолжаем цикл статей — переводов по Spring и Hibernate, от krams.

Предыдущая статья:
«Spring MVC 3, Аннотации Hibernate, MySQL. Туториал по интеграции».

Введение.
В этом уроке мы познакомимся с использованием отношения один ко многим, используя аннотации Hibernate и Spring MVC 3. Мы будем использовать аннотоцию @OneToMany для указания отношений между нашими объектами. Мы не будем использовать каскадные типы или fetch-стратегии, вместо этого мы воспользуемся стандартными настройками @OneToMany.

Что такое ассоциация один-ко-многим?
Ассоциация один-ко-многим возникает тогда, когда каждой записи в таблице А, соответствует множество записей в таблице Б, но каждая запись в таблице Б имеет лишь одну соответствующую запись в таблице А.

Спецификация нашего приложения.

Приложение является простой CRUD системой управления списком записей. Каждая запись соответствует одному лицу, она содержит персональные данные и данные о кредитной карте. Каждое лицо может владеть несколькими кредитками. Так же мы добавим систему редактирования лиц и кредиток.

Ниже приведены скриншоты из будущего приложения:

Как известно, в языке Java существуют вложенные (nested) классы, объявленные внутри другого класса. Их даже четыре разновидности — статические вложенные, внутренние (inner), локальные (local) и анонимные (anonymous) (в этой статье мы не затрагиваем лямбда-выражения, появившиеся в Java 8). Всех их объединяет одна интересная особенность: виртуальная машина Java не имеет понятия об особенном статусе этих классов. С её точки зрения это обычные классы, расположенные в том же пакете, что и внешний класс. Вся работа по преобразованию вложенных классов в обычные ложится на компилятор. И здесь любопытно посмотреть, как разные компиляторы с ней справляются. Мы посмотрим на поведение javac 1.8.0.20 и компилятора ecj из Eclipse JDT Core 3.10 (идёт в комплекте с Eclipse Luna).

Прочитав заголовок, вы, наверное, немного удивились необычности задачи, которую я перед собой поставила. Однако, как ни странно, пейджеры до сих пор иногда могут пригодиться в жизни, даже несмотря на появившееся в последние 15 лет обилие других средств коммуникации. Один из частных случаев их применения — (около)медицинское учреждение, расположенное в железо-бетонном здании, глушащем WiFi и сигнал мобильного телефона. Обслуживающий персонал, тем не менее, должен каким-то образом получать сообщения о том, куда им надо срочно переместиться в случае чего. Для решения этой проблемы руководство учреждения в нашем случае поставило себе дорогую станцию и раздало всем сотрудникам пейджерА пейджеры, которые должны были среди прочих принимать наши сигналы. Соответственно, нашей (меня и моих коллег) задачей являлась их отправка.

Уже прошли те времена, когда для отправки текста на пейджер надо было сначала пообщаться с сонной девушкой с телефонного узла. Теперь достаточно дозвониться до станции и набрать номер абонента и сообщение в тоновом режиме. Арсенал при этом сильно ограничен: можно отправлять только цифры, символы * и #, иногда буквы ABCD. Но для передачи, скажем, номера комнаты или кода ошибки должно хватить. Это довольно сильно упрощает задачу и роднит её с другими — с дозвоном в общую переговорную комнату, например.

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

Отказ от ответственности

Во-первых, материал появился потому, что хотелось быстро объяснить индусам коллегам, что такое null-анализ, чем он хорош и почему нужно прямо сейчас преодолеть корпоративную лень и начать использовать этот анализ в проектах. Статьи, содержащей полную систематизированную информациию о предмете без привязки к IDE, не нашлось, так что пришлось писать самому. И хотя в результате полной систематизации так и не получилось, всё равно захотелось поделиться материалом с более широкой аудиторией. Будет минимум текста и много изображений.

Во-вторых, на ресурсе уже есть отличная статья tr1cks, посвящённая IntelliJ IDEA, которая усиливает и без того стойкое впечатление, что IDEA — это очень хорошо, а Eclipse — это для бедных (что стало притчей во языцех). Для соблюдения баланса я сконцентрируюсь на Eclipse.

Рассмотрим, в качестве примера, следующую ситуацию. У нас имеется класс User с полями, описывающими пользователя. Имеется класс Phone, который является родительским для классов CellPhone и SatellitePhone. В классе User есть поле содержащее список телефонов пользователя. В целях уменьшения нагрузки на БД мы сделали этот список «ленивым». Он будет загружаться только по требованию.


В такой конфигурации при запросе списка телефонов конкретного пользователя мы можем получить как список проинициализированных объектов-телефонов (например, если они уже есть в кэше), так и список proxy-объектов.
В большинстве ситуаций нам не важно с чем именно мы работаем (реальным объектом или его proxy). При запросе какого-либо поля какого-либо объекта — proxy-объект автоматически проинициализируется, и мы получим ожидаемые данные. Но если нам нужно узнать тип объекта, то все идет наперекосяк.

Добрый день! Полтора года назад моей команде пришлось протестировать Java Swing приложение, которое могло иметь разные визуализации, натянутые на общий процесс. Статей тогда по этой теме было немного, конкретные решения отсутствовали вообще. TestComplete и прочие скриптовые технологии (да простят меня сторонники TestComplete) использовать не хотелось, так как приложение должно иметь гибкую архитектуру, расширяемую и изменяемую в рамках Agile процесса.

Сутки поиска в Google, анализ десятков примеров и технологий привели меня к двум возможным вариантам:

• Fest
• Jemmy

Не погружаясь в глубины глубин сравнения, я выбрал Fest библиотеку. С её помощью и, конечно, Junit, Mockito мы начали тестировать наше приложение. Об этом и расскажу ниже.

Хотите пользоваться преимуществами (и недостатками) авто-обновления схемы БД при использовании Hibernate, но у вас имеется multi-tenant архитектура? Добро пожаловать под кат.

Постоянно сталкиваясь с парсингом Json всегда подглядываю в старых проектах или на встретившуюся реализацию объекта на stackoverflow.com.

Решил собрать три основных типа в шпаргалку Map, List, Array.

Type itemsMapType = new TypeToken<Map<Integer, GoodsItem>>() {}.getType();
Type itemsListType = new TypeToken<List<GoodsItem>>() {}.getType();
Type itemsArrType = new TypeToken<GoodsItem[]>() {}.getType();

Рассматривается Serialization/Deserialization операции класса:

public class GoodsItem{
    String name;
    float price;
    public GoodsItem(String name, float price) {
    this.name = name;
    this.price = price;

    public String toString(){
	return name + " : " + price;
    }
}

12345

На днях появилась статья 5nw Два способа быстрого вычисления факториала, в которой приводится идея ускорения подсчёта факториала с помощью группировки перемножаемых чисел в дерево по принципу «разделяй и властвуй». Взглянув на это, я сразу понял, что тут параллельные потоки Java проявят себя во всей красе: ведь они делят задачу на подзадачи с помощью сплитераторов именно таким образом. Получается, что быстрая реализация будет ещё и красивой:

public static BigInteger streamedParallel(int n) {
    if(n < 2) return BigInteger.valueOf(1);
    return IntStream.rangeClosed(2, n).parallel().mapToObj(BigInteger::valueOf).reduce(BigInteger::multiply).get();
}