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

Всем привет.

Время от времени я, как и большинство программистов, изучаю какие-то новые структуры и алгоритмы.

В этот раз мне на глаза попались статьи по cache oblivious алгоритмам. Это такие алгоритмы, которые изначально более оптимизированы для работы с подсистемой кэширования современных процессоров.

Одним из представителей этой группы является Unrolled linked list.

Что же это такое?

В первой части статьи мы рассмотрели комбинацию Caché + Java. Здесь будет показана структура проекта непосредственно реализующего комбинацию Caché + Java + Flex, а также основные инструменты и их настройки, используемые для её реализации. Стоит отметить, что здесь будет приведен лишь общий вид взаимодействия, в то время как, конкретные примеры будут рассмотрены в заключительной части. Начнем с описания модулей, входящих в состав проекта, и постепенно перейдем к особенностям их взаимодействия.

Как и было обещано во второй части эта статья посвящена исключительно практическим примерам, демонстрирующим особенности взаимодействия Caché + Java + Flex. Начнем с преобразования типов данных на протяжении всей связки. Мы не стали заострять внимание на преобразованиях таких типов данных, как Integer, Float, String, Boolean, поскольку данные типы идентичны в Caché и Java (а в ActionScript все числовые типы переходят в Number). Другое дело коллекции объектов. Их преобразование проходит достаточно нетривиально, поэтому остановимся на них подробнее.

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

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

List<String> getElements(String key);

Но вы решили, что иногда эти наборы бывают огромными, либо трудно достать все строки сразу (например, некоторые реализации запрашивают их у какого-нибудь медленного веб-сервиса с дурацким протоколом). А применяете вы их, например, отображая на экране с постраничной навигацией или подгружая частями. Тут некоторым разработчикам придёт мысль расширить интерфейс как-то так:

public interface MyCollection {
    List<String> getElements(String key);
    String getElement(String key, int index);
    List<String> getElementsRange(String key, int fromIndex, int toIndex);
    int getElementsCount(String key);
}

Доброго времени суток, дорогие хабравчане.
Недавно столкнулся с проблемой создания панели меню — стандартной панели, которая присутствует почти в каждом мало-мальски функциональном UI. И не с той проблемой, что ее сложно создать, напротив, в Swing создание UI занятие довольно тривиальное, большинство элементов интерфейса создаются в пару строк кода (это в равной степени касается и меню). А с проблемой создания многофункционального, сложного меню, которое выливается в невероятное количество кода, который в последствии не то чтобы сопровождать, а порой даже и читать невозможно.

Для хранения всего процесса генерации меню любой сложности, решил я прибегнуть к силе под названием XML. С его помощью можно описать меню, как мы хотим его видеть, а благодаря классу-утилите, который не преминем создать, наш XML будет распарсен и в итоге можно будет получить то, ради чего все это и затевается — меню любой сложности. Если вас это заинтересовало, добро пожаловать под хаброкат…

Как известно, в Java существуют примитивные типы для чисел (byte, short, int, long, float, double) и объектные обёртки над ними (Byte, Short, Integer, Long, Float, Double). В различных статьях можно встретить диаметрально противоположные рекомендации о том, чем пользоваться. С одной стороны объектные обёртки универсальны: их можно использовать со стандартными коллекциями, которые удобны, инкапсулированы и вообще прекрасны. Но боксинг убивает производительность и ест кучу памяти. Примитивные типы быстры и компактны, но их можно поместить только в массивы, которые и от записи не защитишь, и абстракция на нуле. Если же вам нужно что-то типа Map, для отображения чего-нибудь на числа, то придётся либо мириться с потерей производительности и памяти, либо использовать сторонние библиотеки, реализующие нестандартный интерфейс. Однако в некоторых случаях вам помогут изменяемые (mutable) числа.

Совсем недавно уважаемый lany написал замечательный пост про mutable numbers в Java: http://habrahabr.ru/post/151887/
В комментарии к его посту я упомянул, что если важна производительность, то можно заменить объект-обертку на одно-элементный массив, доступ к элементу массива по определению быстрее чем извлечение значения из instance field.
Этот стереотип мне достался в наследство от Sun после прочтения очередного performance white paper. Там было написано что быстрее всего происходит доступ к локальной переменной, следом идет статический филд, потом элемент массива и замыкает этот список instance field.
К счастью на слово мне не поверили и это послужило поводом для написания этой статьи.
Статья не расчитана на джуниоров, читатель должен знать Java, ASM x86 и байткод.

Ни для кого не секрет что сервера приложений существуют для того чтобы снять некоторую часть работы с разработчика и возложить её на уже готовые механизмы. В частности механизм аутентификации в сервере приложений Glassfish можно организовать с помощью так называемых Security Realms. Существуют несколько встроенных вариантов, такие как аутентификация через СУБД, LDAP, PAM, Certificate и обычное чтение из файла. Однако они могут нас не устроить ввиду своей ограниченности (LDAP, например, может работать только с одним наперед заданным доменом). Поэтому мы и рассмотрим создание собственного security realm’а.

Что Вы делаете, когда Ваше Java приложение потребляет 100% ЦП? Оказывается Вы легко можете найти проблемные потоки, используя встроенные Unix и JDK утилиты. Никакие инструменты профилирования не потребуются.
С целью тестирования мы будем использовать простую программу:

