Java *

Наконец-то вышла финальная версия Google Collections Library.Это библиотека коллекций, по сути дополняющая стандартные коллекции.
Что есть в Google Collections?

• Дополнительные типы коллекций Multimap, Multiset, BiMap
• Также есть неизменяемые типы коллекций, которые удобны в многопоточных программах
• Классы утилит для Списков, Множеств и Карт
• И многое другое…

Советую использовать эту библиотеку, для того чтобы не создавать свои велосипеды.
Видеоуроки по использованию библиотеки
ссылка на проект

Думаю, что многие Java-разработчики знают или хотя бы слышали о методе String.intern(). Но далеко не каждый использует его в своих приложениях или представляет в каких случаях он полезен и полезен ли вообще. Так было и со мной до тех пор пока я не столкнулся с этим методом в одном из проектов. В тот момент я захотел узнать смысл и особенности его использования и набрел на одну весьма интересную статью ведущего разработчика Yahoo! по имени Ethan Nicholas, переводом которой теперь хочу поделиться с той частью Хабра-сообщества, которая не безразлична к языку Java.

Тем, кто знает об этом методе лишь понаслышке, добро пожаловать под кат.

Предыстория

Как-то раз мы решили создать свой собственный микроблоггинг с блекджеком и шлюхами c шахматами и поэтессами. Сначала сделали сайт, но быстро стало понятно, что для реализации идеи его недостаточно. Необходимо было работать с сообщениями через Jabber и ICQ.
Начали с простого — с джаббера. Никаких проблем тут не возникло — мы писали на Java, поэтому прикрутили Smack API и все заработало. Но, как это не печально, но самым популярным IM протоколом все еще является ICQ…

Задача

Итак, задача: залогиниться в ICQ, принимать и отправлять сообщения, понимать X-статусы, работать с кириллицей.

Рассмотрим пути решения.

На просторах сети вообще и хабра в частности мне доселось видеть не один топик посвящённый 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. Поэтому дальше я расскажу как использовать этот сервис (или любой другой) максимально эффективно и может для кого-то, это подкинет интересные идеи на будущее.