Java *

На просторах сети вообще и хабра в частности мне доселось видеть не один топик посвящённый Maven. И везде, где было обсуждение, возникали вопросы вида:

• Что даёт его использование в проекте типа X?
• Чем он лучше Ant/Make/sh?
• А что делать если я хочу использовать в проекте antlr/JAX-WS/XDoclet?

Я полагаю, что все эти вопросы происходят из незнания что на свете есть гугл недостаточного понимания что такое Maven и какой подход к решению задач build management он предлагает. Что в свою очередь растёт из недостаточного внимания, которое авторы статей уделяют идеям стоящим за xml-файлами и завораживающими консольными командами.

Ребята тут выложили программу подготовки слоя тайлов для API Яндекс.Карт

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

Выкладываю вместе с исходниками, программка написана на Java с использованием JAI и ImageIO.

Утилитку писал специально для Йоты вот для этой карты.

Коллектив SpringSource, недавно вошедший в состав компании VMWare, выпустил первый релиз новой ветки популярного Java-фреймворка Spring 3.0, выступающего в роли свободной альтернативы Enterprise JavaBeans. Исходные тексты Spring доступны в рамках лицензии Apache 2.0. Одновременно доступно обновление инструментария SpringSource Tool Suite, который теперь поддерживает всю новую функциональность Spring 3.0.

Основные новшества Spring 3.0:

• Полная оптимизация под Java 5: первое поколение Spring, требующее Java 5 или выше, синтаксис Java 5 применяется везде в Spring API и во всём коде реализации;
• Новый язык выражений SpEL (Spring expression language): парсер выражений ядра для использования в бин-определениях (bean definitions);
• Расширенная поддержка компонентов на базе аннотаций: ключевые возможности проекта Spring JavaConfig теперь доступны и в самом Spring;
• Мощная модель стереотипов: создание «коротких» аннотаций через использование мета-аннотаций;
• Стандартизованные аннотации с внедрением зависимостей (dependency injection): присутствие начальной поддержки пока не полностью готового стандарта JSR-330 для внедрения зависимостей в Java;
• Декларативная модель валидации на основе ограничивающих аннотаций;
• Расширенная поддержка связующих средств и средств форматирования;
• Глобальная поддержка архитектурного стиля REST;
• Прямое отображение объект/XML (OXM);
• Полная поддержка Portlet 2.0;
• Абсолютно новые возможности планирования: новые механизмы триггеров и TaskScheduler с первоклассной поддержкой cron;
• Поддержка Java EE 6.

Передо мной частенько вставала задача написать какой-нибудь Java-сервис. В качестве ОС мы используем по большей части линукс, так что удобнее всего управляться с такими сервисами — работать с ними как с демонами. То есть, запускаем:

start-stop-daemon --start --make-pidfile --pidfile /var/run/myservice.pid --exec /usr/bin/java — -jar myservice.jar

, и останавливаем:

start-stop-daemon --stop --quiet --oknodo --pidfile /var/run/myservice.pid

Команда --stop посылает JVM сигнал SIGTERM и сервис останавливается. Все как бы неплохо, JVM завершается в штатном порядке, если только вам не нужно выполнить по завершении работы сервиса какое-либо действие. Например явно освободить ресурс, или написать что-нибудь приятное в stdout.

Но все не так страшно, благо JVM начиная с 1.3.1 позволяет обрабатывать сигналы. За ответом как — под хабракат.

Одновременно с выходом NetBeans 6.8 состоялся выпуск финальной версии свободного (GPLv2 + CDDLv1.0) сервера приложений GlassFish v3. Позади остались более чем полтора года разработки и несколько «prelude»- и «preview»-релизов.

GlassFish v3 — первый сертифицированный сервер приложений, поддерживающий стандарт Java EE 6. Напомним, что недавно утвержденный стандарт Java EE 6 включает в себя:

• enterprise-технологии: EJB 3.1, JPA 2.0, JDBC 4.0, CORBA 3.0;
• Web-технологии: Servlet 3.0, JSP 2.2, JSTL 1.2, EL 2.2, JSF 2.0 (Facelets), RESTful web services;
• вспомогательные технологии: Java Contexts and Dependency Injection (JCDI; ex-WebBeans), Bean Validation

Отличительными чертами собственно GlassFish v3 можно назвать:

