Java *

Решили поделиться своими наработками по реализации ВКонтакте API для Android. Данное SDK позволяет быстро авторизоваться и вызывать методы API, например отправить запись на стену, получить список друзей пользователя и многое другое. Изначально библиотека разрабатывалась как ядро проекта Kate Mobile. Совсем недавно пришла идея оформить часть кода в ощедоступную библиотеку. На скорую руку вынести её в отдельный проект и теперь она доступна всем желающим. Сейчас реализованы основные методы API, пополняем по мере необходимости. Будем улучшать на основании полученного фидбэка. Если он будет.

Представляю вашему вниманию перевод второго туториала по libGDX. Оригинал находится здесь. Первая часть находится здесь.

Этот туториал дает представление как рисовать изображения используя OpenGL и как libGDX упрощает и оптимизирует этот процесс с помощью класса SpriteBatch.

Рисование изображений.

Изображение, полученное из его оригинального формата (например, PNG) и загруженное в GPU называется текстурой. Текстуры рисуются по некоторой спецификации, которая представляет собой описание геометрической фигуры и каким образом текстура накладывается на вершины этой фигуры. Например, геометрическая фигура может быть прямоугольником и каждый угол прямоугольника относится к соответствующему углу текстуры.

На JavaDay в Питере мне задали вопрос: «Пригоден ли JavaFX для написания браузилок — небольших браузерных игр?» Мой ответ: «Да, конечно пригоден», — очевидно, нуждается в подтверждении. Этому и посвящена данная публикация.

В JavaFX 2.1 есть необходимые для такого рода приложений богатые возможности в области графики, анимации, поддержки медиа-контента. Для их использования не нужно изучать новый язык программирования, достаточно знания Java. API сравнительно небольшой. Разобраться в основных концепциях помогут слайды с моей презентации. Для всего остального есть Java community и множество доступных для языка Java библиотек.

Далее речь пойдет о развертывании приложения и добавлении его в социальную сеть ВКонтакте.

Для начала немного уточним о чем идет речь. Wicket хранит последнюю просмотренную страницу в сессии, но в случае если страница очень большая, иногда это может стать проблемой. Для того что бы избежать этих проблем, можно попытаться сделать страницу Stateless(т.е. не имеющую состояния).
Итак, Stateless page — это страница не имеющая состояния, Statefull page — это страница с состоянием.

Stateless страницы не хранят никакого состояния из-за чего нет необходимости сохранять их от запроса к запросу.
Такие страницы не сохраняются ни в сессии ни в истории посещённых страниц хранящейся на диске, таким страницам не присваивается версия, как это происходит со statefull страницами. При каждом запросе к такой странице, её экземпляр создаётся заново.

2 февраля 2012 года микроблоггерка, действующая под псевдонимом «Лоличка», попросила:

— Если уж вы произносите «Java» как «Ява», то будьте любезны говорить не «jazz», а «йаззь».

(Конец цитаты.)

Судя по более чем полусотне ретвитов, этот пример про джаз и язя (опирающийся на известный видеомем) получился наглядным.

Очевидно, он в той же мере касается и джаваскриптов.

Привет, Хабр!

С любезного разрешения сообщества Java-разработчиков JUG.ru мы публикуем видеозапись выступления Андрея Бреслава о новом языке программирования Kotlin для платформы Java, которое состоялось на встрече 26 апреля.

Статья будет полезна всем, кому интересно узнать способ устранения ошибки 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 была слишком вкусной…