Java *

Статья будет полезна всем, кому интересно узнать способ устранения ошибки LazyInitializationException при JAXB сериализации объектов, созданных при помощи Hibernate.
В конце статьи имеется ссылка на исходный код проекта, реализующего предложенное решение — использование custom AccessorFactory.

Для сравнения рассмотрено, как аналогичная проблема решена в популярном JSON-сериализаторе — Jackson.

Симону Риттеру удалось запустить JavaFX-приложение на платформе Raspberry Pi.

Для запуска он использовал коммерческую версию Open JDK для процессоров ARM. Пересобрать JavaFX ему не удалось (из-за лени, как он говорит) и он воспользовался непубличной сборкой JavaFX для платформы Beagle Board.

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

Эта статья — перевод первого туториала для проекта libGDX. Оригинал находится — здесь

От переводчика: недавно у меня появилось желание написать игру под Android. У меня есть некоторый опыт программирования на Java, но я почти не сталкивался с разработкой под Android. Тут я наткнулся на библиотеку libGDX, которая позволяет писать кросплатформенные игры. Также я наткнулся, что по ней не хватает русской документации, а конкретно — туториалов. Поэтому у меня появилось желание перевести туториалы. Это мой первый перевод, поэтому буду рад любым замечаниям и указаниям на неточности.

Настройка проекта

Примечание: есть проблемы с использованием Java 1.7 для Android-приложений. Убедитесь, что вы используете Java 1.6
Примечание: надо сделать несколько шагов для настройки приложения под Android. Смотрите ниже.

Эта статья описывает, как настроить Eclipse для разработки и запуска приложений как на настольном компьютере, так и на Android-устройствах.

Для написания программ, выполняющих параллельные вычисления, широко применяются потоки (threads). При том, что потоки позволяют достаточно гибко организовывать парраллелизм в программах, они обладают рядом недостатков. Дело в том, что потоки разделяют между собой память. Это значит, что очень легко по неосторожности нарушить целостность программы. Побороть это можно с помощью блокировок, которые позволяют некоторому коду получать эксклюзивный доступ к обшему ресурсу. Однако, сами блокировки, помимо того, что их нужно не забывать проставлять, порождают, в свою очередь, проблемы. Одна из самых страшных проблем — это возможность породить deadlock. Впрочем, даже без этого написание действительно хорошо работающей многопоточной программы превращается в ювелирный труд.

Но у потоков есть альтернативы. Из известных мне — модель акторов (actors) и software transaction memory. Героем этой статьи, как понятно из заголовка, являются первые. Впрочем, по STM есть достаточно много статей в интернете, которые удовлетворят ваше любопытство.

Измерение производительности Play Framework 2.0

Я уже рассказывал о программной платформе Typesafe Stack 2.0. В том посте шла речь об одном из компонентов платформы — фрэймворке Akka 2.0, реализующем модель акторов на JVM. Сегодня я хочу написать о возможностях другой составляющей Typesafe Stack — фрэймворке Play 2.0. Хотя о функциональности данного компонента уже рассказывали здесь и здесь, тема производительности решений под управлением Play 2.0 по-моему осталась не раскрытой.

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

Размеры объектов в Java уже обсуждались на Хабре, например, здесь или здесь. Мне бы хотелось подробнее остановиться на размерах многомерных массивов — простая вещь, которая для меня стала неожиданной.

Оптимизируя вычислительный алгоритм по памяти, я наткнулся на то, что при определённых (вполне разумных) входных параметрах создаётся массив float[500][14761][2]. Сколько он может занимать в памяти (на HotSpot 1.6.0_26 32bit, если кому интересно)? Я примерно прикинул, что 500*14 761*2*sizeof(float) = 500*14 761*2*4 = 59 044 000 байт плюс какой-то оверхед. Решив проверить, как на самом деле, я воспользовался Eclipse Memory Analyzer (невероятно волшебная вещь, рекомендую!) и обнаружил, что «Retained Heap» для этого массива составляет 206 662 016 байт! Неплохой оверхед — 350%. Посмотрим, почему так получилось.