• микроядро на основе стандарта OSGi — обеспечивает старт сервера за считаные секунды;
• Grizzly/Comet — поддержка неблокирующих обработчиков web-запросов и ответов на основе Java NIO и NIO.2
• веб- и CLI-интерфейсы для управления и мониторинга;
• веб-интерфейс Центра Обновлений, при помощи которого можно установить дополнительные, не входящие в основную поставку компоненты, такие как JRuby/Rails, Groovy/Grails, jMaki AJAX Framework, серверный JavaScript

Отныне именно GlassFish является официальной reference implementation (RI) для новых веб-технологий от Sun, переняв палочку эстафеты у Apache Tomcat. Также доступен корпоративный вариант Sun GlassFish Enterprise Server v3, отличающийся в первую очередь наличием Enterprise Manager — системы мониторинга и управления набором GlassFish-серверов. Заявлена поддержка средами разработки NetBeans 6.8, Eclipse 3.5.1 и IDEA 9.

С небольшим опозданием вышла новая версия популярной среды разработки с открытым исходным кодом NetBeans.

Некоторые из нововведений:

• Поддержка Java EE 6;
• Поддержка JavaFX 1.2.1, улучшены возможности редактирования .fx-файлов;
• Новые возможности интеграции с kenai.com;
• Полностью поддерживается PHP 5.3;
• Поддержка Rails 2.3.4, усовершенствованный рефакторинг Ruby;
• Улучшен профайлинг C/C++: определение утечек памяти, «узких мест»;

И многое другое…
качаем тут

После публикации топика о Maven в комментариях возникли вопросы о том, как начать с ним работать, с чего начать, как составлять файлы pom.xml, откуда брать плагины и т.п. Данный топик будет своего рода getting started или f.a.q.

У Вас когда-либо случались такие ситуации, когда Ваше Java приложение трещит по швам? В моём случае это случилось из-за нехватки доступной оперативной памяти. И, естественно, обнаружилась нехватка в самый неподходящий момент: на носу очередной долгожданный релиз, один из серверов остановлен для обновления кода и данных и реинкарнация старого кода уже невозможна, в ближайшие дни запланировано несколько совещаний и собеседований, что сильно отвлекает от процесса оптимизации — в общем, ЧП не прошло незамеченным.

К слову сказать, сделай я правильный backup и экстренные работы по восстановлению жизнеспособности прошли бы гораздо более спокойно, но это была бы уже совсем другая история. Итак в моём распоряжении есть код, которому не хватает 15Gb оперативной памяти для нормального функционирования и очень длительный и дорогостоящий процесс запуска (около 5 часов), в ходе работы которого можно только сидеть со скрещенными пальцами и надеятся, что в этот раз заветные слова OutOfMemoryException не появятся в консоли удалённого сервера.
Не буду описывать всех ухищрений, которые пришлось проделать, чтобы восстановить остановленный сервер в течении трёх дней, но одним своим мини открытием поделюсь — boolean — это не тот тип данных, который Вы хотите использовать в высоконагруженных системах. Внимание вопрос:

Этот пост – отчет по результатам годового изучения платформы Java EE.
Он будет полезен мне своей отчетностью. Может быть пост будет полезен тем читателям хабра, которые задумали учить Джаву.

Проблема

Я — параноик. Кода я пишу код, я скрываю все переменные, методы и классы, которые только могу скрыть. Я стараюсь открыть лишь те методы и классы, которые необходимы.

Довольно часто, особенно при написании подсистем, скрыть те или иные методы и классы довольно непросто. Неприятности начинаются, кода подсистема достаточно большая, и для лучшей организации кода необходимо завести несколько под-пакетов.
Например, если есть класс com.system.InternalProperty, который используется и в com.system.persist.PropertyManager, и в com.system.network.PropertyUpdater, то InternalProperty должен быть объявлен public.

В этом посте я постараюсь рассказать о существующих решениях и предложить новую идею.

Введение

Для многих разработчиков Java часто является синонимом ужасно занудных корпоративных приложений. Она ассоциируется с многочисленными конфигурационными файлами формата XML, шаблонным кодом и т.д. Поэтому как правило вместо нее разработчики используют динамические языки (такие как Ruby, Python, PHP) для разработки своих проектов, особенно для простых утилит, мэш-апов и т.п.

