В этом месяце я сдавал экзамен SCJP. В этом топике я расскажу о подготовке и экзамене.
В основном для тех, кто собирается сдавать и кому нужно больше информации об этом.

Уточнение

Так как Sun'a больше нет, то и экзамена SCJP тоже нет. Теперь он значится так:
1Z0-851 Java Standard Edition 6 Programmer Certified Professional Exam.

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

Суть её очень проста: если хранить перечисления как сущности (@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.

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

Я уже достаточно много лет занимаюсь разработкой на java и повидал довольно много чужого кода. Как это не странно, но постоянно от одного проекта к другому я вижу одни и те же проблемы. Этот топик — попытка ликбеза в наиболее часто используемых конструкциях языка. Часть описанного — это довольно банальные вещи, тем не менее, как показывает мой опыт, все эти банальности до сих пор актуальны. Надеюсь, статья пригодится многим java программистам. Итак, поехали:

new vs valueOf

//медленно
Integer i = new Integer(100);
Long l = new Long(100);
String s = new String("A");

//быстро
Integer i = Integer.valueOf(100);
Long l = 100L;//это тоже самое что Long.valueOf(100L);
String s = "A";

Старайтесь всегда использовать метод valueOf вместо конструктора в стандартных классах оболочках примитивных типов, кроме случаев, когда вам нужно конкретно выделить память под новое значение. Это связано с тем, что все они, кроме чисел с плавающей точкой, от Byte до Long имеют кеш. По умолчанию этот кеш содержит значения от -128 до 127. Следовательно, если ваше значение попадает в этот диапазон, то значение вернется из кеша. Значение из кеша достается в 3.5 раза быстрее чем при использовании конструктора + экономия памяти. Помимо этого, наиболее часто используемые значения могут также быть закэшированы компилятором и виртуальной машиной. В случае, если ваше приложение очень часто использует целые типы, можно увеличить кеш для Integer через системное свойство «java.lang.Integer.IntegerCache.high», а так же через параметр виртуальной машины -XX:AutoBoxCacheMax=<size>.

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

Buffered Streams

//медленно
InputStream is = new FileInputStream(file);
int val;
while ((val = is.read()) != -1) {
}
//быстро
InputStream is = new BufferedInputStream(new FileInputStream(file));
int val;
while ((val = is.read()) != -1) {
}

Казалось бы — очевидная истина, неправда ли? Но как показал чужой код и опыт собеседования кандидатов, часть разработчиков определенно не понимает в чем преимущество буферизованных стримов. Кто до сих пор не разобрался — метод read() класса FileInputStream:

public native int read() throws IOException;

Согласитесь, каждый раз делать системный вызов, чтобы считать один байт несколько расточительно. Собственно для того, чтобы избежать этой проблемы и были созданы оболочки-буферы. Все что они делают — при первом вызове системного read() считывают несколько больше (в зависимости от указанного размера буфера, котрый по умолчанию равен 8 кб) и при следующем вызове read() считывают данные уже из буфера. Прирост производительности — на порядок. Системные вызовы, на самом деле, это не всегда плохо, например:

System.arraycopy(src, srcPos, dest, destPos, length);

В случае копированния массива — системный метод будет гораздо быстрей реализованного на java. И еще — считывайте данные порциями, а не по байтам, это тоже позволит прилично сэкономить.

Большинству разработчиков известно, что сборщик мусора в Java не является универсальным механизмом, позволяющим программисту полностью забыть о правилах использования памяти и о том, в каких случаях осуществляется его работа. Ниже описаны типичные случаи утечки памяти в java-приложениях, встречающиеся повсеместно.
Итак, о чём должен помнить каждый java-программист.

Про Unsafe в Java не слышал только ленивый, однако это не единственный магический класс в Sun/Oracle JDK, стирающий границы Java платформы и открывающий тропинки, не нанесенные на карту публичного API. Я расскажу про некоторые из них, принесшие пользу в реальных проектах. Но помните: недокументированные возможности лишают ваше приложение переносимости на другие Java платформы и, кроме того, являются потенциальным источником нетривиальных ошибок. Я даже зря написал слово «приложение». Лучше сказать, что описанные ниже классы вовсе не годятся для приложений! Скорее, они представляют интерес лишь для системного ПО и для любознательных программистов, т.е. для вас :)

Предисловие

На 16 декабря сего года я назначил себе прохождение экзамена Oracle Certified Professional Java Programmer. Он же Sun Certified Programmer в прошлом. Кроме того я подтолкнул к этому важному шагу еще троих своих товарищей. Начинаем готовиться. Пока вяло, но все же… И чтобы систематизировать получаемые знания, я решил периодически составлять «выжимки» — краткое содержание того, что нашел, прочитал или испытал на собственной шкуре. То, что вы читаете в данный момент — выжимка за номером ноль. Надеюсь, что это поможет кому-то избежать покупки дорогостоящих книг и перелистывания огромного количества статей. Готовлюсь я, кстати, по книге Sun Certified Programmer for Java 6: Study Guide за авторством Kathy Sierra и Bert Bates. Хорошая книга, отличный автор, легкий язык. Рекомендую.

