После публикации топика о Maven в комментариях возникли вопросы о том, как начать с ним работать, с чего начать, как составлять файлы pom.xml, откуда брать плагины и т.п. Данный топик будет своего рода getting started или f.a.q.

Наверняка многие из вас сталкивались с проблемой хранения перечислений в базе данных, возникающей при попытке реализации удобного способа работы с разного рода служебными справочниками — статусами, типами объектов и так далее.

Суть её очень проста: если хранить перечисления как сущности (@Entity), то с ними получается крайне неудобно работать, база данных нагружается лишними запросами даже несмотря на кэширование, а сами запросы к БД усложняются лишними JOIN'ами. Если же перечисление определять как enum, то с ними становится удобно работать, но возникает проблема синхронизации с базой данных и отслеживания ошибок таковой синхронизации.

Особенно актуально это в том случае, когда поле, содержащее перечисление, аннотировано как @Enumerated(EnumType.ORDINAL) — всё мгновенно ломается при смене порядка объявления значений. Если же мы храним значения в строковом виде — как @Enumerated(EnumType.STRING) — возникает проблема скорости доступа, так как индексы по строковым полям менее эффективны и занимают больше места. Более того, вне зависимости от способа хранения значения поля при отсутствии в базе данных таблицы со списком допустимых значений мы никак не защищены от некорректных или устаревших данных и, как следствие, проблем.

Однако сама идея хранения в базе данных заманчива простотой построения запросов вручную, очень ценной при отладке ПО или решении сложных ситуаций. Когда можно написать не просто SELECT id, title FROM product WHERE status = 5, а, скажем, SELECT id, title FROM product JOIN status ON status.id = product.status_id WHERE status.code = 'NEW' — это очень ценно. В том числе и тем, что мы всегда можем быть уверены в том, что status_id содержит корректное значение, если поставим FOREIGN KEY.

На самом деле, существует очень простое и изящное решение этой проблемы, убивающее сразу всех зайцев.

На просторах сети вообще и хабра в частности мне доселось видеть не один топик посвящённый Maven. И везде, где было обсуждение, возникали вопросы вида:

• Что даёт его использование в проекте типа X?
• Чем он лучше Ant/Make/sh?
• А что делать если я хочу использовать в проекте antlr/JAX-WS/XDoclet?

Я полагаю, что все эти вопросы происходят из незнания что на свете есть гугл недостаточного понимания что такое Maven и какой подход к решению задач build management он предлагает. Что в свою очередь растёт из недостаточного внимания, которое авторы статей уделяют идеям стоящим за xml-файлами и завораживающими консольными командами.

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

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

Этот пост – отчет по результатам годового изучения платформы Java EE.
Он будет полезен мне своей отчетностью. Может быть пост будет полезен тем читателям хабра, которые задумали учить Джаву.

У Вас когда-либо случались такие ситуации, когда Ваше Java приложение трещит по швам? В моём случае это случилось из-за нехватки доступной оперативной памяти. И, естественно, обнаружилась нехватка в самый неподходящий момент: на носу очередной долгожданный релиз, один из серверов остановлен для обновления кода и данных и реинкарнация старого кода уже невозможна, в ближайшие дни запланировано несколько совещаний и собеседований, что сильно отвлекает от процесса оптимизации — в общем, ЧП не прошло незамеченным.

К слову сказать, сделай я правильный backup и экстренные работы по восстановлению жизнеспособности прошли бы гораздо более спокойно, но это была бы уже совсем другая история. Итак в моём распоряжении есть код, которому не хватает 15Gb оперативной памяти для нормального функционирования и очень длительный и дорогостоящий процесс запуска (около 5 часов), в ходе работы которого можно только сидеть со скрещенными пальцами и надеятся, что в этот раз заветные слова OutOfMemoryException не появятся в консоли удалённого сервера.
Не буду описывать всех ухищрений, которые пришлось проделать, чтобы восстановить остановленный сервер в течении трёх дней, но одним своим мини открытием поделюсь — boolean — это не тот тип данных, который Вы хотите использовать в высоконагруженных системах. Внимание вопрос:

При разработке cloud платформы веб-приложений был реализован сервис серверной логики на базе java scripting технологии для более гибкого управления другими сервисами платформы.

Соответственно «стал ребром» вопрос контроля над порождением, жизнью и использованием ресурсов платформы дочерними потоками создаваемыми из скриптинга. Потоки через скриптинг могут создаваться всеми доступными способами. В GoogleAppEngine проблему дочерних потоков решили простым запретом их порождения. В нашем случае хочется иметь более гибкое решение. Поэтому необходимо иметь контроль над дочерными потоками создаваемыми из главного потока запроса.

Изначально предполагалось что задача тривиальна и что в Java есть стандартные для этого средства. Но ожидания не оправдались.

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

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

Оригинальное название статьи: «The * stupidest things I’ve done in my programming job», поэтому перевод названия статьи не очень точен, однако то, что автор имел ввиду под "*" мы опустим — мы ведь не знаем наверняка :)

Я больше не стыжусь своих грешков, так что — вперед:

1. ORM

Глупость

Создал собственную ORM (Object Relational Mapping) библиотеку

Следствие