Открою не Америку, но шкатулку Пандоры: в Java-коде много бойлерплейта. Типовые геттеры, сеттеры и конструкторы, методы ленивой инициализации, методы toString, hashCode, equals, обработчики исключений, которые никогда не выбрасываются, закрывалки потоков, блоки синхронизации. Проблема заключается даже не в том, чтобы написать всё это — современные среды разработки справляются с такими задачами нажатием нескольких клавиш. Сложность в поддержании бойлерплейта в актуальном состоянии по мере внесения модификаций в код. А в некоторых случаях (многопоточность, реализация методов hashCode и equals) и сам шаблонный код написать без ошибок — далеко не простая задача. Одним из решений проблемы является генерация кода, и в этой статье я расскажу про проект Lombok — библиотеку, которая не только может избавить вас от бойлерплейта, но и сделать это максимально прозрачно, с минимальной конфигурацией и, что немаловажно, с поддержкой на уровне среды разработки.

17-18 апреля 2012 года в Москве, в здании Российской Академии Наук прошла, уже вторая по счёту, конференция JavaOne/Oracle Develop. В прошлом году я посещал сие мероприятие и мне очень понравилось, поэтому приобрёл входной билет как только они появились в продаже. К слову, их минимальная стоимость выросла вдвое относительно прошлого года, но осталась вполне адекватной — 1 000 рублей.


Автор фото — Trukhin Yuri

На входе встречал известный Java-персонаж Дюк.

  В последнее время очень часто появляются фреймворки которые позволяют разработчику реализовывать функционал в свободном виде не прибегая к наследованию от интерфейсов. Примеры можно увидеть в таких как EJB 3, JUnit 4, JSF 2, Spring Framework 3 и т.д.
Под катом найдете обсуждение обоих подходов.

После полутора лет досудебных разбирательств, сотен рассмотренных документов с участием 75 адвокатов с обеих сторон, представители Oracle и Google сойдутся лицом к лицу в окружном суде Северной Калифорнии, чтобы выяснить, подлежат ли языки программирования защите копирайтом.

Столь кардинальную постановку предложил сам судья. В специальном запросе на прошлой неделе суд постановил, что Google и Oracle должны твёрдо разъяснить свои позиции по фундаментальному вопросу: «применимы ли законы о защите интеллектуальной собственности в отношении языков программирования». И компании уже предоставили свои ответы. В частности, компания Google высказалась чётко: «Нет, языки программирования не подлежат защите копирайтом. Компания Google всегда придерживалась такой позиции».

Перевод. Оригинал статьи http://in.relation.to/Bloggers/WhyIsJBossAS7SoFast. Статье скоро год, но вопрос все еще актуален.

Если кратко, то ответ следующий: потому что вся проектировка JBoss AS 7 строится на основе закона Эмдейла (эффективная параллелизация задач) в противоположность закону Мура (ждать железа с большей частотой процессора). Почти каждый процессор на вооружении настольных компьютеров, ноутбуков и серверов сегодня имеет не менее двух ядер, при чем тенденция быстро растет. Дни гонок за частотой процессора уже в прошлом. Так что, программам приходится адаптироваться, чтобы выжать все из того железа, что есть сейчас и будет завтра.

На сайте DZone собираются публиковать серию интервью о Java-стартапах.



Вот письмо одного из редакторов сайта:

Java-Стартапы - Мы хотим услышать о Вас!

Сейчас все помешаны на культуре стартапов которая стала модной в индустрии разработки ПО. Стартап Draw Something покупают за $ 200 млн, Facebook покупает Instagram за $ 1 млрд, постоянно происходит что-то новое. Но мы не видим, на каких технологиях базируются эти проекты. В ближайшее время будут опубликовано несколько интервью освещающих эту сторону стартапов.


Не так давно на Хабре был хороший пост посвященный проекту Spring Data-JPA.
Проект меня очень впечатлил, т.к. он предлагал хорошо продуманное решение для работы с репозиториями.
Собственные наработки на эту тему у нас имелись, однако Spring Data-JPA был намного более элегантным и функциональным решением.
Была одна загвоздка — проекты с которыми я работаю построены с применением Google Guice.
В свое время это был мой осознанный выбор и в целом он до сих пор устраивает как команды проектов, так и заказчиков.