Обращаю внимание, что я не претендую на полное описание всего того, что нужно знать перед экзаменом. Без помощи хаброжителей я подобную работу проделать не смогу, просто потому, что я еще не сдавал сам экзамен. Многое из приведенного ниже может показаться кому-то примитивным. Однако, как показывает практика нарешивания тестов, дьявол кроется именно в деталях. Будем считать это попыткой сжато изложить необходимое от правил именования идентификаторов до подводных камней перегрузки методов при наследовании и далее. Кроме того, я надеюсь подчерпнуть что-то полезное из комментариев людей, которые этот путь уже прошли. В лучшем случае на Хабре появится successfull story с полным описанием того, как все начиналось, росло и развивалось. Поскольку по задумке публиковаться все будет в реальном времени, — раз в двое суток примерно, — то те, кому предстоит сдавать экзамен смогут сравнивать по датам свой темп обучения с нашим и проходить чекпоинты намного быстрее.

В октябре на хабре появилась замечательная статья про работу HashMap. Продолжая данную тему, я собираюсь рассказать о реализации java.util.concurrent.ConcurrentHashMap.
Итак, как же появился ConcurrentHashMap, какие у него есть преимущества и как он был реализован.

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

HashSet

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

// Dummy value to associate with an Object in the backing Map
private static final Object PRESENT = new Object();

Это значит, что любое ваше значение внутри HashSet будет ассоциироваться со ссылкой на этот обьект. Это тоже самое, что:

Map.put(key, PRESENT);

Казалось бы, подумаешь — 8 байт, который будут использоваться всеми. Но не забывайте что при каждой вставке в HashSet, создается Map.Entry, в котором 4 ссылки (еще 16 лишних байт на каждый элемент). Расточительно, не находите? Почему так? Большая загадка… Спасибо хоть не унаследовались.

Default logger

Кто в проекте не использует log4j? А можете сходу назвать библиотеки, которые тоже обходятся без него? Думаю это трудные вопросы. Понимаю, java не может подстраиваться под каждую конкретную задачу, но добавили же стандартный Logger, так почему за 10 лет существования log4j, java так и не взяла лучшее из него? Представьте на сколько бы уменьшились все приложения, особенно сложные, где в конечной сборке может оказаться несколько разных версий логера.

Предисловие

Хочу продолжить делиться приобретенными знаниями и своими впечатлениями от подготовки к экзамену. Огромное спасибо всем тем, кто дал рекомендации к нулевой части этой серии! Сегодня я поговорю еще немножко о модификаторах доступа и их взаимоотношениях с наследованием и пакетами, рассмотрю varargs и перечисления, а также массивы и способы их инициализации. Я надеюсь, что хабражители снова откликнутся и дополнят то, о чем я забыл упомянуть или попросту не знал.

Продолжаем готовиться к экзамену под катом.

Готовясь к собеседованию, я решил освежить память да и вообще поискать каверзные и малоизвестные нюансы языка Java. Выборку пяти наиболее интересных на мой взгляд моментов я вам и предлагаю.

Вот уже подоспела и вторая часть статьи.


1. Нестатические блоки инициализации.

Всем, я думаю, известно, что в Java существуют статические блоки инициализации (class initializers), код которых выполняется при первой загрузке класса.

class Foo {
	static List<Character> abc;
	static {
		abc = new LinkedList<Character>();
		for (char c = 'A'; c <= 'Z'; ++c) {
			abc.add( c );
		}
	}
}

Но существуют также и нестатические блоки инициализации (instance initializers). Они позволяют проводить инициализацию объектов вне зависимости от того, какой конструктор был вызван или, например, вести журналирование:

class Bar {
	{
		System.out.println("Bar: новый экземпляр");
	}
}

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

Map<String, String> map = new HashMap<String, String>() {{
	put("паук",  "арахнид");
	put("птица", "архозавр");
	put("кит",   "зверь");
}};

Очень даже мощное средство, не находите?

JFrame frame = new JFrame() {{
	add(new JPanel() {{
		add(new JLabel("Хабрахабр?") {{
			setBackground(Color.BLACK);
			setForeground(Color.WHITE);
		}});

		add(new JButton("Торт!") {{
			addActionListener(new ActionListener() {
				public void actionPerformed(ActionEvent event) {
					System.out.println("Хабрахабр - торт!");
				}
			});
		}});
	}});
}};

Остальные четыре пункта под катом.