Однако в среде Java многое изменилось за последние несколько лет. Появилось много фрейморков освобождающих разрабочика от бремени корпоративных («энтерпрайзных») приложений. Grails вероятно — один из лучших. Он основан на Groovy, динамическом языке на платформе Java. Groovy создан специально для Java-программистов и переход на него максимально безболезненый. Grails используе хорошо известные, надежные и эффективные библиотеки Java (Spring, Hibernate и т.п.) для выполнения всей тяжелой работы. Существует также система плагинов и плагины для почти для всех широко используемых библиотек Java.

В этом посте я раскажу, как сделать мэш-ап из Twitter'а и Google Maps в течении всего 20 минут. Конечный результат будет выглядеть примерно следующим образом:

Случилось так, что поставленная задача требовала применения удалённого вызова методов. Порывшись на Хабре, ничего не нашел по данному вопросу (хотелось что-нибудь почитать в качестве первого знакомства, перед чтением документации). Изучив спецификации на java.sun.com спешу поделиться с вами своей первой статьей. :)

«Что такое RMI?»

Remote method Invocation — механизм, который позволяет вызывать метод удалённого объекта. Согласно ему, все операции по подготовке и передаче данных инкапсулируются в вызываемом методе клиентского объекта-заглушки (stub). Сам же вызов метода ничем не отличается от вызова метода обычного локального объекта, за небольшим исключением:

• все параметры передаются по значению (т.е. копии объектов, а не ссылки на них, как это обычно происходит) — исправил ниже. Спасибо KonstantinSolomatov
• локальные объекты передаются по значению (копии)
• при передаче удалённого (Remote) объекта, если он экспортирован, передаётся stub этого объекта
• передаваемые объекты должны быть Serializable
• кроме всех прочих исключительных ситуаций, при вызове удалённого метода может возбуждаться исключение RemoteException (ошибки маршализации/демаршализации, передачи данных и другие возможные ошибки протокола)

Так же нужно отметить, что при вызове метода мы работаем с удалённым интерфейсом, а не с удалённым классом.

Фреймворк Java Server Faces достиг версии 2.0 и близок к официальному релизу в качестве одного из стандартов JEE 6 (выход ожидается в ноябре-декабре). Изменений, по сравнению с предыдущей версией (1.2), — масса, и многие возлагают надежды на то, что этот релиз будет также успешен и приветливо встречен, как в свое время EJB3, поскольку большинство нареканий к предыдущим версиям устранено, в стандарт вошли большинство перспективных и опробованных на практике наработок из таких фреймворков, как JBoss Seam, RichFaces, Pretty Faces и др.

Мы попробуем использовать эту технологию на Google App Engine — популярной облачной платформе.

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

17е обновление содержит в основном багфиксы, связанные с безопасностью. Вместе с ним вышло и 22е обновление для JRE 5, которое станет последним общедоступным в 5й ветке.
Страница загрузки
Прямая ссылка (windows, offline)

При разработке cloud платформы веб-приложений был реализован сервис серверной логики на базе java scripting технологии для более гибкого управления другими сервисами платформы.

Соответственно «стал ребром» вопрос контроля над порождением, жизнью и использованием ресурсов платформы дочерними потоками создаваемыми из скриптинга. Потоки через скриптинг могут создаваться всеми доступными способами. В GoogleAppEngine проблему дочерних потоков решили простым запретом их порождения. В нашем случае хочется иметь более гибкое решение. Поэтому необходимо иметь контроль над дочерными потоками создаваемыми из главного потока запроса.

Изначально предполагалось что задача тривиальна и что в Java есть стандартные для этого средства. Но ожидания не оправдались.

Компания Oracle объявила о своих планах относительно технологий Sun, доставшихся ей по наследству.

Ключевые моменты из письма на официальном сайте Oracle:

Oracle plans to accelerate investment in the Java platform for the benefit of customers and the Java community.
Oracle планирует увеличить инвестиции в платформу Java во благо коммерческих пользователей и сообщества.

— Spend more money developing SPARC than Sun does now.
— Тратить больше денег на разработку SPARC, чем тратит сейчас Sun.

— Spend more money developing Solaris than Sun does now.
— Тратить больше денег на разработку Solaris, чем тратит сейчас Sun.

