Feel Java

Области применения XML.

noreply@blogger.com (Andriy Sholokh) — Sat, 01 Mar 2008 16:08:00 +0000

XML – это формат обмена данными... И ничего более.

Ни для кого не секрет, что XML является одной из наиболее популярных технологий, появившихся за последние 10 лет. Но для каких целей все-таки целесообразно ее использование? Для описания конфигурационных данных? Для передачи данных? Как средство хранения данных? Для решения каких задач следует применять XML? Данная статья дает пищу для размышления и позволит Вам сформулировать свой ответ на данный вопрос.

Хранение конфигурационных данных.

Одним из первых вариантов применения формата XML, и до сих пор одним из наиболее популярных, является его применение для хранения конфигурационных данных. Практически сразу, как только XML стал популярен, разработчики стали заменять созданные ими ранее конфигурационные файлы файлами в формате XML. Файлы настроек, текстовые файлы, содержащие пары имя-значение, значения разделенные запятыми, собственные форматы файлов, были вытеснены XML документами, состоящими из тегов, элементов, атрибутов и текстовых данных.

Избыточный формат данных.

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

firstName=Brett
lastName=McLaughlin
email=brett@newInstance.com

Сравним его с абсолютно такими же данными в формате XML:

<?xml version="1.0"?> 
<config-data> 
   <firstName>Brett</firstName> 
   <lastName>McLaughlin</lastName> 
   <email>brett@newInstance.com</email> 
</config-data>

Как видим, XML файл содержит значительное количество вспомогательных данных, введенных для удобства XML. Это означает, что в этом случае мы предпочли XML технологию производительности (чтение меньшего объема данных занимает меньше времени и наоборот).

API для обработки XML.

В дополнение к значительному объему служебных данных в XML файле вам потребуется дополнительное программное обеспечение для его обработки и чтения. Для этого вы можете написать свой XML парсер или же использовать один из многих уже реализованных для разных платформ. Таким образом, вам потребуется добавить одну или несколько дополнительных библиотек к вашему проекту и изучить их API.

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

Цена гибкости

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

Вполне вероятно, что существуют и другие веские причины использования XML файлов для описания конфигурационных данных, однако я не буду излагать здесь размышления о них. Взамен предлагаю вам обратиться к [Ресурсам], посетить форум по Java XML технологиям и поделится своими мыслями о возможных преимуществах использования XML для представления конфигурационных данных. Мне будет интересно послушать вас.

XML как формат передачи данных.

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

Передача данных внутри приложения.

Одним из наиболее популярных вариантов использования XML является его использование в качестве формата передачи данных между компонентами приложения. К сожалению, в то же время этот вариант является одним из худших примеров использования XML для передачи данных.

При передаче данных в одном и том же приложении вы сталкиваетесь с теми же недостатками, которые описывались при рассмотрении XML как формата описания конфигурационных данных: избыточность, большие объемы файлов, необходимость использования дополнительных библиотек. При этом выгода от использования XML не велика. В большинстве случает, более эффективным решением является отправка сериализованых данных или объектов. Этот подход, как правило, более быстрый, так как объем передаваемых данных меньше, декодирование данных при получении достаточно просто.

Обмен данными между приложениями.

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

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

Заключение.

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

Ресурсы.

Дискуссионный форум по XML.
DeveloperWors - широкое разнообразие статей, заметок, руководств, стандартов по XML.