… но концепция репозиториев от Spring Data-JPA была слишком вкусной…

Сегодня выпущен первый официальный «milestone» проекта Kotlin — современного языка программирования дла платформы Java, разработанного в компании JetBrains:

• Плагин для IntelliJ IDEA 11.1 можно установить из центрального репозитория (см. здесь).
• Компилятор можно скачать здесь.

Самые интересные изменения:

Без сомнения каждый, кто в своем резюме указывает опыт разработки на Java, хоть раз в жизни писал строки

public static void main(String[] args)

компилировал их и запускал на выполнение командой наподобие java HelloWorld.
Но многие ли знают, что происходит внутри JVM от момента выполнения этой команды до того как управление передается методу main, как Java находит и загружает необходимые пользователю классы? Возникшая однажды производственная задача заставила автора разобраться в этом вопросе. Результаты изысканий под катом. Сразу стоит оговориться, что статья не претендует на полноту охвата всех существующих JVM, тестирование проводилось только на Sun HotSpot JVM.

13 марта состоялся релиз второй версии scala/java-фреймворка Play. На хабре уже был обзор новых фич Play 2.0. В этой же статье я хочу восполнить пробел в отсутствии мануалов на русском языке по этому интересному фреймворку на примере создания простого приложения на Java, состоящего из списка категорий и привязанных к ним вакансий.

Статья рассчитана на тех, кто совсем не знаком с Play и хотел бы его «пощупать», не тратя много времени.

На сайте Oracle стала доступна для скачивания предварительная версия JavaFX Scene Builder:



Редактор предназначен для мышкоредактирования формочек под JavaFX. Рассмотрим что в нём есть:

Наверное многие из Вас работают с Maven. Если так, то полагаю каждый из Вас ежедневно собирает свой проект по несколько раз, особенно если Вы сейчас в активной фазе разработки и изменения затрагивают много модулей. В определенный момент времени проект становится довольно большим и билд с каждым днем начинает выполнятся все дольше и дольше… И вот приходит время, когда пора что-то с этим делать.

Мигрируйте с Maven 2 на Maven 3

Вы еще используете maven2? Странно. Одна только миграция на 3-ю версию может значительно ускорить процесс сборки. В моем проекте переход на Maven 3 дал прирост в скорости сборки на 10%. Вероятней всего за счет каких-то фиксов и оптимизаций, что были сделаны в новой версии (так как заявляют разработчики количество кода было существенно уменьшено и сильно отрефакторено). Миграция займет у Вас несколько минут и в большинстве случаев будет безболезненной. Хотя есть шанс, что некоторые конфигурационные файлы все же придется подправить.

Используем ядра и дополнительные потоки

В Maven 3 есть замечательная опция:

mvn -T 4 clean intall
mvn -T 2C clean install

В первом случае мы явно указываем, что хотим запустить процесс сборки на 4 потока. Во втором случае мы указываем, что на каждое ядро должно быть выделено по 2 потока для процесса сборки. Это одна из новых фич нового мавена — Parallel Builds. Эта фича анализирует граф зависимостей Вашего проекта
и распихивает модули по разным потокам, сборка которых может быть выполнена параллельно.
Для моего текущего проекта скорость сборки со вторым параметром (-T 2C) ускорилась на 20%. Правда тут есть один минус. Количество ресурсов, что будет потребляться для билда может значительно вырасти. В моем случае это +30% к потребляемой памяти.
Хочу сразу обратить внимание — если связанность модулей в Вашем проекте очень низкая — то
скорость сборки этой опцией можно увеличить на порядок.
Это, кстати, повод задуматься об Вашей архитектуре проекта. Ведь если билд занимает довольно много времени, то небольшой рефакторинг поможет уменьшить эту цифру. Хотя, конечно, это все очень индивидуально.
Вообще разработчики заявляют, что прирост в скорости сборки может быть 20-50%.