К моему последнему проекту, написанному на 80% на Java, надо было дописать модуль — парсер всех писем, проходящих через сервер. Религиозные мотивы модуля очень странные, но некоторыми деталями хотелось бы поделиться.

В наличии имеются:

Почтовый сервер Postfix со службой доставки Dovecot на CentOS. Ну и JVM.

Структура сообщений

Что такое электронное письмо, его составные части, их примерная структура, заголовки и MIME типы по-человечески описано на википедии.
Более интересной является структура имени файла письма на сервере. Пример имени новоиспеченного (не прочитанного/не запрошенного клиентом) письма:

1348142977.M852516P31269.mail.example.com,S=3309,W=3371

Давным давно, когда трава была зеленее, меня поймали и долго пытали пришлось мне повышать перформанс в одной чудесной связке.

Как задачу понял архитектор

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

Попытка решения: написали плееры на флэше и на javascript, которым скармливается этот преобразованный каталог, и они разными красочными эффектами по определенному алгоритму крутят нечто рекламное.

Проблема: каталоги постоянно меняются, а конвертация только одного гроссбуха из каталога занимает больше часа(!).

Почему так и как улучшить?

Данная статья призвана систематезировать знания о всех современных сборщиках мусора, используемых в HotSpot, JRockit и J9 JVMs. Статья содержит краткий обзор всех режимов сборки мусора с проведенными аналогиями между всеми рассматриваемыми здесь JVM. Статья будет интересна всем, кто интересуется вопросом GC, а также будет полезна тем, кто рассматривает или планирует совершать портирование JAVA приложений на альтернативные JVM.

Введение

Посетил вчера семинар по lambda-выражениям в JAVA 8. Рассказали много интересного.

Я работаю в нагрузочном тестировании относительно недолго, и одним из моих основных инструментов является Apache Jmeter. Тем не менее, большинство моих коллег не использовали Beanshell в JMeter, и в этой статье я хочу показать пару способов как он может упростить и сократить время подготовку к самим тестам. А покажу это на примере конвертации текста в base64-кодировку и простых стрельб в MongoDB.

Введение

В процессе отладки приложений работающих на JVM посредством дебаггера в Eclipse меня всегда впечатляло то, сколько доступа можно получить к данным приложения — потокам, значениям переменных и т.п. И в то же время периодически возникало желание «заскриптовать» некоторые действия или получить больше контроля над ними.

Например, иногда для того чтоб «мониторить» состояние какой-то переменной, меняющейся в цикле, я использовал условный брейкпойнт, условием к которому был код вроде «System.out.println(theVariable); return false». Этот хак позволял получить лог значений переменной практически не прерывая работы приложения (она, естественно, всё-таки прерывалась на время выполнения кода условия, но не более). Плюс, нередко при просмотре каких-нибудь данных через вид Display порядком раздражало то, что результат евалюейшна кода в Display введённого добавлялся тут же после него.

В общем хотелось получить возможность делать всё то же самое например через Bean Shell или Groovy Shell, что в принципе аналогично программному дебагу. По логике это не должно было быть сложно — ведь делает же это как-то сам Eclipse, верно?

Проведя некоторый рисёрч я смог получить доступ к отладочной информации JVM программно, и спешу поделится примером.

    В статье ниже я попытаюсь кратко рассказать о том, что такое Tarantool и как начать его использовать в уже существующем проекте если вы программируете на Java. Если же вы программируете на другом языке, то вам могут быть интересны некоторые инструменты доступные в коннекторе, такие как возможность редактирование xlog файлов и создание snap файлов из любых данных. Если вы не знаете, что такое Tarantool, то лучше прочитать этот пост.

Многие знают что для подстановки значений в конфигурационные файлы Spring можно использовать context:property-placeholder.

<context:property-placeholder location="classpath*:/prop/*.properties"/> <!-- здесь будут искаться property файлы -->

<bean id="mongoTemplate" class="org.springframework.data.mongodb.core.MongoTemplate">
    <constructor-arg ref="mongo"/>
    <constructor-arg name="databaseName" value="${mongo.db}"/> <!-- здесь будет подставлено значение из найденных property -->
</bean>

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

Когда передо мной встала задача, в зависимости от окружения (dev, prod, load-test), изменить логику развертывания — я искренне попытался использовать старый проверенный способ через property.

Disclaimer: нашел статью у себя в черновиках. Писал года полтора-два назад, почему не опубликовал — не помню. Просмотрел, вроде, не совсем бесполезная, пусть будет в открытом доступе.

В последнее время стало достаточно актуальным использование domain specific languages (DSL) — языков «заточенных» под конкретную предметную область. Слово «язык» в данном контексте не обязательно подразумевает именно новый язык программирования, зачастую можно обойтись и старым добрым.

На хабре не замечено ни одной статьи про fluent interface в контексте джавы, так что хотел бы поделиться своим опытом применения.

Что это и для кого (вместо вступления)

В данной статье я бы хотел рассказать о небольших результатах своей научной деятельности в сфере Text Mining. Этими самыми «результатами» стал небольшой FrameWork, который, пока еще, и до либы то не очень дотягивает, но мы растем =). Данный проект — реализация на практике некоторых, разработанных мною, теоретических положений. Как следствие этого я представляю возможности, которыми он может потенциально обладать в конце внедрения всех идей. Названо сее творение: «Text Mining FrameWork»(TextMF). Давайте в кратце рассмотрим, что именно будет позволять TextMF в своей первой финальной версии и что работает уже сейчас.