Java EE 5: Мощь и производительность при меньшей сложности

Java EE 5: Мощь и производительность при меньшей сложности

Технология Java EE является расширением языковой платформы Java, которое позволяет создавать масштабируемые, мощные и переносимые корпоративные приложения. В ней определено четыре типа контейнеров для компонентов приложения: Web, Enterprise JavaBean (EJB), клиентские приложения и аплеты. Эти контейнеры и поддерживаемые ими Java API подробно описаны в спецификации сервера приложений, что создает и поддерживает конкуренцию на рынке продуктов Java EE, гарантируя при этом серверную переносимость для приложений, которые придерживаются спецификации (см. врезку Краткая история Java EE).

Последняя версия платформы, Java EE 5, была выпущена в мае 2006 года. Сосредоточенная в первую очередь на производительности разработчика, Java EE 5 предоставляет простую модель программирования без ущерба для мощности и функциональности платформы. Упрощение моделей разработки обеспечивают по большей части два механизма — аннотации Java и разумные значения по умолчанию. Важнейшие функциональные усовершенствования включают расширение поддержки Web-сервисов, а также включение в платформу JavaServer Faces (JSF) и стандартной библиотеки тегов Java (JSTL — Java Standard Tag Library).
Краткая история Java EE

Grester облегчает JUnit-тестирование Java-приложений

Grester облегчает JUnit-тестирование Java-приложений

Jester, созданный Айвеном Муром (Ivan Moore), представляет собой превосходный инструмент, который тестирует unit-тесты, написанные программистами и разработчиками. Он основан на предположении, что в коде может существовать множество мест, содержащих операторы условных переходов, циклов и выбора, а также мест, в которых цикломатическая сложность классов в целом может резко возрастать или увеличиваться из-за множества возможных путей исполнения. Jester сосредоточен именно на таких участках кода. Но для его работы требуется хорошо отформатированный classpath к различным ресурсам.

Grester, который представляет собой оболочку Apache Maven вокруг Jester, упрощает рутинную работу по созданию classpath Java™ с учетом зависимостей проекта, облегчая тестирование с применением Jester. Кроме этого, Grester пытается реализовать некоторые преимущества Maven, который лежит в основе его инфраструктуры. Jester чрезвычайно полезен в качестве дополнительного средства проверки кода, написанного без учета требований разработки через тестирование. Это могут быть старые программы или код, недавно написанный программистами, которые считают методы разработки через тестирование, входящие в концепцию гибкой разработки ПО (Agile software development), слишком грубыми в качестве исходного принципа написания качественного кода.

Нетривиальные возможности Java

Нетривиальные возможности Java

Java — язык простой. И после года активного использования для Вас не остаётся секретов. Совершенно случайно я обнаружил, что на stackoverfow люди решили поделиться скрытыми возможностями (Hidden Features of Java). Вышло очень занимательно, получился своеобразный рейтинг нетривиальных возможностей, который я далее запротоколирую в вольном переводе на русский.

double brace

С большим отрывом лидирует «double brace», уже обсуждавшийся ранее в статье Эффект «double brace» by zeroed. Подробное описание метода —
http://www.c2.com/cgi/wiki?DoubleBraceInitialization
несомненно это самое забавное и неочевидное из списка. Однако как уже отмечалось, метод имеет свои минусы в виде анонимного класса на каждое использование этого метода. А также невозможности использования метода equals () для подобных объектов.

Работа с Grails: Cоздание первого Grails-приложения

Работа с Grails: Cоздание первого Grails-приложения

Знакомство с Grails я начну с другой бесплатной инфраструктуры для разработки Web-приложений: Ruby on Rails. Когда Rails появился, он увлек множество разработчиков. Возможности скаффолдинга, заложенные в Rails, позволяли запустить новый проект за меньшее время, чем раньше. Идея «соглашений по конфигурации» (convention over configuration), лежащая в основе Rails, позволяет приложению «собирать» себя самому, основываясь на разумных схемах именования, а не на громоздких и подверженных ошибкам конфигурационных XML-файлах. Возможности метапрограммирования Ruby позволяют объектам «магически» наследовать методы и поля, которые им требуются во время работы, без загромождения исходного кода.

Инфраструктур Rails заслужил и по-прежнему заслуживает того одобрения, которое он получил, но он ставит Java-разработчиков перед трудными вопросами. Стоит ли отказываться от известной Java-платформы из-за обещаний новой платформы? И что делать с существующим кодом Java, существующими корпоративными серверами и штатом опытных Java-программистов?