Java *

С появлением в Spring 2.5 фреймворка TestContext интеграционное тестирование кода, работающего с базой данных, существенно упростилось. Появились аннотации для декларативного указания контекста, в котором должен выполняться тест, аннотации для управления транзакциями в рамках теста, а также базовые классы тестов для JUnit и TestNG. В этой статье я опишу вариант интеграции фреймворка TestContext с DBUnit, позволяющим инициализировать базу данных и сверить её состояние с ожидаемым по окончании выполнения теста.

Typesafe Stack — современная программная платформа, которая обеспечивает возможность создания легко масштабируемых программных систем на Java и Scala. Стек функционирует на JVM, включает в себя фрэймворки Akka 2.0 и Playframework 2.0. Ядром платформы, которое обеспечивает практически неограниченную масштабируемость разрабатываемой системы, является библиотека Akka, реализующая многозадачность на основе модели акторов.

Введение

Для передачи данных от интерфейса веб-приложения есть несколько методов, но, пожалуй, самый распространенный — отправка формы с MIME-type application/x-www-form-urlencoded. Ещё один вариант — multipart/form-data.

В качестве серверной технологии для приема могут использоваться контроллеры в MVC-фреймворках (из основных Java-технологий следует упомянуть Spring MVC, Java Server Pages, Java Server Faces. Но эти фреймворки довольно сильно осложняют жизнь разработчику интерфейса, если он не знаком с Java или нужен шаг в сторону от того, что позволяет фреймворк. В случае же экспонирования REST-интерфейса бэкендом приложения разработкой фронта упрощается: ей может заниматься человек, знающий базовый javascript и jquery, независимый от разработки бэка. Кроме того, даже при использовании шаблонизатора, выбор сильно расширяется: Apache Velocity, FreeMarker (стоит упомянуть, что Spirng MVC неплохо интегрируется с последними). Тогда данные из формы на стороне сервера записываются в бины, с которыми связан данный view/controller. Правда, у JSF тоже наблюдалась генетическая проблема с кодировками, рассмотрение которой — тема для отдельной статьи.

Краткое введение в JAX-RS было дано в предыдущей статье. И экспонированный через JAX-RS интерфейс может принимать GET и POST запросы с данными форм. О проблемах данного подхода при использовании не-latin-1 и пойдет речь в данной статье.

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

1. Легковесность
2. Потокобезобасность

В общем-то и все. До написания данной задачи с java.util.concurrent дела не имел. На мысль использования этого пакета меня натолкнул один мой коллега, у которого было нечто подобное, но не соответствовало тому функционалу который был нужен. Итак, начнем:

В качестве ключа будет выступать внутренний класс, который помимо прямого назначения будет определять он является «живым» или его можно удалить с кеша, так как время его существования подошло к концу:

В качестве хобби последние несколько месяцев я разрабатываю парсер языка PHP с помощью ANTLR. Сам проект для меня скорее просто Just for fun, но в ходе его реализации у меня, разумеется, возникали сложности. Тут сказывается как особенность языка PHP с полным отсутствием спецификаций, так и ограничения алгоритмов LL(k).

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

Введение

Выросло данное API из JSR 311: JAX-RS: The Java API for RESTful Web Services и вошло в Java EE 6 (планировалось в Java EE 5). Как видно из названия, предназначено оно для разработки RESTful веб-сервисов.

Основная цель данной статьи — познакомить читателя с основами JAX-RS API. Изначально я планировал написать о некоторых проблемах работы форм при использование JAX-RS сервиса. Не обнаружив на Хабре почти ничего, касающегося данной технологии понял, что введением к статье отделаться не удастся.

Будут представлены основы JAX-RS API, реализация от JBoss и дано небольшое введение в клиентскую часть фреймворка Resteasy.

Java характеризуется динамической загрузкой классов. Для поиска и загрузки используется механизм делегирующих classloader'ов. В Java SE окружении их количество ограничивается 2-3, но в серверах приложений оно приближается к 10 иерархическим classloader'ам. Этим объясняется большое время запуска (обычно от минуты) и деплоя приложений.

В JBoss AS 7 разработчикам удалось сильно сократить время запуска (пустой appserver запускается за 3-4 секунды на рабочей станции). Этому способствовала новая система загрузки классов в данном сервере приложений. Такой подход всё же обладает своими недостатками.

Данная статья касается механизма загрузки классов в различных окружениях, особенностях работы с JBoss AS 7, сопряжения с системой сборки Apache Maven и IDE IntelliJ IDEA.

Очень часто вес приложения, которое мы выкладываем на сервер достигает неприлично больших размеров из-за включения в него всех нужных зависимостей. У меня в конечном итоге приложения занимают от 20 до 50 метров. Деплой таких war-ов на удаленный сервер, на Tomcat, дело не одной минуты, а при плохой связи и вовсе становится проблематичным. Класть библиотеки в ${tomcat.home}/lib дело очень неблагодарное и зачастую опасное. Мы на фирме немного погуглили и нашли очень приятное решение на DZone. Хочу с вами поделиться…

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

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

Stephen Chin, автор проекта JFXtras, предлагает желающим возглавить проект. Аргументирует своё решение отсутствием времени из-за работы над книгой по JavaFX.



Участники проекта JFXtras тесно сотрудничают с Oracle (либо являются штатными работниками Oracle). JFXtras служит инкубатором для новых компонентов JavaFX, часть из них войдёт в официальный релиз JavaFX 3.0.

Ссылка на письмо С.Чина — http://groups.google.com/group/jfxtras-users/browse_thread/thread/437d8f8f25faafc2. В комментариях к его письму можно предложить своё участие, если кому интересно.

У нас и rich client, и сервер активно используют Spring. И очень быстро возникла проблема — как использовать спринг бины из обычных классов (которые сами — не бины).

Сначала возникли две идеи — передавать им нужные бины как аргументы в конструкторе или использовать какое то статическое поле для хранения Spring context.
Первая идея была признана порочной. Получается, что ныжные сервисы надо тянуть через длинную череду конструкторов.
Вторая идея тоже была признана порочной — возникает вопрос кто и когда будет инициализировать это поле и что будет происходить с юнит тестами.

Вскоре я нагуглил в интернетах такой красивый вариант:

Священный спор

Принято считать, что есть «вечные» вопросы, на которые нет правильного ответа. Например, что лучше: Windows или Linux, Java или C#; Чужой против Хищника или Чак Норрис против Ван Дамма.

Одним из таких холиваров считается выбор лучшей IDE для Java:


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

Так вот, я утверждаю, что это не просто дело вкуса. Есть объективные причины, почему

Intellij IDEA однозначно лучше, чем Eclipse.

Подчёркиваю, мы сейчас рассматриваем обе среды именно как Java IDE.

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

Хочу вам рассказать немного о Java Day, который случился 10 февраля. Сразу поясню, почему публикую так поздно — первоначально идея была в том, чтобы сравнить Java Day с семинаром Red Hat (читайте в моём следующем посте), но мероприятия оказались настолько разными, что писать о них «вперемешку» нет никакого смысла. Вообще-то, пост будет не столько описанием того, что там происходило (такое уже публиковалось), сколько о впечатлениях, которые у меня остались.

Я уже посещал ранее «Sun Tech Days», но тогда мероприятие проходило «под крылом» Sun, поэтому, честно говоря, я ехал посмотреть, насколько Oracle всё испортила. :-) К счастью, сильно разочароваться мне не пришлось, хотя влияние нового владельца Java всё же было очень заметно.