Неразбериха в проекте после двух лет поддержки, в следствие хаков-обходов моей ORM библиотеки для запуска прямых SQL запросов

Что я должен был сделать

Использовать Hibernate, iBATIS, Cayenne или нечто подобное.

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

Задача

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

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

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

Многие тесты на сертификацию Java программистов содержат большое количество вопросов с вариантами выбора. От таких тестов толку немного: многие вещи, касающиеся API можно быстро узнать чтением документации или исходников. При этом, умение программировать, которое состоит по большей части из умения правильно сформулировать алгоритм и логически мыслить, совершенно не тестируется.

Компания betterprogramming.com из Сан-Франциско решила исправить эту проблему. Тест, находящийся на их сайте, вместо множества вопросов предлагает решить несколько задач. Задачи заключаются в реализации несложных алгоритмов (уровня районной олимпиады по программированию, первого тура ACM ICPC или легких задач в topcoder). Текст программы, написанный разработчиком исполняется на сервере, и по его результатам а также по времени, ушедшем на прохождения теста, выставляется оценка.

Попробовать этот тест можно здесь: www.betterprogrammer.com

Java — язык простой. И после года активного использования для Вас не остаётся секретов. Совершенно случайно я обнаружил, что на stackoverfow люди решили поделиться скрытыми возможностями (Hidden Features of Java). Вышло очень занимательно, получился своеобразный рейтинг нетривиальных возможностей, который я далее запротоколирую в вольном переводе на русский.

double brace

С большим отрывом лидирует «double brace», уже обсуждавшийся ранее в статье Эффект «double brace» by zeroed. Подробное описание метода — 
http://www.c2.com/cgi/wiki?DoubleBraceInitialization
несомненно это самое забавное и неочевидное из списка. Однако как уже отмечалось, метод имеет свои минусы в виде анонимного класса на каждое использование этого метода. А также невозможности использования метода equals () для подобных объектов.

Некоторые вещи иногда работают не так, как подсказывает интуиция. Это утверждение можно отнести к обработке исключений в Java. Далее — ситуации и примеры кода, которые отражают некоторые имеющиеся нюансы.

По мотивам «JAVA → Java по-русски. Часть первая: Книги» habrahabr.ru/blogs/java/66568

Добрый день, уважаемые хабровчане!
В предыдущем обзоре Java книг, проведенном пользователем Scala, было рассказано о «практических» книгах, вышедших на рынок в последние три года. Я же хочу рассказать об этих и других книгах с несколько иного ракурса: попытаться выделить ценность информации книг.
Я не любитель читать с монитора, и предпочитаю книги покупать в бумажном варианте. Чтобы сделать осознанный выбор, следует отдавать себе отчет в том, что книга несет некие фундаментальные знания, но никак не сборник «последние фишки». Также в данной статье я хочу упомянуть о других известнейших трудах, не касающихся Java напрямую. Посмотрим, что лучше всего выбрать для обучения языку?

Я продолжаю переводить источник первой статьи. Всё больше очевидных вещей, не смотря на это я все же решил, что повторение — не такое плохое занятие.

И коли источник исчерпыет себя — призыв к хабра-java-сообществу: «Don’t be jealous!», дополните этот список в комментариях, поделитесь опытом. А пока — продолжение предыдущей статьи, после монтажа, дубляжа и разбавления собственным опытом:

JDK tools

Почти все в курсе, что в поставку JDK входит внушительное число tools’ов. Однако в повседневной работе, думаю, многие кроме как java, javac, jar не используют. Что же ещё можно взять из папки bin:

В продолжение первой части. Сегодня будем рассматривать ресурсы о Java в интернете, которые подразделим на 4 части: вендоры, JUG, форумы, новости. А заодно подведём итоги.

Вендоры

Sun Microsystems

Основной сайт компании Sun содержит чисто рекламную информацию, поэтому рассматривать мы будем Сеть Разработчиков. Итак, что же здесь есть:

• JavaFX — хит сезона. В рамках продвижения Sun проводит конкурсы по этой технологии, ещё вы можете найти документацию на русском языке и даже Wiki.
• Академические программы — информация об образовательных программах. В основном это курсы для преподавателей и учебные материалы — лекции, написанные в рамках грантов.
• Java SE, Java EE, Java ME, JavaCard за 2009 год не содержат практически никаких обновлений, а за предыдущие года есть разве что переводы некоторых статей.
• Форум довольно мёртвый, за исключением раздела о JavaFX.
• Ещё есть переводы англоязычных блогов The Aquarium и The Planetarium, посвящённых новостям о Java EE и Java для всех других платформ(SE, ME, FX, etc...) соответственно.

Почему эта загадка абсолютная? По двум причинам:
• Она касается основ языка Java, а не какого-то малоизвестного нюанса API.
• Она расплавила мой мозг, когда я на нее наткнулся.
Если вы хотите проверить себя перед дальнейшим чтением, пройдите этот тест.

Недавно на Хабре была статья Сортировка миллиона 32-битных int'ов в 2 мегабайтах памяти на Питоне. Заинтересовался, попробовал реализовать на Java.

Конечно, 32 строчки не получилось. Получилось 235.
Но мне показалось, что результат вполне можно использовать в качестве первого поста — не судите строго ;)