Java *

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

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

Недавно в Oracle блоге Brian Goetz опубликовал ссылку на презентацию с Devoxx talk on Language / Library / VM Co-Evolution in Java SE 8.
В статье я попытаюсь вкратце раскрыть основные проблемы, которые будут решены в восьмерке, а также пути их решения, которые были избраны компанией Oracle. Остальные аспекты можно посмотреть в оригинале.

Читайте дальше:
Расширение существующих API с обратной совместимостью;
Java становится еще более объектно-ориентированной;
Лямбда-выражения в Java;
Упрощение многопоточности.

Всем привет!

Чего хотим

Хотим чтобы работала проверка орфографии в NetBeans для русского языка.

Как сделать

КО: Чтобы работала проверка орфографии для русского языка, надо установить словарь для русского языка!

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

UPDATE
В комментариях подтвердили работоспособность словарей в IntelliJ IDEA и Eclipse IDE.

 

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

Малоизвестные особенности 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. Идентификатор может состоять из совершенно любых букв, помимо цифр, знаков подчёркивания и валюты США (однако последний знак ($) использовать не рекомендуется, он предназначен для системных нужд). Но оно нам надо? Разве только в целях обфускации. Только представьте себе, сколько разных идентификаторов можно сгенерировать всего-то из символов «А» английского, русского и греческого алфавитов…

Готовясь к собеседованию, я решил освежить память да и вообще поискать каверзные и малоизвестные нюансы языка 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("Хабрахабр - торт!");
				}
			});
		}});
	}});
}};

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

Предисловие

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

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

Решил перевести новость о том, что OpenShift теперь объединяет Jenkins, JBoss Tools и Maven, позволяя Java-разработчикам программировать, собирать, развёртывать и масштабировать приложение в облаке.

Red Hat предлагает вам использовать OpenShift не только для хостинга приложений, но и для всего цикла разработки ПО. Вы можете программировать, компилировать и улучшать своё ПО прямо в «облаке», не используя для этого десктоп или мощный ноутбук.

OpenShift — PaaS-облако, о запуске которого Red Hat объявил в мае. Эта облачная платформа существует в трёх версиях — Express, Flex и Power и позиционируется, как альтернатива Microsoft Azure или Google App Engine. Главное преимущество облачных вычислений состоит в том, что они автоматически масштабируют ресурсы, настолько, насколько это требуется для текущей нагрузки.

Во время работы мне, как, наверное, и каждому из Вас, иногда приходится замечать мелкие недочеты 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 так и не взяла лучшее из него? Представьте на сколько бы уменьшились все приложения, особенно сложные, где в конечной сборке может оказаться несколько разных версий логера.

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

Предисловие

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

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

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

Вместо введения отправляю читателя к отличной статье Использование Spring в OSGi-контейнере которая и послужила отправной точкой для практического изучения.
Итак, к делу. Рассмотрим классический вариант — есть бизнес-логика приложения и она как-то
взаимодействует с внешним миром. Используем такую связку:
клиент <-> транспорт <-> приемник <-> сериализатор/десериализатор <-> метод бизнес логики.
Сериализатор напрашивается заменяемым модулем, например сериализация в JSON или сериализация в XML.
Про бизнес-логику далее можно забыть, и сосредоточиться на связке приемника и сериализатора.
В качестве приемника используем сервлет, а для сериализатора, для простоты, используем реализацию следующего интерфейса:

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

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

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. И еще — считывайте данные порциями, а не по байтам, это тоже позволит прилично сэкономить.

Доброго всем времени суток! При написании программы, которая так или иначе будет взаимодействовать с базой данных, пользуются разными средствами. Это и старый добрый jdbc, также применяют: EclipseLink,TopLink, iBatis (уже MyBatis), Spring Framework и конечно же герой нашей статьи — Hibernate. Конечно я здесь перечислил не все средства работы с базой данных, но постарался указать самые распространенные. В данной статье будет показано, как при помощи Hibernate вызывать хранимые процедуры, маппить как таблицы, так и запросы к классам. В качестве подопытной базы данных возьмем Oracle.

Совершенство достигается не тогда, когда уже нечего прибавить,
а когда уже ничего нельзя отнять.
Антуан де Сент-Экзюпери, Ветер, песок и звезды, 1939

Часто приходится проектировать и разрабатывать пакеты ввода/вывода для приложений на Java. С одной стороны есть java.io, которого бывает более чем достаточно. Однако, на практике редко удается обойтись набором стандартных классов и интерфейсов.

В статье, приводится практический пример идеи для реализации пакетов ввода/вывода на платформе Java.

Я уже достаточно много лет занимаюсь разработкой на 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>.

Xtend

Xtend представляет собой статически типизированный язык программирования от команды Eclipse, который обладает тесной интеграцией и работает поверх JVM. Его корни лежат в языке программирования Java (кто бы мог подумать). Xtend обладает рядом концептуальных улучшений:

• Выведение типов — нет необходимости постоянно указывать сигнатуры типов.
• Полная поддержка Java Generics — включая все соответствия и правила приведения.
• Замыкания — приятный синтаксис для анонимных классов.
• Перегрузка операторов — позволяет писать более выразительный код.
• Улучшенные switch выражения — на основе типов и приведения.
• Каждое выражение имеет значение (en. «No statements — Everything is an expression»).
• Шаблоны — с поддержкой пробелов.
• Поддержка расширений — JSR-330.
• Доступ к свойствам — синтаксический сахар над get/set.
• Полиморфный вызов методов.
• Транслируется в Java код, а не Bytecode — корректная работа с кодом, предназначенным для пратформ, таких как Android или GWT.

У разработчиков не стоит цели заменить Java. Библиотека Xtend является тонким слоем над JDK и работает равносильно с Java и Xtend. Разумеется, разработчики предоставляют современную IDE на основе Eclipse.

Сегодня пятница (а в России еще и выходной). Поэтому вместо кода послушайте рэп «Java Life»



UPD: divX дал ссылку на текст и видео, как снимался клип.