Как и обещал, предлагаю вашему вниманию следующие пять пунктов.

Малоизвестные особенности Java. Первая часть

6. Конфликт имён.

Если импортированы несколько классов с одним и тем же именем из разных пакетов, возникает конфликт имён. В таком случае при обращении к классу следует указывать его квалифицированное имя, то есть полное имя, включая и имя пакета, например java.lang.String.

Неужели ничего нельзя с этим поделать? Оказывается можно. Следующий код скомпилируется без проблем, несмотря на то, что класс List присутствует и в пакете java.awt, и в пакете java.util:

import java.awt.*;
import java.util.*;
import java.util.List;

public class Класс {
	public static void main(String... аргументы) {
		List простоСписок = Collections.emptyList();
		System.out.println(простоСписок);
	}
}

Достаточно дополнительно импортировать необходимый класс, java.util.List в данном примере.

Тут, как вы заметили, используются кириллические идентификаторы. Да! Для кого-то это станет откровением, но Java… такая Java. Идентификатор может состоять из совершенно любых букв, помимо цифр, знаков подчёркивания и валюты США (однако последний знак ($) использовать не рекомендуется, он предназначен для системных нужд). Но оно нам надо? Разве только в целях обфускации. Только представьте себе, сколько разных идентификаторов можно сгенерировать всего-то из символов «А» английского, русского и греческого алфавитов…

Уж много воды утекло с тех пор, как мы пользовались мышами на com-у, модемами, играли «по нему» в игры за неимением сети, перекидывали файлики и …, чего только мы с ним не делали.

Всё, на дворе 21 век, USB 3.0 подмял по себя всё и вся, com-ы вымерли и теперь «новорожденные» программисты смотрят на этот разъём с недоумением и укоризной. Но, умерли не все, кое-кто всё-таки остался… Эти бравые парни шлют байты по трём проводам и с со снисходительной улыбкой смотрят на «новорожденных». И о том, чем эти парни пользуются выполняя свою работу я и хочу поведать в этой небольшой статье. Речь в ней пойдёт о маленькой библиотечке по имени jSSC.

Вот уже почти год как усиленно занимаюсь коддингом на Java. Столкнулся с довольно серьезной на мой взгляд проблемой, связанных с многопоточностью, как мне кажется, неразрешимой в рамках текущей реализации JVM от Oracle (сказанное относится к JDK 1.5 и выше). Дело в том, что на данный момент в Java нет возможности гарантированно безопасно остановить выполнение какого-либо потока. Данный пост разъясняет почему это именно так и предлагает начать дискуссию о способах решения этой проблемы.

На Хабрахабре очень мало статей о SWT, поэтому я постараюсь исправить данное маленькое упущение.

Из данной статьи Вы узнаете:

• Какова мотивация использовать SWT в отличии от основного конкурента — Swing
• Основные трудности с которыми я столкнулся при разработке простенького блокнота на связке Java + SWT и Немного кода
• Каким образом упаковать и распространить свое приложение для нескольких платформ

Если Вас заинтересовало — прошу под кат.

Знаете сколько в памяти занимает строка? Каких только я не слышал ответов на этот вопрос, начиная от «не знаю» до «2 байта * количество символов в строке». А сколько тогда занимает пустая строка? А знаете сколько занимает объект класса Integer? А сколько будет занимать Ваш собственный объект класса с тремя Integer полями? Забавно, но ни один мой знакомый Java программист не смог ответить на эти вопросы… Да, большинству из нас это вообще не нужно и никто в реальных java проектах не будет об этом думать. Но это, ведь, как не знать объем двигателя машины на которой Вы ездите. Вы можете быть прекрасным водителем и даже не подозревать о том, что значат цифры 2.4 или 1.6 на вашей машине. Но я уверен, что найдется мало людей, которые не знакомы со значением этих цифр. Так почему же java программисты так мало знают об этой части своего инструмента?

Integer vs int

Все мы знаем, что в java — everything is an object. Кроме, пожалуй, примитивов и ссылок на сами объекты. Давайте рассмотрим две типичных ситуации:

//первый случай
int a = 300;
//второй случай
Integer b = 301;

В этих простых строках разница просто огромна, как для JVM так и для ООП. В первом случае, все что у нас есть — это 4-х байтная переменная, которая содержит значение из стека. Во втором случае у нас есть ссылочная переменная и сам объект, на который эта переменная ссылается. Следовательно, если в первом случае мы определено знаем, что занимаемый размер равен:

sizeOf(int)

то во втором:

sizeOf(reference) + sizeOf(Integer)

Забегая вперед скажу — во втором случае количество потребляемой памяти приблизительно в 5 раз больше и зависит от JVM. А теперь давайте разберемся, почему разница настолько огромна.

Из чего же состоит объект?

Прежде чем определять объем потребляемой памяти, следует разобраться, что же JVM хранит для каждого объекта:

