Java *

Хоббит или туда и обратно

Некоторое кол-во времени назад мне срочно потребовалось найти возможные способы получения переменных из js и браузера, чтобы передать их значение в моем приложении на java. К сожалению, на хабре данный вопрос не был раскрыт или возможно сила покинула меня и поиск дается уже не так легко.
Как бы то ни было сегодня я постараюсь в какой то мере пролить свет на данный вопрос. Итак приступим!

Play! framework набирает популярность и на Хабре уже есть следующие топики:
Отличный Java MVC фреймворк — Play Framework
‘Hello World’ tutorial — Ваше первое приложение на Play framework (Часть 1)
‘Hello World’ tutorial — Ваше первое приложение на Play framework (Часть 2)
Мои 5 любимых фишечек в Play Framework

Одна из замечательных возможностей Play! — развертывание приложения в облачную инфраструктуру App Engine от Google.

На приложения, которые исполняются в GAE накладываются довольно жесткие (по сравнению с обычными Play! приложениями) ограничения, в основном, это связано с модулем сохранения данных (JPA / Hibernate). Для того, чтобы приложение без проблем заработало в GAE следует отказаться от JPASupport/Model хелперов и использовать только базовые возможности JPA.
Альтернативой также может стать использование модуля Siena.

В данном топике я пошагово опишу процесс развертывания приложения Play! в Google AppEngine.
Процесс установки и использования описан применительно к ОС Linux, но существенных различий при использования других ОС возникнуть не должно.

«Вы счастливчики. Мы по три месяца жили в мешках из дерюги в грязных сараях. Мы вставали в шесть утра, стирали мешки, съедали по корке чёрствого хлеба и шли работать на мельницу, по 14 часов в день, с понедельника и до воскресенья, и когда мы возвращались домой, наш папа порол нас своим ремнем»
— Летающий цирк Монти Пайтона, Четыре йоркширца


Ленивая молодёжь.

Что может быть хорошего в тяжёлой работе?

Верный признак моего старения — моё ворчание и жалобы о «современной молодёжи» и о том, как не хотят или не могут больше делать ничего сложного.

“Есть ложь большая, есть маленькая, а есть статистика производительности Java.”

В последнее время я стал замечать обилие тестов производительности Java с удивительно невероятным разбросом результатов тестирования. Результаты отличаются с точностью до полной противоположности, в зависимости от того кто проводит тесты.

Многим понятно, что такие тесты это часть маркетинга. И те кто его заказывает, заказывают и результат. Но удивительность ситуации в том, что упрекнуть во лжи некого. Нельзя отказать в истинности тех тестов в которых Java на порядок уступает C#, ни тем тестам в которых Java превосходит С++ (не Си). Проблема в том, что такие тесты ориентированны в основном на начинающих разработчиков с целью переманить в свой стан побольше программистов и тем самым увеличить коммерческую привлекательность платформы для бизнеса. И в таких тестах намеренно упускаются сложные для понимания подробности работы динамической JIT компиляции и адаптивной оптимизации HotSpot, в которые начинающие программисты редко вдаются.

Чем это чревато? Банальным когнитивным диссонансом.

Groovy — объектно-ориентированный язык программирования разработанный для платформы Java как альтернатива языку Java с возможностями Python, Ruby и Smalltalk.

Groovy использует Java-подобный синтаксис с динамической компиляцией в JVM байт-код и напрямую работает с другим Java кодом и библиотеками. Язык может использоваться в любом Java проекте или как скриптовый язык.

Возможности Groovy (отличающие его от Java):

— Статическая и динамическая типизация
— Встроенный синтаксис для списков, ассоциативных массивов, массивов и регулярных выражений
— Замыкания
— Перегрузка операций