(Автор: Бреет МакЛокхин, 20 февраля 2007 года. Оригинал сатьи: «XML and Java technology: What's XML really good for?»)

Что такое Tomcat?

noreply@blogger.com (Andriy Sholokh) — Sun, 24 Feb 2008 10:45:00 +0000

Что такое Tomcat и к какой категории сред для разворачивания Java приложений он относится.

Когда Java разработчики рассматривают серверы приложений, одним из первых упоминается Tomcat. Он применяется как достаточно простая среда для разворачивания Java приложений, и в большинстве своем подпадает под критерии сервера приложений, хотя реально является Web-сервером. В данной статье Джеф Хенсон затрагивает вопрос о том, является ли Tomcat сервером приложений. Для начала, объясняется разница между сервером приложений, веб-сервером и контейнером Java EE. После этого определяется, к какой из категорий сред разворачивания Java приложений относится Tomcat.

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

В этой статье я попытаюсь ответить на вопрос, является все же Tomcat сервером приложение или нет. Начну с пояснения различий между сервером приложений, веб-сервером и контейнером Java EE, после чего рассмотрю несколько сценариев, при которых веб-сервер Tomcat может быть использован как сервер приложений.

Java Enterprise Edition

Платформа Java Enterprise Edition, или Java EE, де-факто является стандартом разработки серверных Java приложений. Соответствие стандарту Java EE является основным фактором, определяющим разницу между веб-сервером и сервером приложений.

Стандарт Java EE расширяет платформу Java Standard Edition (Java SE) добавляя поддержку веб-сервисов, модели бизнес компонентов, API управления, коммуникационных протоколов, распределенных и веб-приложений. Замечу, что веб-приложения являются лишь частью того, что описывает Java EE.

Стандартный Java EE сервер приложений должен поддерживать такие технологии как EJB (сервер и контейнер), JNDI, JMS (Java Message Service), JTA (Java Transaction API), архитектуру J2EE Connector. Java EE задает контейнеры для серверных приложений, сервлетов, EJB компонентов. Такие контейнеры предоставляют функциональность, позволяющую устанавливать, сохранять и выполнять поддерживаемые компоненты.

Java EE также предоставляет стандартную архитектуру для взаимодействия Java EE приложений и серверов приложений с гетерогенными корпоративными информационными системами, такими как ERP-системы, мейнфреймы, системы баз данных и т.д. Архитектура Java EE Connector предоставляет средства взаимодействия с корпоративными системами используя стандартный интерфейс, известный как адаптер ресурсов (Resource adapter).

На рисунке 1 показаны уровни и компоненты типичной архитектуры Java EE приложения.

Рисунок 1 - Типичная архитектура Java EE приложения.

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

Например, большинству Java веб-приложений необходим для работы лишь ограниченный набор технологий, таких как сервлеты, JSP, JDBC. Именно поэтому многие разработчики выбирают Tomcat как сервер приложений Java EE, поддерживающий указанные технологии.

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

EAR, WAR, JAR и Java EE

Приложение Java EE может состоять из нескольких компонентов, таких как, например, EJB, веб-модули, адаптеры ресурсов, клиентские модули J2EE. Каждый из компонентов может иметь свой дескриптор развертывания – XML файл, описывающий компонент. Для разворачивания Java EE компонентов применяется файл в формате «Java архив» (JAR), который расширяется несколькими дополнительными форматами в зависимости от того или иного типа компонента. Формат JAR основан на формате ZIP.

JAR файл может содержать Java классы, XML файлы, вспомогательные ресурсы, статические HTML файлы и другие. Стандартное Java веб-приложение разворачивается в WAR (Web Application Archive) файле, который является JAR файлом с расширением WAR. Стандартное Java EE приложение разворачивается в EAR (Enterprise Application Archive) файле, который является JAR файлом с расширением EAR.

WAR файл - это специализированный JAR файл, содержащий такие компоненты веб-приложения как сервлеты, JSP файлы, HTML файлы, дескрипторы развертывания, библиотеки классов и тому подобное. WAR файл может быть развернут на веб-сервере, таком как Tomcat.

EAR файл – это специализированный JAR файл, содержащий компоненты Java EE приложения, такие как веб-приложения (WAR), EJB, адаптеры ресурсов и так далее. Файл EAR может быть развернут на сервере приложений Java EE, таком как JBoss, WebLogic или WebSphere. Сервер приложений Java EE загружает EAR файлы в процессе выполнения и устанавливает обнаруженные в нем компоненты на основе инструкций, описанных в дескрипторе развертывания каждого компонента.

На рисунке 2 показаны компоненты, часто встречающиеся в Java EE приложении.

Рисунок 2 - Компоненты типичного Java EE приложения.

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

Веб-приложения и корпоративные приложения

Очень часто определение того, что такое Tomcat, связано с вопросом о том, в чем разница между корпоративным приложением и веб-приложением. Традиционно, корпоративное Java EE приложение определяется как набор следующих компонентов и технологий:

EAR файлы
Java сервлеты
JavaServer Pages или JavaServer Faces
Enterprise JavaBeans (EJB)
Сервисы аутентификации и авторизации (JAAS)
Архитектура J2EE Connector
JavaBeans Activation Framework (JAF)
JavaMail
Java Message Service (JMS)
Java Persistence API (JPA)
Java Transaction API (JTA)
The Java Management Extensions (JMX) API
Java API for XML Processing (JAXP)
The Java API for XML-based RPC (JAX-RPC)
The Java Architecture for XML Binding (JAXB)
The SOAP with Attachments API for Java (SAAJ)
Java Database Connectivity (JDBC) framework

В свою очередь, веб-приложение Java объединяет подмножество компонентов и технологий корпоративного приложения, таких как:

WAR файлы
Java сервлеты
JavaServer Faces или JavaServer Pages
Java Database Connectivity (JDBC) framework

Популярные Фреймворки, такие как Apache Struts, Spring, Hibernate и другие стирают традиционную грань между корпоративными приложениями и веб-приложениями. Каждый фреймворк предлагает свою точку зрения на то, как решить ту или иную задачу. Каждый фреймворк пытается более эффективно решить те или иные сложности, возможно используя набор дополнительных технологий.

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

Сценарии Java EE приложения

В типичном Java EE веб-приложении HTML клиент отправляет запрос серверу, где этот запрос обрабатывается веб-контейнером сервера приложений. Веб-контейнер вызывает сервлет, который сконфигурирован для обработки определенного контекста запроса.

Начальный запрос HTML клиента проиллюстрирован на рисунке 3.

Рисунок 3 – Начальный запрос HTML клиента.

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

Рисунок 4 – Бизнес сервисы или компоненты в JEE архитектуре.

Некоторым бизнес сервисам или компонентам требуется доступ к хранилищам данных или информационным системам. Как правило, для этих целей вводится дополнительный слой абстракции между бизнес-сервисами и хранилищем данных, что позволяет сделать максимально безболезненным возможное изменение источника данных в будущем. При этом объекты доступа к данным (DAO) представляются отдельными компонентами (рисунок 5).

Рисунок 5 – Использование DAO объектов бизнес сервисами для доступа к хранилищу данных.

Когда обработка запроса на сервере завершена, HTML клиенту возвращается ответ в определенном формате. Этот процесс показан на рисунке 6.

Рисунок 6 – Ответ возвращается HTML клиенту.

Сценарий, проиллюстрированный на рисунке 6, может быть реализован с использованием ограниченного набора Java EE технологий, таких как, например, сервлеты, JDBC, JSP и тому подобные. Tomcat как и другие веб-серверы, предоставляющие среду выполнения сервлетов и JSP, вполне могут быть использованы как серверы приложений для данного сценария.

Увеличение сложности

Теперь предположим, что добавляется новое требование к приложению, которое заключается в необходимости реализации асинхронного обмена сообщениями между бизнес компонентами. В Java системах это как правило реализуется средствами Java Message Service (JMS) как показано на рисунке 7.

Рисунок 7 – Управление асинхронным обменом сообщениями между бизнес компонентами средствами JMS.

Большинство веб-серверов не предоставляют JMS как стандартный элемент, однако достаточно просто добавить реализацию JMS на веб-сервер. Таким образом, сценарий приложения, проиллюстрированный на рисунке 7, может быть реализован, опять таки, лишь средствами веб-сервера с задействованием дополнительных сервисов.

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

Рисунок 8 – JCA предоставляет средства взаимодействия между бизнес компонентами и корпоративными информационными системами.

Теперь архитектура по сложности подходит для сервера приложений JAVA EE. Веб-сервер такой как Tomcat мог быть применен для данной ситуации при использовании дополнительных средств. Однако сложности управления и мониторинга такой сложной смешанной системы, не позволяют судить о целесообразности такого подхода.

В конце концов, на рисунке 9 представлена сервис-ориентированная архитектура средней сложности, использующая, наряду с уже рассмотренными технологиями, такие технологии как EJB и веб-сервисы.

Рисунок 9 - Сервис-ориентированная архитектура средней сложности.

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

Использование Tomcat как сервера приложений

Как показывает рассмотренный выше пример, Apache Tomcat может быть использован как сервер приложений, особенно для несложных Java EE веб-приложений. Tomcat в большинстве своем применяется Java разработчиками. Свою популярность он завоевал благодаря простоте использования и поддержке различных технологий, принятых считаться стандартными для окружения Java веб-приложений. Среди таких технологий: JNDI ресурсы, источники данных JDBC, поддержка JSP, репликация сессий, поддержка виртуального хостинга, поддержка кластеризации, JMX и мониторинг. Tomcat также популярен среди Java разработчиков тем, что имеет достаточно конкурентоспособную производительность как сервер.

В Tomcat версии 6 добавлены некоторые новые возможности, такие как обработка асинхронных HTTP запросов, разделение потоков, улучшенное JMX управление и мониторинг, сервлеты версии 2.5 и JSP 2.1.

Но даже, несмотря на новые возможности, Tomcat не в полной мере поддерживает стандарты Java EE. В нем всё еще отсутствует поддержка распределенных транзакций, EJB, JMS. Для приложений, требующих эти компоненты, требуется разворачивание таких серверов как JBoss, Geronimo, WebLogic, WebSphere или Glassfish. Следует отметить, что многие серверы приложений Java EE используют Tomcat как веб-контейнер.

Заключение

Формальные различия между серверами приложений Java EE и веб-серверами понятны, но реальные различия менее очевидны. Хотя Tomcat нельзя в полной мере назвать сервером приложений, он, как показала эта статья, до определенной степени успешно применим в данной роли.

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

Об авторе

Джеф Хенсон (jeff@jeffhanson.com) обладает более чем 20-летним опытом разработки программного обеспечения, включая работу ведущим разработчиком проекта Windows OpenDoc и главным архитектором платформы Zareus SOA. Автор большого числа статей, книг, он является главным архитектором компании Max Software Inc., где руководит командами разработчиков клиентского и серверного программного обеспечения на языках C++, PHP и J2EE.

(Автор: Джеф Хэнсон, Дата: 22/01/2008. Оригинал статьи: «Is Tomcat an application server?. By Jeff Hanson»).

Будущее - это настоящее. Java разработка в 2008 году.

noreply@blogger.com (Andriy Sholokh) — Thu, 14 Feb 2008 21:34:00 +0000

Что прошедшие 12 месяцев говорят о грядущем годе?

Прошедший 2007-й год был отмечен развитием динамических языков, эволюцией JVM в сторону открытия исходного кода, ростом компании Google, являющейся стратегическим участником сообщества Java. Вопрос в том, что всё это может нам сказать о наступившем годе? Эндрю Гловер имеет несколько ответов для Java разработчиков, желающих знать уже сейчас, что готовит нам новый, 2008-й год.

Французский поэт Пол Валери однажды сетовал на то, что "проблема наших времен в том, что будущее не является тем, чем принято его осознавать". Этот комментарий Валери был произнесен много лет назад, но он всё еще актуален для тех из нас, кто живет в эпоху Интернета, движимого развитием платформы Java.

Немногим более чем за одно десятилетие ми увидели развитие и закат Java-апплетов. Стали свидетелями появления таких технологий как JSF, Spring, Struts, и переопределения Java одновременно в язык программирования и платформу. Платформа Java разделилась на три составляющие: Standard, Enterprise и Micro, а JDK была представлена сообществу разработчиков свободно распространяемого программного обеспечения. Язык Java был расширен аннотациями, перечислениями, развитыми коллекциями и многим другим. Его ядро, Java Runtime Edition (JRE), используется новыми динамическими языками, такими как Groovy, JRuby, Rhino и другими. Фактически, если проследить тенденции в особенности последних лет, можно отметить, что Java трансформировалась из языка программирования в настоящую платформу.

Что мы узнали за последнее десятилетие, так это то, что Java представляет собой намного большее, нежели язык программирования или платформу – это сообщество. Это экономическая экосистема. Это живущая, дышащая сущность, которая повзрослела и выросла в истинное эльдорадо для приложений различного уровня и сложности. Вместо того чтобы пытаться предсказать будущее развития Java, я предлагаю взглянуть на основные события и тенденции прошедшего года, обобщив которые мы сможем узнать, что же нас ждет в новом 2008 году.

Безмятежные дни.

Год 2007-й выдался чем-то вроде американских горок, где наиболее впечатляющими моментами были: возрастающий интерес к динамическим языкам, эволюция JVM в сторону открытия исходного кода, ростом корпорации Google, являющейся стратегическим участником сообщества Java. Кроме того, отмечалось более широкое применение Unit-тестирования, непрерывной интеграции (Continuous integration) и других техник быстрой разработки, что говорит о том, что Java-разработчики всё чаще видят свое ремесло как профессию, требующую подотчетности и результативности. Мы, в конце концов, начинаем обращать наше внимание на качество нашего кода и его жизнеспособность.

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

Динамические языки достигли совершеннолетия.

Важной вехой развития языка Groovy стал 2007-й год, когда увидели свет его версии 1.0 и 1.5. Пройдя путь продолжительностью в 5 лет, Groovy позиционировался как дополнительный язык к JRE, но не замена Java.

Основным преимуществом Groovy является лаконичность его синтаксиса, который упрощает каждодневные задачи программирования. К примеру, открытие и чтение файла является достаточно громоздкой конструкцией, описанной на языке Java:

try {
   BufferedReader in = new BufferedReader(
      new FileReader(path));
   String line;
   while((line = in.readLine()) != null){
      System.out.println(line);
   }
   in.close();
}catch(IOException e){
   System.err.println("Exception reading");
}

Та же самая функциональность в Groovy может быть реализована значительно проще:

new File(path).eachLine{ line ->
println line
}

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

Язык Groovy был не единственным игроком среди динамических языков в 2007 году. Платформа Java 6, выпущенная в 2006 году, представила стандартные API для взаимодействия с динамическими языками. Наиболее популярной реализацией данного API стал язык Rino. Хотя новшества и заинтересовали разработчиков, дальнейшее развитие этого подхода будет после выхода в свет Java 7.

Следует также отметить язык JRuby. Как и Groovy, JRuby (который позволяет Ruby программам выполнятся на JVM и взаимодействовать с Java объектами) упрощает Java разработку, позволяя применять более гибкий и изысканный синтаксис. К примеру, Ruby позволяет усовершенствовать существующие объекты. В Java проверка того, является ли строка пустой, может быть реализована следующим образом (показана реализация метода isBlank() в библиотеке Apache commons-lang):

public static boolean isBlank(String str) { 
   int strLen; 
   if (str == null || (strLen = str.length()) == 0) { 
      return true; 
   } 
   for (int i = 0; i <> 
      if ((Character.isWhitespace(str.charAt(i)) == false)) { 
         return false; 
      } 
   } 
   return true; 
}

Класс String в Java является final и потому не может быть переопределен для модификации или добавления новой функциональности (например, добавления метода isBlank()). Поэтому приходится полагаться на стороннюю библиотеку, такую как common-lang. В Ruby Вы можете определить нужный метод isBlank() в самом объекте String:

class String
def blank?
empty? || strip.empty?
end
end

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

Открывая сердце.

Развитие Java в сторону открытия исходного кода означает то, что эволюция Java платформы больше не зависит только от инженеров Sun. Теперь каждый из нас может внести свою посильную лепту в развитие проекта OpenJDK, создаваемого по GPL лицензии, охватывающего библиотеки классов Java, компилятор и даже виртуальную машину.

Открытость Sun, на самом деле, началась не с проекта OpenJDK. Glassfish – сервер приложений с открытым кодом от Sun, в 2007 году продолжил расширение своей аудитории. За последнее время невозможно не упомянуть приобретение компанией Sun компании, стоящей за MySQL, которая возможно доминирует среди СУБД с открытым кодом.

Все эти шаги могут говорить о всеобъемлющей бизнес модели, предложенной компанией Sun, которая подразумевает развитие программного обеспечения в сторону открытия исходного кода. На основании этого можно сделать вывод, что в 2008 году нас ожидают последующие шаги в сторону открытости Java платформы.

Развитие Google.

В конце 2007 года мобильные технологии Java от Google, которые уже, казалось, достигли апогея своего развития, получили новый импульс в виде представленной платформы Android. Ее целью является превознести на новый более качественный уровень программные приложения, выполняемые на мобильных устройствах, работающих на основе операционной системы с открытым кодом. Так как Android представляет собой целостную платформу (как Java), SDK для разработки приложений на его основе реализовано на Java.

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

Однако влияние Google на Java началось немногим ранее создания мобильных платформ. Особенный интерес вызвал проект Guice, фреймворк, являющийся аналогом Spring, построенный на аннотациях и обобщених Java 5. В отличии от Spring Guice предложил новшество отказавшись от XML файлов, используя при этом аннотации и собственные типы Guice – Modules.

В новом 2008 году следует ожидать дальнейшего развития этого IOC-фреймворка нового поколения от Google.

Развитие Agile разработки. Тестирование.

Термин Agile не нов, ровно как не новы unit-тестирование и непрерывная интеграция (continuous integration). Однако 2007 год стал годом, когда эти практики получили еще более широкое распространение. Практически ни одна конференция не обходилась без хотя бы одной или двух презентаций, посвященных Agile разработке. Всё чаще разработчики программного обеспечения обращают внимание на то, насколько созданная ими архитектура доступна для тестирования. Можно сказать, что наконец-то, тестирование разработчиками имеет место быть.

Растущие достижения Java.

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

Однако некоторые возможности приветствуются, а некоторые нет. К примеру, аннотации стали очень популярны среди разработчиков – их используют такие фреймворки как JUnit4, TestNG, Spring. Иначе обстоят дела с обобщениями (generics), которые не завоевали достаточной популярности.

В ожидаемом релизе Java 7 ожидается наличие пакетов java.util.concurent в задачи которого входит поддержка параллелизма на аппаратном уровне. Хотя Java всегда поддерживала потоки, поддержка их на аппаратном уровне оставалась нереализованной. Поэтому развитие Java направлено в сторону решения этой задачи.

Путь к RIA.

В прошедшем году большой интерес разработчиков продолжили вызывать RIA (Rich Internet Applications), особенно после того как компания Sun презентовала семейство программных продуктов JavaFX, включающее в себя на данный момент JavaFX Script и JavaFX Mobile компоненты.

Многие представители Java сообщества высказывали мнения, что выпуск JavaFX выдался поспешным и будущее у этого продукта отсутствует. Однако компания Sun дала уверенные сигналы о том, что имеется четкая долгосрочная стратегия развития RIA JavaFX, а это в свою очередь повысило оптимизм по отношению к данному продукту.

Заключение.

Африканская пословица гласит о том, что «завтра принадлежит тем, кто готовится к нему сегодня». Таким образом, можно сказать, что будущее Java по крайней мере на ближайший год уже сформировано. Обещание применения Java технологий для разработки мобильных приложений видится достаточно правдоподобным ввиду появления на свет таких продуктов как Android от Google и JavaFX Mobile от Sun. Многие из нас также с нетерпением ожидают Java 7 и ее поддержки мультипроцессорных систем на аппаратном уровне. Наконец, развитие Java как продукта с открытым исходным кодом приведет к дальнейшему росту бизнес моделей, основанных на данной концепции.

(Автор: Эндрю Гловер, Дата: 24/01/2008. Оригинал статьи: «The future is now -- Java development in 2008. By Andrew Glover»).

Добро пожаловать в мир Java.

noreply@blogger.com (Andriy Sholokh) — Sun, 10 Feb 2008 21:06:00 +0000

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

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