Добрый день!
По роду работы (Documentum developer) столкнулся с необходимостью отлаживать процессы, которые создаю в Process Builder. Нашёл простой способ это сделать. И вот этим знанием хотелось бы поделится с разработчиками Documentum, которые наверняка присутствуют на Хабре.

Введение

Рассмотрим процесс локальной отладки метод, вызываемых активностями в Process Builder’е (PB) в режиме в Debug. Причины этого очевидны – для отладки и проверки на минимальную работоспособность методов не нужно «заливать» их в Java Method Server (JMS) с его рестартом. И ладно если с ним работаешь только ты один, а если несколько человек одновременно разрабатывают свои методы?

Недавно я наткнулся на блог, который ведет Peter Lawrey. Там можно найти интересную информацию, которая касается производительности кода под JVM.

Там я нашел непривычный подход, который состоит в повторном использовании объектов. Непривычен он по нескольким причинам:

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

Сегодня компания JetBrains объявила о доступности исходных текстов языка программирования Kotlin, который предназначен для разработки на платформах Java и JavaScript. В дополнение был предоставлен доступ к сборкам компилятора, стандартным библиотекам Kotlin, инструментам сборки (интеграция с Ant, Gradle, Maven), и плагину для Intellij Idea. Ранее стала доступна Веб-демо версия Kotlin.