• Заголовок объекта;
• Память для примитивных типов;
• Память для ссылочных типов;
• Смещение/выравнивание — по сути, это несколько неиспользуемых байт, что размещаются после данных самого объекта. Это сделано для того, чтобы адрес в памяти всегда был кратным машинному слову, для ускорения чтения из памяти + уменьшения количества бит для указателя на объект + предположительно для уменьшения фрагментации памяти. Стоит также отметить, что в java размер любого объекта кратен 8 байтам!

Под впечатлениями от habrahabr.ru/blogs/java/134102.

Недавно мне приходилось немного поковыряться внутри JVM. Довольно интересный опыт. Текст в вышеупомянутом топике не совсем сходится с моим опытом, но я не считаю себя обладателем абсолютной истины. Ниже я поделюсь с читателями небольшой частью моих экспериментов, которые касаются непосредственно объектов Java.

К сожалению, на данный момент Hibernate не обладает необходимыми механизмами интеграции для работы в OSGi среде, хотя подвижки в этом направлении заметны (начальная OSGi-фикация путём разделения пакетов в 4-ой ветке). Это побуждает разрабатывать собственные механизмы, что требует немалых дополнительных усилий.

Эта статья предназначается для тех разработчиков, кому интересно: как можно использовать Hibernate со связкой Spring+OSGi; что такое паттерн Extender; как реализовать ClassLoader со специфичным поведением; как поддерживается Hibernate в Spring Framework и немного о расширении этого кода. Разумеется, для чтения статьи необходимо разбираться в технологиях Spring, Hibernate, OSGi, а также понимать основные проблемы выполнения кода в многопоточной среде. Те же кто незнаком с использованием Spring Framework в OSGi среде могут обратиться к вводной статье «Использование Spring в OSGi-контейнере».

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

Что подвигло меня на написание данной библиотеки и чем плохи существующие решения:
К сожалению такие монстры как Hibernate «тяжеловесны» и навязывают свой API для работы с БД. Мне же нужна была простенькая библиотечка, использовать которую можно было бы в перемешку с обычным JDBC-кодом (по сути мне нужно было некоторое подобие Dapper.NET для JDBC).

Основные принципы, используемые при написании библиотеки:

• простота и атомарность — библиотечка представляет собой 1 java-файл, для добавления в проект достаточно просто добавить файлик к своим исходникам.
• ненавязчивость — библиотечка не навязывает свой API, возможно использование «вперемешку» с обычным JDBC-кодом
• независимость — библиотечка не использует ничего кроме Java SE 5
• расширяемость — библиотечка поддерживает добавление расширений, необходимых для конкретного проекта

Довольно часто в java приложениях с целью снижения нагрузки на БД используют кеш. Не много людей реально понимают как работает кеш под капотом, добавить просто аннотацию не всегда достаточно, нужно понимать как работает система. Поэтому этой статье я попытаюсь раскрыть тему про то, как работает кеш популярного ORM фреймворка. Итак, для начала немного теории.

Прежде всего Hibernate cache — это 3 уровня кеширования:

• Кеш первого уровня (First-level cache);
• Кеш второго уровня (Second-level cache);
• Кеш запросов (Query cache);

Кеш первого уровня

Кеш первого уровня всегда привязан к объекту сессии. Hibernate всегда по умолчанию использует этот кеш и его нельзя отключить. Давайте сразу рассмотрим следующий код:

SharedDoc persistedDoc = (SharedDoc) session.load(SharedDoc.class, docId);
System.out.println(persistedDoc.getName());
user1.setDoc(persistedDoc);

persistedDoc = (SharedDoc) session.load(SharedDoc.class, docId);
System.out.println(persistedDoc.getName());
user2.setDoc(persistedDoc);

Возможно, Вы ожидаете, что будет выполнено 2 запроса в БД? Это не так. В этом примере будет выполнен 1 запрос в базу, несмотря на то, что делается 2 вызова load(), так как эти вызовы происходят в контексте одной сессии. Во время второй попытки загрузить план с тем же идентификатором будет использован кеш сессии.
Один важный момент — при использовании метода load() Hibernate не выгружает из БД данные до тех пор пока они не потребуются. Иными словами — в момент, когда осуществляется первый вызов load, мы получаем прокси объект или сами данные в случае, если данные уже были в кеше сессии. Поэтому в коде присутствует getName() чтобы 100% вытянуть данные из БД. Тут также открывается прекрасная возможность для потенциальной оптимизации. В случае прокси объекта мы можем связать два объекта не делая запрос в базу, в отличии от метода get(). При использовании методов save(), update(), saveOrUpdate(), load(), get(), list(), iterate(), scroll() всегда будет задействован кеш первого уровня. Собственно, тут нечего больше добавить.