Java *

Этот пост – отчет по результатам годового изучения платформы 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-объекты могут симулировать поведение бизнес-объектов и бизнес-логику, что иногда необходимо из-за сложности реального поведения»

Одна из самых популярных и удобных сред разработки для Джавы, IntelliJ IDEA, стала опен-сорсной.

Начиная с со следующей версии (9.0), IntelliJ IDEA будет выходить в двух версиях: Community Edition и Ultimate Edition. В бесплатной версии, выпускаемой по лицензии Apache 2.0, будет полная поддержка Java SE, Groovy и Scala, а поддержка Java EE и связанных с ней технологий останется прерогативой коммерческой версии.

Подробная информация — в официальном блоге.

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

Итак, условие:
Необходимо реализовать ОДНИМ выражением Java (конечно же, используя только стандартные библиотеки) задачу по капитализации слов произвольной строки.

То есть, что-то вроде этого:
String strOrig = "строка с большим количеством слов";
String strRes = <.. тут какое-то выражение ..>;
assert strRes.equals("Строка С Большим Количеством Слов");

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

Результаты мозговой деятельности под катом

4 октября вышел релиз 3.0.0 интересного MVC фреймворка для java web-разработки V|Raptor.

Наткнулся я на него случайно, когда изучал детали реализации JForum, разработчики которого активно использовали VRaptor2 в качестве ядра для своего движка.

Поначалу мне он не показался чем-то особенным — какая-то бразильская (!) команда делает opensource проект, на сайте язык по умолчанию португальский, домен vraptor.org сразу редиректится на какой-то vraptor.caelum.com.br…

Я думаю на Хабре существует много разработчиков, которые так или иначе связаны с такой технологией как SWING. Недавно, я прочитал новость, означающую неопределенность его дальнейшего существования, и был удивлен, что здесь про это ничего не написали. Поэтому — читаем.

Привет всем. Хочу поделиться решением одной задачи, которая встала передо мной некоторое время назад. Состояла она в том, что было необходимо дать веб-сервису возможность получать доступ и обмениваться информацией с некоторым устройством (в моем случае карт-ридер) через COM-порт на компьютере пользователя. Для этого было решено использовать Java-апплет, и в процессе реализации возникало несколько затруднений, решение которых я и хочу описать в статье. Замечу, что в интернете мне не удалось найти единого руководства «от начала и до конца», как решить мою задачу, так что надеюсь, кому-нибудь моя статья может сэкономить несколько часов времени.

В бытность мою j2ee программистом, приходилось разрабатывать сайты с достаточно большим количеством страниц, использующие для визуализации ajax и прочие красивости. Контроллеры можно было протестировать при помощи JUnit и моковых запросов\ответов. Но для огромного количества ftl шаблонов и их JavaScript кода такой вариант не подходил.

Начиная с версии 1.4 в j2se появился package java.nio, который позволяет работать с сокетами в неблокирующем режиме, что зачастую повышает производительность, упрощает код и даёт дополнительные возможности и функционал. А начиная с версии j2se 1.6 на серверах под упралением ОС линукс(kernel 2.6) реализация класса Selector выполнена с использованием epoll, что обеспечивает максимально возможную производительность.

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

Про полезность подхода TDD (разработка через тестирование, test driven development) не слышал только ленивый или глухой. Но сегодня мы не будем обсуждать всю его полезность и красоту, а также проблемы и недостатки. Сегодня мы попробуем посмотреть, как разрабатывать unit-тесты для spring приложений. Также мы немного тронем ручное управление транзакциями в unit-тестах.