[http://ru.wikipedia.org/wiki/Groovy]

Более того, почти всегда java-код — это валидный groovy-код.

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

Думаю, почти каждый сталкивался с таким мнением: писать тесты сложно, все примеры написания тестов даны для простейших случаев, а в реальной жизни они не работают. У меня же за последние годы сложилось впечатление, что писать тесты — это очень просто, даже тривиально^*. Автор упомянутого выше комментария далее говорит, что неплохо было бы сделать пример сложного приложения и показать, как его тестировать. Попробую именно этим и заняться.

^*)Писать сами тесты — действительно элементарно. Создать инфраструктуру, позволяющую легко писать тесты — чуть сложнее.

Наверняка все знакомы с таким понятием как test-driven development(TDD). Наряду с ним также существует такое понятие, как data-driven testing(DDT, не в обиду Шевчуку) — техника написания тестов, при которой данные для тестов хранятся отдельно от самих тестов. Они могут храниться в базе данных, файле, генерироваться во время исполнения теста. Это очень удобно, так как один и тот же функционал тестируется на различных наборах данных, при этом добавление, удаление или изменение этих данных максимально упрощено.

В предыдущей статье я рассмотрел возможности JUnit-а. Там примерами такого рода подхода могут служить запускалки Parameterized и Theories, в обоих случаях один тест-класс может содержать только один такой параметризированный тест(в случае Parameterized несколько, но все они будут использовать одни и те же данные).

В этой статье я заострю внимание на тестовом фреймворке TestNG. Многие уже слышали это название, и перейдя на него, вряд ли желают вернуться к JUnit-у(хотя это только предположение).

Я часто и много работаю со Swing и, как следствие — очень часто приходится создавать
слушателей самых различных видов и форм. Однако некоторые виды встречаются чаще других,
и ниже я приведу свой рецепт автоматизации их создания.
Возможно, предложенный мной подход не оригинален, но в литературе я его не встречал.
UPD: спасибо pyatigil за ссылку на статью, в которой описывается аналогичный подход, но немного в другом стиле.

Совсем недавно, в статье Сервлеты — маленький трюк с Reflection, разбирался прием, с помощью которого можно получить url вида:
host/servletName/methodName.

Если пойти дальше, то с помощью Reflection можно реализовать конструкцию следующего вида:


Где, у нас в проекте есть несколько классов контроллеров, и у каждого из них свои действия. А самое главное, в методы контроллеров мы можем передавать параметры из URI. Например:
host/servletName/projects/add?title=hello

Любите ли вы GWT так, как люблю его я? Недавно возникла задача, повесить Sonar на проект, где используется GWT. Проблема возникла в тот момент, когда врубается Clover. Подробности этой истории под катом.

Зачем это надо?

В enterprise-разработке часто бывает необходимо отслеживать процесс редактирования каких-нибудь таблиц.
Скажем, завели у вас документ в системе. Потом кто-то поменял ему серию. Потом номер. Потом сменил тип с паспорта РФ на загран. паспорт Германии. Хотелось бы иметь возможность отследить историю изменений и, скажем, настучать по шапке пользователю, который совершил ошибку.

На прошлогодней конференции JavaOne в Сан-Франциско компания Oracle анонсировала технологию JavaFX 2.0. А несколько дней назад мир увидел Java FX 2.0 Beta. JavaFX — это естественный шаг в эволюционном развитии клиентской платформы Java. Технология обеспечивает разработчиков кросс-платформенным инструментом для создания функционально насыщенных и привлекательных приложений.
Встроенная в технологию Java, JavaFX предлагает богатый графический и медийный API с поддержкой аппаратных графических ускорителей и большой выбор новых компонент: элементов управления, графиков, мультимедиа и встроенного браузера.
Из очевидных плюсов JavaFX 2.0 — возможность создания приложений без изучения новых технологий, применение привычных средств разработки и, конечно, все традиционные плюсы Java. Для корпораций — использование технологии Java на серверной и клиентской сторонах снизит интеграционные риски.
Из минусов: к сожалению, бета версия вышла только для Windows, но к релизу состав поддерживаемых платформ расширится.

Но лучше один раз увидеть, чем 100 раз услышать.
Давайте попробуем вместе написать панель задач с кнопками в стиле Mac

