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 и связанных с ней технологий останется прерогативой коммерческой версии.

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

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-тестах.

Я с нетерпением жду когда уже выйдет релиз JDK 7. И меня, как, наверное, и любого java разработчика, интересует что же будет нового в релизе. Рассказ о новшествах в JDK 7 от Danny Coward (Главный архитектор клиентского ПО в Sun Microsystems) можно посмотреть тут.

Итак, основные нововведения платформы:

1. модульность;
2. кросс-языковость;
3. новый сборщик мусора;
4. NIO.2;
5. новые Swing API.

Joe Darcy (лидер проекта Project Coin из Sun) выложил окончательный список нововведений языка Java 7 (оригинал тут). Вот эти нововведения:

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

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

Такая техника широко применяется для реализации AOP, создания тестовых фреймворков, ORM. Особенно хочется отметить terracotta, продукт с красивой идеей кластеризации jvm и на всю катушку использующей модификации байт-кода. Эта заметка будет посвящена обзору структуры байт-кода, первой части этой сильной связки.

Приходилось ли вам разбирать выражение? Рисовать график функции по введенной с клавиатуры пользователем строке?

Согласитесь, занятие приносит больше головной боли, чем радости от результата. Возможно вы знакомы с библиотеками antlr или javacc, тогда вы отделаетесь малой кровью. Но приобретете хвост из некрасивых сгенерированных классов, который как можно быстрее скроете от посторонних глаз в самом дальнем пакете.

Написав вчера о cglib, я заметил в документации главу о модификации байт-кода. И само собой напрашивается вопрос, а можно ли в runtime заставить класс выполнять, то что очень хочется, а не то что хочет класс?

Большинство программистов знают о reflection, которая (она — рефлексия) упрощает добавление динамических возможностей в статические языки, такие как Java/C#. Однако reflection упрекают в том, что вызовы работают очень медленно — до 500 раз медленнее. Все же это можно c легкостью исправить — покажем в этой статье как сделать reflection-вызов таким же быстрым, как и прямой (direct) вызов.

Задача

За минимальное время написать HTTP сервер, который после запуска сможет корректно ответить браузеру и отдать простую HTML страничку (минимальное время, чтобы кода было мало, чтобы новичку вникать было проще).
У меня это заняло около 15 минут. Сервер вроде справляется с поставленной задачей.

Суть примера — показать что такое Socket, ServerSocket, InputStream, OutputStream, и Thread.

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

Не так давно в Яве не существовало стандарта, описывающего способ валидации данных. Каждый выкручивался как мог, писались (и пишутся) свои поделки а так же используются некоторые возможности широко распространенных сервисов как Spring или Hibernate. Наибольшей проблемой было то, что валидация могла быть реализована отдельно от предметной модели и быть редунданто расбросанной по фронт- и бэкэнду. Теперь, при помощи стандарта JSR 303: Bean Validation (практически это явлается стандартизированным валидатором Hibernate) становится возможным следовать принципу «Don't Repeat Yourself»: объявлять ограничения для данных прямо в предметной модели и валидировать данные где угодно, хоть на сервере, хоть в десктопном приложении.