— Spend more money developing MySQL than Sun does now.
— Тратить больше денег на разработку MySQL, чем тратит сейчас Sun.

— Dramatically improve Sun's system perfomance by tightly integrating Oracle software with Sun hardware.
— Значительно улучшить производительность систем, поставляемых Sun, путем интеграции ПО Oracle и аппаратного обеспечения Sun.

— Have more than twice as many hardware specialists selling and servicing SPARC/Solaris systems than Sun does now.
— Увеличить более чем вдвое количество специалистов продающих и обслуживающих системы SPARC/Solaris.

Так же обещана поддержка NetBeans, GlassFish, OpenOffice и прочих технологий и продуктов.

С документом можно ознакомиться по ссылке www.oracle.com/us/sun/038563.pdf

UPD: опоздал чуток, но немного больше информации перевел. Вот тут первый топик habrahabr.ru/blogs/Sun/73708

Довольно часто в жизни разработчиков встречаются ситуации «когда очень хочется, но нельзя». И очень часто этот вопрос решается, как все в нашей стране — «если очень хочется, то можно». Сегодня я хочу рассказать вам про мой опыт создания независимого API для web-проекта, который этот API не предоставляет. Статья будет полезна Java или Solaris разработчикам, а так же всем тем кто сталкивается с проблемой интеграции различных сервисов.

Не так давно для всех разработчиков был открыт проект SourceJuicer (http://jucr.opensolaris.org/), который позволяет публиковать свои проекты для OpenSolaris, проводить сборку и публиковать их в открытые репозитории. Описание проекта делается в виде spec-файла (http://jucr.opensolaris.org/help/spec_file), в котором перечислены атрибуты проекта, как его собирать, откуда скачивается исходный код, под какими лицензиями он распространяется и т.п. Все необходимые для сборки файлы загружаются на сервер и после review он будет собран и выложен в репозиторий. Вроде бы все классно, но в чем подвох? А подвох в том, что создавать проект и загружать или обновлять файлы можно только через web интерфейс. Что в принципе не так смертельно для небольшого проекта, но уже при 10-ти файлах этот процесс загрузки-обновления начинает несколько утомлять.

Кроме того такая система загрузки абсолютно не подходит для Continuous Integration — для чего в сущности и создавался SourceJuicer. Поэтому дальше я расскажу как использовать этот сервис (или любой другой) максимально эффективно и может для кого-то, это подкинет интересные идеи на будущее.

Проходящая сейчас (и почти уже закончившаяся) в Новом Орлеане конференция SpringOne 2GX — отличный повод поговорить о том, чем нас радовал SpringSource в последнее время и порадует в ближайшем будущем.

SpringOne 2GX — это ежегодная конференция, проводимой компанией SpringSource. Так как относительно недавно SpringSource стал счастливым обладателем технологий Groovy и Grails, в этом году конференции SpringOne и 2Gx решили объединить в одну.

Данный пост является продолжением статьи о байт-коде виртуальной машины Java, и мы считаем, что читатель имеет представление о его структуре. Наиболее распространенной библиотекой для модификации байт-кода является фрейморк ASM от object web. На нем построено большинство высокоуровневых библиотек, в частности cglib.

Библиотека ASM имеет два варианта API. Что бы лучше представить отличие между ними, проведем следующую аналогию. Класса это некое дерево. Корень его- сам класс. Переменные, методы, подклассы это его листья. Инструкции — листья методов. Таким образом можно провести параллель с XML и двумя типами его парсеров. Первый вариант Core API похож на SAX парсер. Когда нужно прочитать, создать или внести изменения, делается обход дерева представления класса. Второй вариант (Tree API) работает по прицепу DOM парсера. Сначала строиться дерево представления, а затем с ним производиться необходимые манипуляции. Очевидно, что первый вариант API менее ресурсоемкий, более подходящей для внесения небольших изменений. Второй требует больше ресурсов, но и дает более гибкие возможности. Мы рассмотрим только первый вариант API.

А Вы знаете что такое mock-объект? Нет?

Что же говорит по этому поводу википедия: «В объектно-ориентированном программировании mock-объект имитирует поведение реального объекта заданным образом… ». Казалось бы зачем? Википедия продолжает: «Во время unit-тестирования mock-объекты могут симулировать поведение бизнес-объектов и бизнес-логику, что иногда необходимо из-за сложности реального поведения»