Сегодня все большую популярность приобретает test-driven development(TDD), техника разработки ПО, при которой сначала пишется тест на определенный функционал, а затем пишется реализация этого функционала. На практике все, конечно же, не настолько идеально, но в результате код не только написан и протестирован, но тесты как бы неявно задают требования к функционалу, а также показывают пример использования этого функционала.

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

Ну и начну с, пожалуй, самого известного, а потому и самого используемого фреймворка для тестирования — JUnit. Используется он в двух вариантах JUnit 3 и JUnit 4. Рассмотрю обе версии, так как в старых проектах до сих пор используется 3-я, которая поддерживает Java 1.4.

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

Только вернулся с JeeConf о котором уже ранее писал — и очень хочется поделиться впечатлениями. Если кратко — было очень круто — ну а чуть подробней — под катом

Задача:

Необходимо написать сервлет, который содержит кучу методов, имена которых совпадают с URL.
Например, у нас 3 URL адреса:

myhost/userservice/registration
myhost/userservice/login
myhost/userservice/anotherAction

которые обрабатывает сервлет UserServiceServlet, вот так:

Думаю, у многих возникала задача точно знать версию выпущенного jar'a или war'a. Причем хотелось бы иметь способ, позволяющий «простому пользователю» определить версию такого архива. Ниже приведен способ решения этой задачи.

Читая ежедневную порцию постов из своей подборки Google Reader наткнулся на пост про ORM для MongoDB с манящим названием «Morphia». Ниже вы найдете компоновку материалов из его документации, претендующую на звание «очень краткий обзор».

1. Morphia очень просто использовать. Это легкий и быстрый фреймворк
2. Поддерживает как аннотированные POJO объекты, так и DAO подход
3. Вся конфигурация задается аннотациями, XML файлы не используются
4. Поддерживается интерфейс расширений (в настоящий момент во фреймворк встроены валидация (jsr330) и поддержка SLF4J для протоколирования
5. Отлично работает с Google Guice, Spring и другими DI фреймворками
6. Содержит большое количество точек расширения
7. Поддерживает GWT

«Отгремел» ADD-2011 (кстати — огромное спасибо организаторам — было круто и интересно!) как пора паковать чемоданы на следующую. К удивлению — поиск по «JEEConf» ничего не дал на хабре (или я плохо искал?) — а конференция выглядит очень интересной!
Итак — возьму на себя смелость сделать неофициальный анонс JEEConf — надеюсь еще не поздно.

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

В последнем приложении, с которым я работал, был реализован на тот момент неизвестный мне велосипед SPI механизм, который искал в джарках текстовые файлы вида META-INF/services/<qualified interface name> и брал оттуда название нужного класса, реализующего этот интерфейс, далее этот класс использовался как расширение. Поискав в интернете, узнал, что Service Provider Interface(SPI) представляет собой программный механизм для поддержки сменных компонентов и что этот механизм уже довольно давно используется в Java Runtime Environment(JRE), например в Java Database Connectivity(JDBC):

ps = Service.providers(java.sql.Driver.class);
try {
  while (ps.hasNext()) {
    ps.next();
  }
} catch (Throwable t) {
  // Do nothing
}

Благодаря этому коду приложения больше не нуждаются в конструкции Class.forName(<driver class>) (хотя и с ней будут работать), JDBC драйверы будут подгружены автоматически при первом обращении к методам класса DriverManager.

SPI механизм также используется в Java Cryptography Extension(JCE), Java Naming and Directory Service(JNDI), Java API for XML Processing(JAXP), Java Business Integration(JBI), Java Sound, Java Image I/O.

Как это работает?

Весь смысл в разделении логики на сервис(Service) и провайдеры(Service Providers). Ссылки на провайдеры сохраняются в джарках расширений в текстовом файле(UTF-8) META-INF/services/<qualified service class>, в каждой строке полное имя класса провайдера. Пустые строки и комментарии(начинающиеся с символа #) игнорируются. Ограничения на провайдеры: они должны реализовывать интерфейс либо наследоваться от класса сервиса и иметь конструктор по умолчанию(zero-argument public constructor).