В июле прошлого года JetBrains анонсировали новый язык программирования Kotlin. Сегодня, JetBrains выложили исходные коды этого языка программирования в Open Source. Теперь пощупать новинку могут все желающие.

Предположим, у вас есть большое приложение написанное на Java. Это может быть web-сервлет размещенный в контейнере или standalone-сервис. В процессе разработки (да и во время эксплуатации) возникает необходимость отслеживать процессы, протекающие в JVM: работу garbage collector, использование памяти, жизненный цикл потоков, а так же иные специфичные для вашего проекта показатели посредством MBean. Самый простой вариант — использовать профилировщик. Но увы, проблемы не случаются по расписанию, и невозможно заранее знать, когда нужно подключить профилировщик, а держать его постоянно включенным тоже не вариант. В таких случаях идеальное решение — непрерывный мониторинг. О нем и пойдет речь. Но для начала пара слов о классической профилировке.

В предыдущей статье много комментаторов были не согласны в необходимости наличия знаний о размере объектов в java. Я категорически не согласен с этим мнением и поэтому подготовил несколько практических приемов, которые потенциально могут пригодится для оптимизации в Вашем приложении. Хочу сразу отметить, что не все из данных приемов могут применяться сразу во время разработки. Для придания большего драматизма, все расчеты и цифры будут приводится для 64-х разрядной HotSpot JVM.

Денормализация модели

Итак, давайте рассмотрим следующий код:

class Cursor {
    String icon;
    Position pos;
    Cursor(String icon, int x, int y) {
         this.icon = icon;
         this.pos = new Position(x, y);
    }
}
class Position {
    int x;
    int y;
    Position(int x, int y) {
        this.x = x;
        this.y = y;
    }
}

А теперь проведем денормализацию:

class Cursor2 {
    String icon;
    int x;
    int y;
    Cursor2(String icon, int x, int y) {
        this.icon = icon;
        this.x = x;
        this.y = y;
    }
}

Казалось бы — избавились от композиции и все. Но нет. Объект класса Cursor2 потребляет приблизительно на 30% меньше памяти чем объект класса Cursor (по сути Cursor + Position). Такое вот не очевидное следствие декомпозиции. За счет ссылки и заголовка лишнего объекта. Возможно это кажется не важным и смешным, но только до тех пор, пока объектов у Вас мало, а когда счет идет на миллионы ситуация кардинально меняется. Это не призыв к созданию огромных классов по 100 полей. Ни в коем случаем. Это может пригодится исключительно в случае, когда Вы вплотную подошли к верхней границе Вашей оперативной памяти и в памяти у Вас много однотипных объектов.

Некоторое время назад я решал задачу автоматической покупки домена. Нужно было оформить в виде библиотеки (jar и файл настроек), которая использовалась бы в корпоративном приложении на Java. Я начал поиски DNS провайдеров с public API. Желательно, чтобы API были попроще, и домены подешевле — такой баланс оказалось не просто найти.