Основные источники информации по Java

Основные источники информации по Java

С момента представления в 1995 г. Java-платформы как единого целого мира, Java прошел радикальный эволюционный путь от концепции “апплеты повсюду”, которую исповедовали первые идеологи и приверженцы. Вместо этого мир Java развился до Swing, сконцентрировался вокруг сервлетов, направил движение к J2EE, споткнулся на EJB, нашел обходной путь через Spring и Hibernate, добавил возможности абстрактного программирования и стал более динамичным, а затем и более функциональным, и продолжает развиваться во множестве интересных направлений, в то время как я пишу эту статью.

Это многообразие может несколько озадачить Java-программиста, если он не рос и не развивался профессионально вместе с данным языком все эти годы.

Практическая автоматизация: Принципы автоматизации развертывания приложений, часть 2

Практическая автоматизация: Принципы автоматизации развертывания приложений, часть 2

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

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

Принцип удаленного развертывания, гарантирующий взаимодействие с несколькими удаленными серверами с центрального компьютера или кластера.

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

Groovy на практике: Взгляд на Groovy как на DSL для Java-разработчиков

Groovy на практике: Взгляд на Groovy как на DSL для Java-разработчиков

Эндрю Гловер (Andrew Glover) начал писать о Groovy для сайта developerWorks еще в 2004 г. Первой в свет вышла статья Почувствуйте Groovy в серии alt.lang.jre, которая была продолжена длинной чередой статей под общим названием Groovy на практике. В те времена еще не было выпущено ни одной книги по Groovy (сейчас их уже более десятка). Более того, до выхода Groovy 1.0 оставалось еще несколько лет. В общем, многое успело измениться с тех пор, как в 2006 г. на сайте developerWorks была опубликована последняя статья из серии «Groovy на практике».

В настоящее время количество загрузок дистрибутива Groovy в Интернет достигло примерно 35 тыс. копий в месяц. Приложения компаний, отличающихся своей консервативностью, например Mutual или Omaha, уже включают более 70 тыс. строк кода на Groovy. Список рассылки, относящийся к Groovy, является одним из наиболее популярных на сайте Codehaus.org, на котором и размещается проект Groovy (см. раздел Ресурсы). Groovy уступает по количеству загрузок и популярности списка рассылки только одному проекту: Grails – инфраструктуре для разработки Web-приложений, причем она написана на Groovy (см. раздел Ресурсы).

Язык Java годен только для аплетов и Интернета

Язык Java годен только для аплетов и Интернета

Java неразрывно связывают с аплетами. И действительно, аплеты — неотъемлемая часть как языка, так и платформы Java в целом. К тому же их создание — удачный маркетинговый шаг Sun. Без аплетов мир о Java не узнал бы так быстро.

Идея встраиваемых приложений в гипертекстовые документы (HTML) не так уж и нова. Многие фирмы пытались продвинуть свои технологии на этот сектор рынка, но в настоящее время конкурентов у Java здесь немного. На сегодня это, пожалуй, JavaScript, ActiveX и технология Flash. Две последние, правда, работают только под управлением Windows.

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

Java работает везде одинаково

Java работает везде одинаково

“Создаешь один раз — используешь где угодно” (“Write once — run anywhere”). Вторая часть этого лозунга создателей Java содержит утверждение, что Java-программа работает везде одинаково. К сожалению, в действительности все не так просто. Java-машины различных компаний на различных платформах НЕ стопроцентно совместимы друг с другом.

Отличия в работе Java-машин на разных платформах существуют и в реализации мультизадачности, и в работе оконной библиотеки (AWT). Сложные Java-программы необходимо “прогонять” на разных платформах, чтобы убедиться, что все в порядке. Вообще говоря, даже и на одной платформе, но на разных машинах, подобные программы могут выполняться по-разному.

Например, программист может столкнуться с ситуацией, когда его код на многопроцессорной машине ведет себя иначе, чем на однопроцессорной. Особо следует упомянуть Java-машину, созданную компанией Microsoft (далее MS JVM). Она носит название Java не совсем законно (что было подтверждено недавним решением суда).

JiBX 1.2, часть 2. От XML-схемы к коду Java

JiBX 1.2, часть 2. От XML-схемы к коду Java

JiBX — это инструмент для установления соответствия между данными XML и объектами Java. JiBX давно известен как самый быстрый и гибкий способ установления соответствия между кодом Java и XML. Однако сложность этих определений соответствия и ограниченная поддержка все более широко используемых определений XML-схемы иногда расхолаживали пользователей. К счастью, в версии JiBX 1.2 сделано многое для решения этих проблем. Из этого руководства вы узнаете об использовании новых функций JiBX 1.2 для простой генерации кода Java из существующего определения XML-схемы и для чтения/записи XML-документов в соответствии со сгенерированными определениями схемы — и все это без необходимости вдаваться в детали определений соответствия JiBX. В первой части был описан обратный процесс преобразования кода Java в определения XML-схемы.

JiBX 1.2: Часть 1. От кода Java к XML-схеме

JiBX 1.2: Часть 1. От кода Java к XML-схеме

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

Разработка приложений для Java: Часть 1. Oтличительные возможности режима реального времени в Java

Разработка приложений для Java: Часть 1. Oтличительные возможности режима реального времени в Java

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

Практические советы по подготовке к экзамену SCJP 6. Цель SCJP

Практические советы по подготовке к экзамену SCJP 6. Цель SCJP

Целевая аудитория экзамена SCJP 6 программисты, желающие стать Certified Java Programmer (сертифицированными JAVA программистами). Экзамен SCJP 6 содержит вопросы проверяющие фундаментальные знания, для сдачи сертификационного экзамена Java от компании Sun.

Стать сертифицированным программистом может каждый. Экзамен SCJP показатель профессионализма в данном направлении, кто-то сдает исключительно для расширения своих знаний, кто-то идет на экзамен, потому что сертификат — обязательное требование работодателя. Главная цель SCJP сертификация фундаментальных знаний, опыта и умений каждого в области программирования на Java и Java платформы в целом. Для получения сертификата необходимо успешно сдать экзамен и для допуска к нему не обязательно наличие статуса Sun Certified Java Associate.

Все ли в порядке в Web-приложениях, которые хранят свое состояние в сеансе пользователя?

Все ли в порядке в Web-приложениях, которые хранят свое состояние в сеансе пользователя?

Несмотря на то, что в мире Java имеется много Web-инфраструктур, все они, прямо или косвенно, основаны на инфраструктуре Java Servlets. Java Servlets API предоставляет набор полезных возможностей, включая управление состоянием с помощью объектов HttpSession и ServletContext, которые позволяют приложению сохранять данные на протяжении нескольких запросов от пользователя. Однако для Web-приложений существует ряд тонких (и по большей части недокументированных) правил, регулирующих работу с совместно используемыми объектами, из-за которых во многих приложениях появляются трудноуловимые ошибки. В результате во многих Web-приложениях, хранящих свое состояние в сеансе пользователя, возникают запутанные ситуации и проблемы.