Coding Break

Eclim: установка и впечатления

2011-07-03T14:34:00.000+04:00

Eclim - программа, которая призвана внести возможности Eclipse в Vim, чтобы облегчить разработку программ на Java, C/C++, Ruby, PHP, Python в последнем.

Установка

По установке Eclim-а есть официальная инструкция. Я устанавливал на Ubuntu, хотелось бы сделать несколько замечаний по этому поводу.

Требования: JDK 1.5+, Vim 7.1.x, Eclipse 3.7.x Indigo. Считаем, что JDK у нас есть. Vim 7.3, который можно установить из репозитория Ubuntu, подходит. Eclipse в репозитории старый, поэтому нужную версию придётся скачать. Будем считать, что Eclipse у нас в /home/user/eclipse/

Установщик только графический. Он довольно неудобен.

В нашем случае Eclipse Home и User Local Eclipse пути должны быть /home/user/eclipse/.

Установщик скачает нужные пакеты и Eclim установится.

Запуск и работа

Eclim предлагает несколько способов применения. Можно разрабатывать в Vim без запуска Eclipse, можно запустить Eclipse и использовать Vim в качестве редактора исходников, а можно совмещать. Принципиальной разницы в настройке Eclim здесь нет. Существуют также и другие средства, которые позволяют использовать Vim внутри Eclipse, например, Vimplugin.

Нужно запустить демон eclimd, он находится в папке /home/user/eclipse/. Ждём сообщения Eclim Server Started on: 127.0.0.1:9091 в его выводе прежде, чем продолжить.

Далее открываем и выполняем Getting Started. У меня .classpath нового Java проекта сам наполнился нужными данными, добавлять ничего не пришлось. Команды :NewSrcEntry в Vim-е не обнаружилось.

Следуем инструкции до пункта 4, где нам предлагается испытать автозавершение (autocompletion). Автозавершение по ctrl+n у меня выдаёт какие-то общие ключевые слова, которые не подходят к контексту. Ctrl+x + ctrl+u не заработало («Option 'completefunc' is not set»). Чтобы починить, нужно в файл .vimrc добавить строку filetype plugin indent on, об этом написано в Eclim Troubleshooting. Если файла .vimrc нет в домашней папке, надо создать.

Так выглядит автозавершение:

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

Впечатления

Для себя я сделал вывод, что в качестве среды разработки Vim не катит. Это хороший редактор, но разрабатывать в нём быстрее, чем в Eclipse, не получится.

Однако тем, кто считает Vim лучшим редактором для всего, Eclim может пригодиться как частичная замена Eclipse. Напомню, что совсем избавиться от Eclipse в системе не получится - Eclim его использует.

Если кто вдруг не знает, в эклипсе есть до фига сочетаний клавиш. Открытие файлов, переключение между вкладками, quick outline, автодополнение, форматирование, компиляция, запуск - все эти и другие действия в Eclipse можно и нужно выполнять без мыши.

Настраивал vsftpd на CentOS

2011-06-05T22:47:00.000+04:00

Настроил. Захожу под тестовой учётной записью и вижу: текущая директория (pwd) верная, а файла, который там лежит, не видно. Проверил настройки - всё верно. Проверил права доступа - всё есть. Поискал в интернете - ничего толкового не нашёл.

В итоге проблема решилась отключением SELinux. Эта зараза, как оказалось, может молча отбирать права у процессов, если ей что-то не понравится. Особенно неприятно, когда такие тонкие моменты всплывают на зачёте по системному администрированию.

Про принтеры Canon в Ubuntu

2011-05-17T14:41:00.000+04:00

По ужасному стечению обстоятельств я являюсь владельцем лазерного принтера Canon LBP2900 и постоянным пользователем Ubuntu (других ОС на домашнем ноутбуке нет). Принтеры этой серии (про другие серии не в курсе) — большая головная боль для линуксоидов, поскольку протоколы закрыты, а официальные драйвера под линукс ужасны.

Недавно появилась новость о разработке открытого драйвера принтеров Canon. Драйвер разрабатывается путём реверс-инжиниринга официального. На днях мне нужно было срочно установить мой принтер в новенькую Ubuntu 11.04, но с этим драйвером я не разобрался, к сожалению. Не стал рисковать временем и решил действовать по-старинке, поставить кривые официальные драйвера.

Здесь нужно заметить, что «правильно» установить кэноновские драйвера не просто. Существует несколько инструкций, но не все работают. Оказалось, один хороший человек написал скрипт для установки драйвера, который автоматизирует этот процесс почти полностью и экономит много времени. Скрипт работает, в том числе, и в Ubuntu 11.04 «Natty Narwhal». Вот он. Архив содержит и сами драйвера, то есть искать и скачивать их отдельно не нужно.

Стоит добавить, что для успешной установки драйверов могут понадобиться пакеты cupsys и gs-esp. Иначе в логе скрипта вы увидете сообщения apt-get об ошибках.

Сам официальный драйвер очень глючный. Время от времени принтер просто перестаёт печатать, иногда при этом ещё capt и cupsd полностью загружают процессор. В этих случаях помогает одно из следующих действий:

отменить печать, перезагрузить cupsd: sudo restart cupsd;
перезагрузить принтер;
перезагрузить компьютер.

Не работает автодополнение в Eclipse

2011-05-10T18:31:00.000+04:00

Иногда случается, что какой-то воркспейс использовался с одной версией Eclipse, потом стал использоваться с другой версией Eclipse и тут сломалось автодополнение (autocompletion) в Java. Решение в таком случае очень простое — надо создать новый воркспейс и импортировать туда проекты из старого, при этом отметив «Copy projects into workspace».

Effective Java: Concurrency

2011-05-10T18:29:00.001+04:00

Напоминаю, что данная серия постов — кратчайшее изложение основных мыслей книги Effective Java 2nd edition. Они не заменят книги, но помогут освежить кое-что в памяти.

Item 66. Синхронизируйте доступ к общим (shared) изменяемым (mutable) данным.

Параграф о применении ключевых слов synchronized и volatile. Автор делает следующие выводы: лучше всего избегать межпоточной синхронизации использованием immutable объектов. Если это невозможно, всегда нужна синхронизация, иначе результат работы программы будет непредсказуем. В случаях, когда блокировки (ключевое слово synchronized) не нужны, допустимо использовать volatile. Но и с ним не всё так просто — надо помнить, что не все операции атомарны (++ и -- не атомарны, операции чтения и записи для long и double тоже).

Item 67. Избегайте избыточной синхронизации.

Никогда не запускайте «чужой» (alien) код внутри синхронизированных блоков. «Чужим» называется код, предоставляемый клиентом вашего API. Соответственно, вы не знаете, что и как будет выполняться в этом коде, поэтому в некоторых случаях выполнение «чужого» кода может привести к дедлокам (deadlocks), состоянию гонки (race condition) ошибкам выполнения. Автор приводит пример кода с такой проблемой. Выполнение «чужого» кода нужно выносить за пределы synchronized-блоков. Если это невозможно, синхронизацию следует переложить на клиентский код, при этом явно задокументировав потоковую небезопасность вашего API.

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

Если ваш класс не предполагает обязательной многопоточности, лучше вообще ничего не синхронизовывать — пусть лучше клиент об этом заботится. Это правило нарушено во многих старых стандартных классах, например, в StringBuffer. Он синхронизован внутри, хотя чаще всего использовался в одном потоке. Поэтому пришлось создавать его несихронизованный аналог StringBuilder, которым мы почти всегда и пользуемся.

Item 68. Предпочитайте executors и tasks вместо «сырых» потоков.

В Java 1.5 появился пакет java.util.concurrent, содержащий Executor Framework. Данный фреймворк предоставляет классы, упрощающие выполнение очередей задач в однопоточном, многопоточном режимах или по таймеру. Благодаря им больше не нужно писать свои собственные безопасные очереди и диспетчеры потоков.

Кроме того, фреймворк вводит понятие задач (tasks), представленных двумя интерфейсами Runnable и Callable. Эти интерфейсы позволяют абстрагироваться от потоков и не работать с ними напрямую.

Item 69. Предпочитайте готовые многопоточные утилиты вместо wait и notify.

Пакет java.util.concurrent кроме Executor Framework содержит ещё и потокобезопасные коллекции и синхронизаторы (synchronizers). Данный параграф рассказывает о двух последних.

Потокобезопасные коллекции — высокоэффективные имплементации стандартных интерфейсов List, Queue, Map, Set. Они синхронизованны внутри. Некоторые из них имеют особые методы типа map.putIfAbsent(key, value) для обеспечения атомарности подобных операций. Эти коллекции рекомендуется использовать вместо устаревших Collections.synchronizedXXX, поскольку первые более производительны.

Синхронизаторы — объекты, заставляющие потоки ждать друг друга, прежде, чем начать выполнение. Наиболее часто используемые: CountDownLatch, Semaphore. Наименее используемые: CyclicBarrier, Exchanger. Про них по-хорошему нужно читать в специализированных статьях и книгах.

Причин использовать wait и notify в новом коде крайне мало. Если приходится поддерживать старый код, использующий эти методы, нужно помнить, что wait() всегда должен располагаться в цикле while с проверкой условия пробуждения.

Item 70. Документируйте потокобезопасность.

При настройках по умолчанию Javadoc не включает ключевые слова synchronized в документацию, и правильно делает. Потокобезопасность нужно документировать самостоятельно. Существует 5 уровней потокобезопасности:

Неизменяемые (immutable) классы — синхронизация не нужна. Примеры — String, Long, BigInteger.
Безусловно потокобезопасные классы — экземпляры класса изменяемы, но синхронизованны внутри, и внешняя синхронизация не требуется. Примеры — Random, ConcurrentHashMap.
Условно потокобезопасные классы — некоторые методы требуют внешней синхронизации. Например, врапперы Collections.synchronizedXXX - их итераторы требуют дополнительной синхронизации.
Не потокобезопасные классы — их экземпляры изменяемы, нужна внешняя синхронизация. Пример — коллекции из java.util.
Враждебные многопоточности (thread-hostile) классы, методы — им не помогает даже внешная синхронизация. В основном, это происходит, когда экземпляры работают со статическими данными класса. Такие классы — редкость, они появляются, если кто-то не расчитывает на многопоточность при проектировании.

Item 71. Используйте ленивую инициализацию с умом.

Параграф описывает способы осуществления ленивой инициализации. Если не позаботиться о многопоточности, может случаться повторная инициализация.

Когда нужно лениво инциализировать статическое поле, используйте holder class idiom; когда не статическое поле — double-check idiom. И помните, что оптимизировать нужно только тогда, когда это действительно необходимо.

Item 72. Не полагайтесь на планировщик потоков.

Код, полагающийся в своей корректности или производительности на алгоритм планировщика потоков, не переносим. Количество работающих (runnable) потоков не должно значительно превышать количество процессоров. Потоки не должны работать, если они не делают никакой полезной работы. Нужно избегать использования Thread.yield() - если производительность низкая, лучше реорганизовать рабочие потоки. Приоритеты потоков допустимо использовать, чтобы немного подрегулировать перфоманс, однако на них нельзя полагаться при решении более серьёзных проблем с многопоточностью. Они тоже реализованы по-разному в разных JVM, некоторые виртуальные машины могут попросту их игнорировать.

Item 73. Избегайте использования групп потоков (thread groups).

Группы потоков были придуманы с целью изолировать java-апплеты для безопасности, но они так и не справились с этим. Сейчас этот API совершенно устарел. Нет причин использовать его в коде.

Отзыв о книге «A Programmer's Guide to Java SCJP Certification: A Comprehensive Primer (3rd Edition)»

2011-04-02T20:01:00.002+04:00

Авторы: Khalid Mughal, Rolf Rasmussen.

Данная книга представляет собой руководство по подготовке к сертификационному экзамену SCJP. Книга здоровая - около 1000 страниц. Впечатления после её прочтения немного противоречивые. С одной стороны, она полностью и подробно покрывает все темы, которые нужно знать. С другой стороны, есть и другие книги по подготовке к экзамену SCJP, гораздо менее толстые. Я думаю, что можно было прочитать одну из таких книг, а в сэкономленное время порешать побольше практических тестов.

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

В конце книги есть тест для самопроверки, покрывающий своими 72 вопросами множество тем, как реальный экзамен. Но имеет место одна странность. Каждый вопрос имеет своё количество правильных ответов, это число указано в условии. Есть список правильных ответов с объяснением. Но для некоторых вопросов число правильных ответов не совпадает с числом, указанным в вопросе! Я этого совершенно не понял.

В общем, если меня кто-то спросит, что почитать по Java, я, скорее всего, порекомендую какое-нибудь более скромное руководство и второе издание «Effective Java». Читать же эту книгу оказалось совершенным задротством.

Конечно, это только моё личное мнение, поэтому не рекомендую делать выбор, основываясь только на нём.

Effective Java: Exceptions

2011-04-02T19:58:00.000+04:00

Продолжаем. Сегодня речь о 9-й главе «Exceptions».

Item 57. Используйте exception-ы только для исключительных (exceptional) ситуаций.

Автор приводит пример применения исключений не по назначению для итерации по массиву без проверки выходна за границу.

// Horrible abuse of exceptions. Don't ever do this!
try {
    int i = 0;
    while(true)
        range[i++].climb();
} catch(ArrayIndexOutOfBoundsException e) {
}

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

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

Item 58. Используйте проверяемые исключения (checked exceptions) в поправимых ситуациях и непроверяемые исключения (runtime exceptions) при программных ошибках.

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

Принято считать, что класс Error и его подклассы используются только виртуальной машиной, и наследоваться от них не надо - вместо этого использовать RuntimeException.
Не имеет смысла напрямую имплементировать Throwable, не наследуясь от какого-либо Exception-а. Поведение будет такое же, как и у checked exceptions.
Exception-ы - полноценные объекты, для которых можно и нужно объявлять дополнительные методы, предоставляющие информацию об исключении.

Item 59. Избегайте лишних проверяемых исключений (checked exceptions).

Злоупотребление проверяемыми исключениями приводит к неудобствам при использовании вашего API. Если исключение можно предотвратить проверкой специальных условий (как метод hasNext() класса Iterator), либо клиент не сможет предпринять никаких полезных действий при возникновении исключения, то использование runtime exception - наилучший выбор.

Item 60. Предпочитайте стандартные классы-исключения.

Применение стандартных исключений полезно хотя бы потому, что все их знают, и использование вашего API будет таким образом упрощено. Самые часто применяемые исключения из стандартной библиотеки: IllegalArgumentException, IllegalStateException, NullPointerException, IndexOutOfBoundsException, ConcurrentModificationException, UnsupportedOperationException. Важно не забывать, что exception должен соответствовать исключительной ситуации не только по названию, но и по семантике, описанной в документации к исключению. Также бывает полезно наследоваться от стандартных исключений для добавления в них какой-либо полезной информации.

Item 61. Кидайте исключения, соответствующие уровню абстракции.

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

/**
 * Returns the element at the specified position in this list.
 * @throws IndexOutOfBoundsException if the index is out of range
 * ({@code index < 0 || index >= size()}).
 */
public E get(int index) {
    ListIterator<E> i = listIterator(index);
    try {
        return i.next();
    } catch(NoSuchElementException e) {
        throw new IndexOutOfBoundsException("Index: " + index);
    }
}

Это называется exception translation idiom. Особая её форма - exception chaining - когда низкоуровневое исключение не отбрасывается, а сохраняется в поле cause высокоуровнего исключения:

// Exception Chaining
try {
    ... // Use lower-level abstraction to do our bidding
} catch (LowerLevelException cause) {
    throw new HigherLevelException(cause);
}

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

Item 62. Документируйте кидаемые исключения.

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

Описывайте каждое проверяемое исключение (checked exception), которое может быть кинуто из ваших методов, используйте для этого javadoc-тег @throws. Непроверяемые исключения тоже важно упоминать в документации, но не с тегом @throws, а просто в описании метода. Конечно, описать всевозможные runtime exceptions далеко не всегда представляется возможным. Всё это относится как к конкретным методам, так и к абстрактным и методам в интерфейсах.

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

Item 63. Включайте в исключения информацию об ошибках.

Когда программа падает с непроверяемым исключением, stack trace и текстовое сообщение из исключения попадают в лог или консоль. Если ошибку трудно или невозможно воспроизвести, то эта вся информация, доступная разработчикам для поиска ошибки. Поэтому важно наделять текст исключения всеми важными значениями, касающимися исключительной ситуации. Проверяемые исключения полезно обеспечивать методами-аксессорами к этим значениям, которые могут пригодиться при обработке исключения в catch-блоке.

Item 64. Стремитесь к атомарности сбоев (failure atomicity).

Любое задокументированное исключение, сгенерированное методом объекта, должно оставлять объект в рабочем состоянии - это и называется failure atomicity. Если добиться такого эффекта слишком сложно или невозможно, нужно ясно заявить об этом в документации.

Для неизменяемых (immutable) инстансов failure atomicity гарантирована по определению. Добиться её в остальных случаях можно одним из следующих способов (по убыванию популярности):

проверять входные параметры каждого метода до выполнения каких-либо действий;
выполнять все «опасные» вычисления до изменения состояния объекта;
писать восстанавливающий код для отката объекта в консистентное состояние;
выполнять действия над временной копией объекта. Пример - метод Collections.sort() копирует объекты из коллекции во временный массив (в т. ч. для лучшей скорости), сортирует их, затем копирует обратно.

Item 65. Не игнорируйте исключения.

Кажется, это очевидно. Исключения придуманы для того, чтобы заставить программиста учитывать их и выполнять какие-либо действия при их возникновении, а не игнорировать их. В самом крайнем случае, когда никакие действия и правда не нужны, необходимо в catch-блоке написать комментарий, почему exception проигнорирован.

Впереди две последние главы - о многопоточности и сериализации. Не переключайте канал.

Старые игры на новых виндах

2011-03-20T17:35:00.000+03:00

Есть такая проблема при запуске старых игр (например, Fallout 2 или Diablo 2) в Windows 7 или Vista - глючит цветопередача. На картинке есть области, где цвет как будто инвертирован (зелёный вместо чёрного и т. д.). Так вот, сегодня узнал простое решение проблемы - надо убить explorer перед запуском игры. Эти игры используют 256 цветов, а новый explorer работает с 32х битной палитрой. Поэтому они DirectDraw поделить между собой не могут, или что-то типа того.

Напомню, что убить explorer можно из диспетчера задач (Ctrl+Alt+Delete / диспетчер задач), при этом отвалится рабочий стол и все окна. Запустить игру можно будет из командной строки (cmd). Чтобы вернуть explorer, в меню диспетчера задач найти «Выполнить» и набрать там explorer. Всю эту процедуру можно объединить в один скрипт, который можно взять здесь или здесь.

Хеширование паролей и соль

2011-03-04T17:37:00.003+03:00

Данный текст является переводом статьи «Password hashing and salting» об основах безопасного хранения паролей.
Золотое правило безопасности – если нужно хранить пароли, скажем, в базе данных, то необходимо их хешировать. Достаточно ли это безопасно? Спросите опытного человека, и он посоветует добавить соль. Зачем? - спросите вы. – Потому что это сделает пароль длиннее и безопаснее.
Действительно, добавление соли улучшает безопасность, но не только потому, что пароли становятся длиннее. А потому, что вступает в игру другой (возможно, более существенный) фактор: солёные пароли более устойчивы к атакам с помощью баз данных хешей и радужных таблиц. Обо всём этом - далее.

Хеширование
Хеш-функция – односторонняя функция, преобразующая входной поток данных любого объёма (в нашем случае - пароль) в некоторую строку фиксированной длины. Односторонняя, потому что мы можем преобразовать исходные данные в хеш, но не можем по хешу восстановить исходные данные. Существует много хеш-функций хороших и плохих, быстрых и медленных. Всё, что нам нужно сейчас знать – это то, что в результате все они выдают хеш фиксированной длины (какова эта длина - зависит от хеш-функции). Это означает, что может существовать несколько исходных текстов, которым соответствует один и тот же хеш. Такие совпадения называются коллизиями; они довольно редки, но случаются.
Ещё более важная вещь, которую нужно понимать – то, что не существует математического способа восстановить исходный текст по хешу. Это возможно сделать только перебором – вычислить хеш для каждой перебираемой строки и сравнить с данным.
Чтобы проверить правильность введённого пароля, нужно посчитать его хеш и сравнить с тем, что лежит в базе данных. Псевдокод:

if (sha1(suppliedPassword) ==
    "e5e9fa1ba31ecd1ae84f75caaa474f3a663f05f4") { 
    print "You have typed to correct password!";
}

Строка «e5e9fa1ba31ecd1ae84f75caaa474f3a663f05f4» - хеш секретного пароля, поэтому сообщение будет напечатано только в случае ввода правильного пароля. Здесь используется хеш-функция sha1.

Брутфорс
На самом деле, если вы очень хотите узнать правильный пароль из этого псевдокода, можете вбить хеш в Google и сразу найдёте ответ.
Предположим, нам известно, что пароль состоит из 6 строчных латинских букв. Тогда мы можем написать небольшой скрипт, перебирающий все такие строки от «aaaaaa» до «zzzzzz». Для каждой строки он будет вычислять sha1-хеш и сравнивать с «e5e9fa1ba31ecd1ae84f75caaa474f3a663f05f4». Если совпало, значит, правильный пароль найден. Это называется брутфорсом (brute-force) хеша, и на данный момент это единственный известный способ узнать пароль.
Теперь предположим, что наша система принимает, например, только пароли, состоящие из 4-8 строчных латинских букв. Кто-то нехороший украл нашу базу данных с логинами и хешами паролей пользователей. Это очень плохо, потому что с помощью брутфорса он может получить пароли ко всем аккаунтам.

Соль
Стоит сразу отметить, что как только кто-нибудь получит списки хешей, они смогут рано или поздно узнать пароли. Единственное противодействие, которое мы можем оказать – максимально усложнить перебор паролей, чтобы он стал неэффективным для недоброжелателей.
Мы можем сделать это двумя способами:

Заставить пользователей вводить очень длинные пароли (20-30 символов, например) с множеством спецсимволов.
Усложнить пароли самостоятельно.

Понятно, что второй вариант гораздо проще осуществить. Для этого используется так называемая соль (salt). Прежде, чем посчитать хеш, мы добавим соль к паролю:

saltedPasswordHash = sha1(SALT + password);

Что это даёт? Прежде всего, то, что если кто-то установит пароль «1234», а солью будет строка «NaCl», то для взлома уже недостаточно будет перебрать все четырёхсимвольные последовательности. Восьмисимвольных паролей в миллионы раз больше, во столько же раз и перебор будет дольше.
Добавление соли происходит прозрачно для пользователя, но не для атакующего. Итак, мы получили очень простой способ обезопаситься, однако всё же не стоит на него полностью полагаться.
Потому что хакер может всё же узнать строку-соль, получив наши исходные коды (невозможно? А как они базы данных крадут?). В этом случае перебор становится вновь простым, как будто никакой соли и не было. По этому поводу важное правило: для начала убедитесь, что ваши пароли достаточно сложные. Соль не поможет плохому паролю, разве что против онлайн баз данных хешей.

Взлом с помощью онлайн баз данных хешей
В интернете существуют большие базы данных, где можно ввести хеш и получить исходный текст (конечно, в них есть далеко не все комбинации, но базы постоянно растут). Например, http://hashcrack.com/.
Вернёмся к соли. Велика вероятность, что в базе найдётся хеш для «1234», но не найдётся для «NaCl1234» (хотя и такие можно найти, поэтому лучше использовать соль посложнее). Таким образом, хакер не сможет воспользоваться базами данных для получения паролей, и ему придётся действительно перебирать все варианты. Фокус в том, что строку-соль даже не обязательно держать в секрете (хотя так ещё надёжнее).

Радужные таблицы
Однако и это ещё не всё. Фиксированная соль не помогает при взломе при помощи так называемых радужных таблиц. Радужные таблицы – большие наборы хешей, которые могут быть сгенерированы достаточно быстро. С помощью радужных таблиц и известной соли можно сгенерировать свою базу данных хешей и паролей, которую затем использовать для взлома. Поскольку все пароли защищены одинаковой строкой-солью, то необходима только одна такая база для взлома всех аккаунтов. Конечно, сгенерировать такую базу не просто, но возможно.

Больше соли
Но и от этого мы можем защититься: будем использовать разную соль для разных аккаунтов.

sha1('NaCl-ujasdfas-1234')
    == b9afc2380b4fccef85b3f3da3379d220f1548cad
sha1('NaCl-jubdsdsb-1234')
    == bd3a831fcd202b546307be8ea5b4a76c87700c4e
sha1('NaCl-jehnwnad-secret123')
    == c0678ee585f635b9bbd91cf7b2a5597e8745521c

Первая часть пароля – фиксированная соль. Она теперь не очень нужна, но мы всё же её оставим. Вторая часть, выделенная жирным, - переменная соль, своя у каждого аккаунта. Третья часть – пароль пользователя.
Как же получить переменную соль для проверки пароля? Очень просто, её можно хранить в открытом виде в базе аккаунтов. Даже если хакер получит базу данных, ему придётся генерировать разные радужные таблицы для взлома каждого аккаунта. Ещё один профит от использования переменной соли – если два пользователя введут одинаковые пароли, хранимые хеши всё равно будут разными (см. первый и второй пароль в примере).
Ура, теперь одной радужной таблицей не взломать все аккаунты сразу!

Заключение
К сожалению, нет стопроцентного способа защитить свои хеши. Всегда возможно взломать хеши брутфорсом, но, следуя перечисленным советам, можно сделать этот процесс сложным и долгим. Но даже это не остановит хакера, охотящегося за одним аккаунтом (root или Administrator, например). Поэтому убедитесь, что ваши пароли достаточно сложны, чтобы сделать брутфорс длительным. Регулярно меняйте пароли, чтобы к моменту завершения брутфорса взломанный пароль был бы уже не актуален.
И напоследок ещё несколько советов:

Все пароли должны удовлетворять определённым требованиям безопасности (зависит от приложения, но 8+ букв и спецсимволов почти всегда достаточно).
Пароли должны хешироваться хорошей хеш-функцией (sha1 или лучшей, но не md5).
Пароли должны хешироваться с хорошей переменной солью.
Читайте про информационную безопасность. Это очень сложная, но и очень важная область.

Effective Java: General Programming (2/2)

2011-02-19T18:23:00.000+03:00

Item 51. Конкатенация строк медленна.
Конкатенация ("+") n строк выполняется за время n² - следствие того, что строки в Java неизменяемы (immutable); когда соединяются две строки, содержимое обеих полностью копируется в новую. Поэтому если требуется объединить большое или заранее неизвестное количество строк, рекомендуется использовать StringBuilder (есть ещё StringBuffer, но он синхронизован, поэтому медленнее).

Item 52. Ссылайтесь на объекты посредством их интерфейсов.
Если существует подходящий интерфейс, то лучше объявлять все параметры, возвращаемые значения, переменные и поля именно этим интерфейсом, а не имплементирующим классом.
Хорошо:

List<Subscriber> subscribers = new Vector<Subscriber>();

Плохо:

Vector<Subscriber> subscribers = new Vector<Subscriber>();

Это делает код более гибким, позволяет сменить имплементацию изменением всего одной строки. Исключения составляют те случаи, когда используются методы, специфичные для имплементации, либо код полагается на некоторые особые свойства имплементации (например, потокобезопасность Vector-а).

Item 53. Предпочитайте интерфейсы вместо reflection.
Суть в следующем: reflection - весьма небезопасная и малопроизводительная вещь, к тому же ещё и редко необходимая. Но если уж так случилось, что без неё никуда, то лучше хотя бы ограничить её использование. В большинстве программ, использующих недоступные в compile time классы, существует некоторый интерфейс или суперкласс, через которые можно ссылаться на экземпляры этого недоступного класса. То есть предлагается создавать экземпляры через reflection, а затем работать с ними через интерфейс или суперкласс, как с любыми другими объектами.

Item 54. Применяйте нативные (native) методы с умом.
Нативные методы имеют 3 основных назначения:

Обеспечение доступа к платформо-зависимым средствам.
В целом допустимо использовать нативные методы для этого, хотя Java платформа с каждой новой версией постепенно избавляет от такой необходимости.
Возможность использовать устаревшие (legacy) библиотеки.
Тоже допустимо.
Увеличение производительности приложения.
В старых версиях Java и JVM это имело смысл, сейчас - практически нет. Java стала намного быстрее, большинство задач можно решить без нативных методов без значительных потерь в производительности.

Использование нативных методов имеет много минусов: это небезопасно, платформо-зависимо и может даже ухудшить производительность.

Item 55. Оптимизируйте с умом.
Преждевременная оптимизация - зло. Не нужно ничего оптимизировать, пока не получено правильное и надёжное, хоть и медленное, решение. Если программа хорошо спроектирована, отдельные модули можно будет оптимизировать позже, без изменений в других модулях.
И, конечно, когда действительно приходит время для оптимизации, нужно сначала выяснить (например, с помощью профайлера), в каком месте программа тратит больше всего времени. Народная мудрость: 80% времени программа проводит в 20% кода.

Item 56. Соблюдайте всеобщие соглашения о наименованиях (naming conventions).
Платформа Java имеет устоявшиеся принципы именования всего (пакетов, классов, интерфейсов, методов, ...), большую часть которых можно найти в Java Language Specification (6.8). Рекомендуется их строго соблюдать и не нарушать без веской на то причины, иначе поддерживать ваш код и использовать его API будет затруднительно.
Данный параграф содержит эти принципы, переписывать частично или полностью смысла нет.

Effective Java: General Programming (1/2)

2011-01-19T21:39:00.000+03:00

Эта глава книги Effective Java собрала более общие советы по написанию кода на Java (и не только). Параграфов довольно много, поэтому я разбил свой сжатый пересказ на две части.

Item 45. Минимизируйте область видимости локальных переменных.
Это улучшает читабельность кода и уменьшает число потенциальных ошибок.
Прежде всего, по возможности объявлять локальную переменную надо там, где она впервые используется. Далее, почти все объявления локальных переменных должны содержать инициализацию. Исключение - когда инициализацию нужно поместить в try/catch блок, а сама переменная нужна снаружи него.
Отдельно следует отметить циклы. Цикл for предоставляет возможность объявлять переменные цикла (loop variables) доступными только для тела самого цикла, что делает его более предпочтительным, нежели циклы while.

Item 46. Предпочитайте for-each циклы вместо for.
Опять же, это делает код более читабельным и уменьшает шансы ошибиться по невнимательности. Но есть и случаи, когда for-each не подходит: фильтрация (когда нужно удалять элементы из коллекции, нужен явный итератор), трансформация (когда нужно заменять одни элементы списка или массива на другие, нужен явный итератор или переменная-индекс), параллельная итерация по нескольким коллекциям.

Item 47. Знайте и применяйте библиотеки.
Изобретать колёса не имеет смысл, потому что:

это лишняя трата времени;
вряд ли получится лучше, чем уже написано ранее;
библиотеки совершенствуются без вашего участия.

Полезно иногда смотреть в release notes новых версий библиотек.
Приведён хороший пример кривого колеса: самописная функция, возвращающая псевдослучайное число из интервала [0, n):

static int random(int n) {
    return Math.abs(rnd.nextInt()) % n;
}

Функция выглядит нормально, но в ней скрыты целых три изъяна. Предлагается попробовать поискать их самостоятельно, однако два их них весьма нетривиальны (я-то их сам точно не нашёл бы). Эти недостатки перечислены в конце поста.
Вместо такой функции следует использовать Random.nextInt(int), где этих проблем нет.

Item 48. Избегайте float и double, если нужны точные результаты.
Типы float и double представляют собой числа с плавающей запятой (floating point). Это означает, что они хранят не точное значение числа, а максимально близкое к нему приближение. Например, они не могут точно хранить числа 0.1, 0.01, 0.001 и т.д. Если задача требует точных результатов, лучше использовать BigDecimal (хоть они и менее удобны и быстры, чем примитивы), либо сводить эту задачу к целым числам (например, считать деньги не в рублях, а копейках).

Item 49. Предпочитайте примитивы вместо объектных типов.
(здесь и далее под объектным типом подразумевается объектная обёртка примитива (boxed primitive))
Автобоксинг и автоанбоксинг (Java 1.5) размыл, но не стёр различия между ними. А различия таковы:

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

Когда следует применять объектные типы:

при работе с коллекциями и другими параметризированными классами;
при рефлексивном (reflective) вызове методов.

В остальных случаях, когда есть выбор, рекомендуется применять примитивы. Если приходится иметь дело с объектными типами, следует помнить:

если программа сравнивает объектные типы с помощью ==, то сравниваются ссылки на объекты, что почти всегда не то, что вы хотите;
когда в выражении замешаны и примитивы, и объектные типы, выполняется unboxing последних;
unboxing может вызвать NullPointerException.

Item 50. Избегайте строк, если другие типы больше подходят.
Строки - не замена для других типов значений. Поступающая в программу информация, будь то чтение из файла, обмен по сети или ввод с клавиатуры, чаще всего приходит именно в текстовом виде и должна храниться в String только если действительно представляет собой некоторый текст. Если же есть более подходящий тип для данных (числовые типы, boolean, ...), нужно использовать его.
Строки - не замена для enum-констант. Об этом было в Item 30.
Строки - не замена для составных типов. Так делать плохо:

String compoundKey = className + "#" + i.next();

Для составных типов лучше писать составные классы.
Строки не годятся для предоставления доступа к чему-либо. Имеется в виду то, что, например, строки нехорошо использовать в качестве ключей доступа к определённым данным в том случае, если клиентский код может нарушить целостность этих данных, предоставив неправильный или «чужой» ключ.

Далее спойлер (см. Item 47)

.

.

.

.

.

.

.

Три изъяна функции из Item 47:

Если rnd.nextInt() выдаст Integer.MIN_VALUE, то функция вернёт отрицательное значение.
Если n - малая степень двойки, то последовательность генерируемых чисел довольное скоро начнёт повторять саму себя.
Если n - не степень двойки, то некоторые псевдослучайные числа будут генерироваться чаще других.

Nautilus: сортировка файлов по имени

2011-01-11T01:56:00.002+03:00

А вы знали, как хитро Наутилус сортирует файлы по имени?

Помимо всего прочего, Наутилус умеет выделять из имён файлов числа и упорядочивать их именно как числа, а не как последовательность символов (см. последние три файла).

Это всё прекрасно и очень человечно, но начало мешать. Моя видеокамера (не столь человечная) нумерует файлы шестнадцатеричными числами, в результате чего они у меня неправильно сортируются. И что самое плохое - я пока не нашёл решения этой проблемы для Наутилуса (переходить на другие менеджеры только из-за этого не хочется). Смена значения $LC_COLLATE не помогает, так как локаль здесь вообще ни при чём.

Do not touch the colon

2011-01-08T00:16:00.000+03:00

Увидел у antilamer-а:

Mark writes, "advice that is true for life as well as code."
# The colon is very important. DO NOT TOUCH.

Colon одновременно означает двоеточие и толстую кишку. Буду знать.

Приключение в коде

2010-12-30T18:37:00.000+03:00

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

public final class MyApplication extends Application {

    private final Core core;

    public MyApplication() {
        super();
        core = new Core(this);
        core.init(); // здесь обращаемся к бд
    }

    public Core getCore() {
        return core;
    }

}

(здесь и далее - упрощённый код)

Но была проблема: мой SQLiteOpenHelper отказывался давать мне доступ к базе данных внутри core.init(): вызовы getReadableDatabase и getWritableDatabase кидали недокументированные NullPointerException-ы.

Проблема оказалась в том, что после вызова конструктора суперкласса в MyApplication, экземпляр последнего(также известный как application context) ещё не был готов к работе. Коллега подсказал использовать хук onCreate() для инициализации core и это помогло. В конечном итоге это выглядит так:

public final class MyApplication extends Application {

    private final Core core;

    public MyApplication() {
        super();
        core = new Core(this);
    }

    @Override
    public void onCreate() {
        core.init() // здесь обращаемся к бд
    }

    public Core getCore() {
        return core;
    }
}

И прекрасно работает.

Effective Java: Методы

2010-12-14T00:29:00.002+03:00

Переходим к следующей главе книги.

Item 38. Проверяйте параметры на корректность.
Большинство методов и конструкторов имеют некоторые ограничения на передаваемые им параметры. Проверка корректности этих параметров позволяет обнаруживать проблемы как можно раньше, что облегчает её исправление.
Для публичных методов и конструкторов лучше всего сразу проверять параметры и кидать соответствующие exception-ы, если они некорректны. Обычно это бывают IllegalArgumentException, IndexOutOfBoundsException или NullPointerException. Ограничения на параметры и exception-ы, которые кидаются при их нарушении должны быть задокументированы.
Для неэкспортируемых (закрытых) методов и конструкторов вы, как автор пакета, сами отвечаете за корректность передаваемых параметров и должны использовать только assertions для их проверки.
Есть и исключения из этих правил. Одно из них - когда проверка корректности слишком сложна и затратна и она происходит неявно во время выполнения метода. Пример такой ситуации - сортировка списка Collections.sort(List), который может содержать несравниваемые элементы. Иногда в таких случаях полезно применять идиому перевода исключений (exception translation idiom), чтобы клиентский код всегда получал понятное исключение вроде IllegalArgumentException вместо того, которое порождается внутри закрытого кода.

Item 39. Делайте защитные копии (defensive copies), когда нужно.
Здесь название говорит сам за себя. Вообще, программировать нужно так, как будто все клиенты только и будут пытаться нарушить инварианты ваших классов.
Защитные копии - ещё одна причина использовать неизменяемые (immutable) объекты в качестве компонентов.

Item 40. Проектируйте сигнатуры методов внимательно.
Здесь собраны советы, не вошедшие в другие параграфы.

Выбирайте наиболее подходящие имена для методов.
Не нужно слишком много "удобных" методов. Для каждого действия, обеспечиваемого классом или интерфейсом, пишите ровно один полнофункциональный метод. Особенно это касается интерфейсов. Добавляйте укороченный метод только если он будет часто использоваться.
Избегайте большого числа параметров. Лучше всего, когда их не больше четырёх. Три способа уменьшить их количество: разбить метод на несколько, создать вспомогающий класс, группирующий часть параметров, использовать шаблон Builder.
В типах параметров предпочитайте интерфейсы вместо имплементирующих классов.
Предпочитайте двухэлементый enum вместо boolean-параметра, где возможно. Например, если конструктор класса Thermometer принимает параметр, определяющий единицу измерения температуры, то лучше единицы измерения засунуть в enum, нежели выбирать одну в случае true и вторую в случае false.

Item 41. Используйте перегрузку (overload) осторожно.
В отличие от переопределения (override), перегрузка работает контринтуитивно: выбор метода происходит во время компиляции, а не в рантайме. Поэтому перегрузку следует применять только там, где этот выбор очевиден. Лучше всего, когда все взаимоперегружающие методы имеют разное количество параметров.

Item 42. Используйте varargs разумно.
Varargs - аргументы переменной длины. При замене аргументов метода на varargs следует учесть все возможные последствия, поскольку некоторые не компилируемые ранее вызовы метода станут допустимыми. Кроме того, не стоит забывать о возможной потере в производительности. Один из вариантов обойти эту потерю - предоставить отдельные методы для 1, 2, 3, ... аргументов и отдельный с varargs.

Item 43. Возвращайте пустые массивы и коллекции, а не null.
Возвращать null вместо пустого массива или коллекции нет смысла. Это лишь добавляет лишний код в методе и лишний код для обработки его возвращаемого значения. Если создавать пустую коллекцию или массив слишком дорого, то можно их кэшировать.

Item 44. Пишите комментарии к каждому экспортируемому элементу API.
Вряд ли кто-нибудь станет с этим спорить. Про утилиту javadoc знают почти все, а этот параграф посвящает в основы документирования API для последующего её применения.

How machines work

2010-12-03T18:35:00.003+03:00

How machines work - интереснейшая телепередача канала Discovery.

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

Серии легко найти на торрентах, например, вот.

UPD. 1 Забыл сказать. В русском переводе у них там иногда случаются заскоки типа "биллиона людей" или "стекло усиливает солнечный свет", поэтому надо слушать внимательно и вдумываться. Но это редко попадается. В целом очень полезно.

UPD. 2 Дорогие переводчики! Послушайте меня! В России не применяется слово "биллион"! Нет у нас такого числа! Америкаский billion = миллиард! Английский billion = триллион!
Обидно, что даже Футурама в переводе Ren-TV очень сильно этим грешит.

Перегрузка и переопределение: памятка

2010-12-02T20:38:00.004+03:00

Override - переопределение - когда подкласс подсовывает свою реализацию метода вместо реализации в суперклассе. При вызове метода выбирается наиболее "специфическая" реализация, то есть реализация в подклассе, если она есть, приоритетнее реализации в суперклассе. В Java выбор выполняемого метода при переопределении происходит динамически (в рантайме) и не зависит от того, каким типом объявлена ссылка на объект:

public class TestOverriding {
    
    private static class Parent {
        String getName() { return "Parent"; }
    }

    private static class Child extends Parent {
        @Override
        String getName() { return "Child"; }
    }

    public static void main(String[] args) {
        Parent child = new Child();
        // Prints "Child"
        System.out.println(child.getName()); 
    }
}

Overload - перегрузка - объявление методов (или конструкторов) с одинаковыми именами, но разными с сигнатурами. Пример - все конструкторы любого класса, если их больше одного. В Java выбор выполняемого метода при перегрузке происходит статически (во время компиляции) и не зависит от типа объекта в рантайме:

import java.util.Collection;
import java.util.HashSet;
import java.util.Set;

public class TestOverloading {

    static void classifyCollection(Collection<?> c) {
        System.out.println("Collection");
    }

    static void classifyCollection(Set<?> s) {
        System.out.println("Set");
    }

    public static void main(String[] args) {
        Collection<?> c = new HashSet<Object>();
        // prints "Collection"
        classifyCollection(c);
    }
}

N things you didn't know about Java

2010-11-30T12:40:00.000+03:00

На ibm.com есть серия статей "5 things you didn't know about ..." о различных аспектах Java. Те вещи, которые показались мне наиболее интересными, я изложу здесь.

Iterator, you surprise me!
Не секрет, что многие используют итераторы очень часто, но когда вы в последний раз видели его интерфейс?

Во-первых, итератор умеет удалять элементы из итерируемой коллекции. Это сделано, в основном, для избежания ошибок вроде ConcurrentModifiedException, которые возникают при модификации коллекции, у которой есть незакрытые итераторы. Некоторые коллекции позволяют делать такие изменения, но в общем случае Iterator.remove() безопаснее.

Во-вторых, существует подинтерфейс итератора ListIterator, поддерживаемый списками. Кроме всего прочего, он умеет добавлять элементы в список и осуществлять двунаправленный скроллинг.

Scanner
Класс Scanner предназначен для парсинга текста и представляет простой API для его преобразования в стандартные типы данных Java. Приводится пример использования класса для парсинга списка задач такого типа:



fetch 1 head

fetch 3 eye

fetch 1 foot

attach foot to head

attach eye to head

admire

Код будет выглядеть следующим образом:

Scanner scanner = new Scanner(commandFile);
// Commands come in a verb/number/noun or verb form
while (scanner.hasNext()) {
    String verb = scanner.next();
    if (verb.equals("fetch")) {
        int num = scanner.nextInt();
        String type = scanner.next();
        fetch(num, type);
    } else if (verb.equals("attach")) {
        String item = scanner.next();
        String to = scanner.next();
        String target = scanner.next();
        attach(item, target);
    } else if (verb.equals("admire")) {
        admire();
    } else {
        System.out.println("I don't know how to " + verb
                + ", marthter.");
    }
}

Timer
Классы java.util.Timer и TimerTask представляют удобный способ выполнять задачи с задержкой или с некоторой периодичностью. Пример:

public class Later
{
    public static void main(String[] args)
    {
        Timer t = new Timer("TimerThread");
        t.schedule(new TimerTask() {
            public void run() {
                System.out.println("This is later");
                System.exit(0);
            }
        }, 1 * 1000);
        System.out.println("Exiting main()");
    }
}

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

SwingX
Иногда компонентов Swing становится недостаточно, что частично компенсирует проект SwingX. Возможности библиотеки SwingX включают:

сортировка, фильтрование и подсветка текста для таблиц, деревьев, списков;
поиск;
автодополнение;
фреймворк для аутентификации;
компонент TreeTable;
компонент сворачиваемая панель;
компонент выбор даты;
компонент совет дня.

Swing threading
Swing рассчитан на то, что приложения на его базе будут запускаться не в основном(main) потоке, а в отдельном. И если сам Swing может простить такую ошибку, то некоторые его компоненты - нет.
Java платформа предоставляет класс SwingUtilities, который поможет вам запустить Swing-приложение в отдельном потоке. Используйте метод invokeLater().

DisableExplicitGC
Явный вызов сборщика мусора (System.gc()) - плохая идея и типичный Java performance антипаттерн. Для игнорирования этих вызовов в HotSpot JVM можно использовать флаг -XX:+DisableExplicitGC. Аналогичный флаг есть и для IBM JVM: -Xdisableexplicitgc.

HeapDumpOnOutOfMemoryError
Флаг -XX:+HeapDumpOnOutOfMemoryError заставляет JVM при переполнении делать снапшот кучи для последующего анализа с помощьют утилиты jhat. В IBM JVM эта возможность включена по умолчанию.

Статья 5 things you didn't know about ... multithreaded programming уже переведена на хабрахабре.

Также полезно ознакомиться, хотя бы поверхностно, со статьями про мониторинг производительности(раз, два) и про аргументы командной строки для JVM.

Интересный вопрос о Java

2010-11-20T02:34:00.001+03:00

Какое значение примет переменная valueInQuestion?

{ int valueInQuestion = o(); }

private int o() {

try { return 1; } finally { return 2; }

}

Ответ, как всегда, кроется в JLS: 14.17 The return Statement, в последнем абзаце.

За задачу спасибо Darth Beleg.

Effective Java: Enums and Annotations

2010-11-17T00:01:00.003+03:00

Item 30. Используйте enum-ы вместо целочисленных контант.
В Java 1.5 был введён новый тип - enum (перечисление). Перечисление имеет фиксированный набор допустимых значений: это могут быть времена года, планеты солнечной системы, масти игральных карт и т. п. Основная идея enum-ов: это классы, экпортирующие по одному экземпляру для каждого своего значения. Enum-ы - это обобщение синглотонов.
Enum-ы обеспечивают безопасность программы на этапе компиляции. Если вы объявляете параметр enum-типа, то гарантируется, что значение, которое будет передано методу, будет одним из элементов этого enum-а и не null. Попытки передать значение неправильного типа, ровно как и использование == для сравнения элементов различных enum-ов, приведут к ошибкам на этапе компиляции программы.
В enum-ы можно добавлять свои собственные методы, чтобы, например, ассоциировать некоторые данные с конкретными элементами. Можно имплементировать ими интерфейсы; в них уже имплементированы Comparable и Serializable. Есть готовые методы ordinal(), valueOf(String) и toString(). Допустимо добавлять даже абстрактные методы, чтобы обеспечить каждый элемемент перечисления собственной реализацией.
Для ознакомления с другими, реже применяемыми особенностями enum-ов рекомендуется прочитать параграф из книги целиком.

Item 31. Используйте поля-члены enum-ов вместо их порядковых номеров.
Все enum-ы имеют метод ordinal(), возврающий порядковый номер элемента, но его использование почти всегда затрудняет поддержку и развитие кода. Вместо него лучше вводить собственные поля и работать с их значениями.
В спецификации метода ordinal() написано: "Most programmers will have no use for this method. It is designed for use by general-purpose enum-based data structures such as EnumSet and EnumMap." Если вы не пишите подобную структуру, то лучше всего обходить этот метод стороной.

Item 32. Используйте EnumSet вместо битовых полей.
Если элементы перечисляемого типа используются в множествах (set), одним из способов реализации является набор констант-степеней двойки с последующим применением битовой арифметики к ним. Этот путь опасен и неудобен. Вместо него рекомендуется использовать уже готовую реализацию - EnumSet. К слову, если количество элементов в enum-е не более 64х, то в EnumSet-е используется та же самая битовая арифметика, а данные о наборе лежат в одном long-е, что обеспечивает максимальную производительность структуры.

Item 33. Используйте EnumMap вместо индексации номеров.
Аналогично предыдущему параграфу, только Map вместо Set. Имплементация Map, использующая элементы enum-а в качестве ключей, уже готова - EnumMap, и не нужно придумывать ничего своего. Внутри неё для хранения данных используется обычный массив, что обеспечивает хорошую производительность.

Item 34. Эмулируйте наследование от enum-ов с помощью интерфейсов.
Наследование для enum-ов запрещено не случайно. Но в некоторых случаях подобный механизм просто необходим (например, если речь идёт об опкодах, и нужно в клиентском коде уметь создавать свои). Для этого очень удобно объявить единый интерфейс, отделённый от перечисления, и имплементировать его enum-ом.

Item 35. Предпочитайте аннотации вместо соглашений о наименованиях.
До релиза Java 1.5 в программах применялись соглашения о наименованиях, чтобы указать на особое трактование некоторых элементов кода. Например, JUnit изначально требовал называть тестовые методы, начиная со слова test. Такой подход имеет массу очевидных недостатков. Все эти проблемы были успешно решены в Java 1.5 с помощью аннотаций (annotations).
Параграф приводит несколько примеров создания своих аннотаций. Вывод таков, что аннотации - достаточно мощный и полезный инструмент, и теперь нет причин использовать соглашения о наименованиях.

Item 36. Нерпеменно используйте аннотацию Override.
Аннотацию Override можно применять только к объявлениям методов. Она указывает на то, что объявление метода переопределяет его объявление в суперклассе. Повсеместное использование этой аннотации поможет избавиться от проблем, возникающих, когда допускается ошибка в объявлении метода, и вместо переопределения происходит его перегрузка (overloading, это когда два метода имеют одинаковые названия, но разные параметры). Современные среды разработки производят инспекции кода и предупреждают о возможности таких проблем.
Начиная с релиза 1.6, аннотацию Override можно использовать не только в подклассах, но и в подинтерфейсах.

Item 37. Используйте интерфейсы-маркеры (marker interfaces) для определения типов.
Интерфейс-маркер не содержит методов и полей, а только помечает класс, который его имплементирует, как имеющий определённое свойство. Очевидный пример - интерфейс Serializable.
Интерфейсы-маркеры имеют следующие преимущества перед маркирующими аннотациями (Item 35):

Они определяют тип, что позволяет осуществлять проверку на этапе компиляции. Например, метод ObjectOutputStream.write(Object) должен бы в качестве параметра принимать не Object, а Serializable. Но по необъяснимым причинам авторы класса этого не сделали.
Интерфейсы могут наследоваться, что позволяет более точно осуществлять таргетинг. Примером здесь служит интерфейс Set, наследующийся от Collection и не добавляющий никаких методов. На самом деле Set - не совсем интерфейс-маркер, так как он переопределяет контракты некоторых методов интерфейса Collection.

Преимущества аннотаций-маркеров перед интерфейсами:

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

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

P.S. На андроиде enum-ы не очень хороши и рекомендуется их избегать. Читать.

Про try-catch блоки Java

2010-11-12T23:36:00.002+03:00

Если выполнение блока try завершилось неудачно и выкинулся некоторый Throwable T, то catch-блоки будут просматриваться сверху вниз в поисках подходящего. Подходящим является блок, обрабатывающий такой Throwable V, что тип T можно привести к типу V.

Это означает, что следующий код содержит недостижимый блок:



try {

// ...

} catch (Exception e) {

// ...

} catch (NullPointerException e) {

// ...

}

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

Иерархия пакетов в Java

2010-11-07T22:04:00.000+03:00

Иерархии пакетов в языке Java нет. Конечно, "про себя" мы можем думать, что пакет java.util.regex лежит внутри пакета java.util, но для компилятора это просто два разных пакета.

Так, классы codingbreak.test.ClassInTest и codingbreak.test.sub.ClassInSub не имеют доступа к пакето-приватным(package-private) полям и методам друг друга.

Кроме того, например, импорт java.util.* не покрывает импорта java.util.regex.Pattern.

Effective Java: Generics

2010-11-07T21:48:00.001+03:00

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

Item 23. Не используйте raw классы в новом коде.

Generic-и были добавлены в Java 1.5, чтобы сделать программы более безопасными и читаемыми. Поддержка raw-типов сохранилась только для обратной совместимости программ. При написании нового кода не стоит их использовать, так как это небезопасно.
Иногда воспользоваться generic-ами не представляется возможным, например, когда неизвестно, что будет лежать в передаваемой коллекции. Для этого случая в языке предусмотрены bounded и unbounded wildcard types.

Item 24. Не игнорируйте предупреждения компилятора об опасном преобразовании типов.
Чтобы написать по-настоящему безопасный код, который не будет порождать ошибки времени выполнения, нужно рассматривать каждое такое предупреждение компилятора.
Если избавиться от предупреждения по каким-либо причинами невозможно, но сам код точно безопасный, тогда (и только тогда) следует использовать аннотацию @SuppressWarnings("unchecked"), причём применять её нужно всегда на как можно меньший кусок кода. Рекомендуется к каждому использованию этой аннотации добавлять комментарий, объясняющий, почему код безопасен.

Item 25. Используйте списки (lists) вместо массивов.
Отмечается два важных отличия массивов и типизированных контейнеров.

Массивы - ковариантны, Generic-и - инвариантны. Это значит, что если Sub - подкласс класса Super, то Sub[] - подкласс Super[], что неверно для типизированных классов. Это делает использование типизированных контейнеров более безопасным, чем использование массивов (хотя на первый взгляд кажется, что это только доставляет неудобства).
Проверка типов для массивов происходит во время выполнения программы, а использование Generic-ов накладывает ограничения только на этапе компиляции, в рантайме же эта информация о типизации совершенно не используется (вернее сказать, её к этому времени просто уже нет).

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

Item 26. Предпочитайте типизированные классы (generic types).
Generic-и - это хорошо, и если можно добавить их к классу, то нужно это сделать. В параграфе описывается процесс изменения класса для его типизации.

Item 27. Предпочитайте типизированные методы (generic methods).
Аналогично предыдущему параграфу. Отмечается удобство использования типизированных фабричных методов:
Map<String, List<String>> anagrams = newHashMap();
вместо
Map<String, List<String>> anagrams = new HashMap<String, List<String>>();
Generic-и могут быть рекурсивными.

Item 28. Используйте bounded wildcards для улучшения своего API.
Как было сказано выше, generic-и инвариантны, т.е. List<String> не является подклассом List<Object>. Иногда это доставляет серьёзные неудобства, но есть выход - bounded wildcards. Они бывают двух видов - "extends" и "super", каждый из которых покрывает, соответственно, все подклассы и все суперклассы указанного типа. Для того, чтобы быстро соображать, какой их них следует использовать, можно пользоваться т.н. правилом PECS: "PECS stands for producer-extends, consumer-super."
Не рекомендуется использовать wildcard-типы в качестве возвращаемых типов.

Item 29. Про безопасные гетерогенные контейнеры.
Типичное применение generic-ов (как в Collections API) ограничивает нас фиксированным числом типовых параметров контейнера. Это ограничение можно обойти, если типизировать не контейнер целиком, а только его ключ. В данном параграфе приводится пример написания такого безопасного контейнера, а также отмечаются некоторые особенности класса Class<T> как параметризированного типа.

Effective Java: Классы и интерфейсы

2010-10-13T00:32:00.002+04:00

Продолжение серии постов об основных идеях книги Effective Java (2-е издание).

Item 13. Минимизируйте доступность классов и их членов.
Известное правило: каждый класс, метод или поле класса нужно делать настолько недоступными, насколько это возможно. Другими словами, необходимо минимизировать открытость вашей программы до тех пор, пока это возможно для использования её по назначению.

Item 14. В открытых (public) классах всегда используйте гетеры и сетеры (getters and setters) вместо открытых полей.
Открытые классы никогда не должны обеспечивать прямой доступ к своим полям, чтобы не позволить нарушить целостность данных. В меньшей степени это относится к неизменяемым (immutable) полям, однако, прежде, чем открыть доступ к такому полю, следует помнить, что публичный API класса нельзя будет изменить в будущем.
Если класс приватный (private) или пакето-приватный (package-private), то допустимо применение прямого доступа к полям.

Item 15. Старайтесь писать неизменяемые (immutable) классы.
Этому есть несколько причин:

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

Единственный недостаток у неизменяемых классов - это то, что для каждого значения нужен новый объект, что увеличивает используемый объём памяти.
В начале параграфа приводится необходимое и достаточное условие того, чтобы класс был неизменяемым.

Item 16. Предпочитайте композицию вместо наследования.
Наследование - мощный инструмент, но, будучи применённым неправильно, может сделать программу уязвимой. Наследование вполне допустимо, если суперкласс и наследники находятся под контролем одних и тех же программистов. В ином случае возникает опасность.
Наследование нарушает инкапсуляцию. Чтобы правильно отнаследоваться от класса, нужно знать, как он работает. Таким образом, если изменится суперкласс, его подклассы могут перестать функционировать. Поэтому каждый класс должен быть либо спроектирован для наследования от него клиентским кодом, либо такое наследование должно быть запрещено.
Зачастую, можно отказаться от наследования, заменив его композицией, то есть вместо подкласса написав т.н. класс-обёртку (wrapper).

Item 17. Проектируйте и документируйте возможность наследования от класса, либо запрещайте это наследование.
Если предполагается, что от класса будут наследоваться, то нужно документировать не только то, что перегружаемые методы делают, но и то, как они это делают. Безусловно, это нарушает инкапсуляцию.
Кроме того, необходимо открыть доступ к некоторым внутренностям такого класса с помощью модификатора protected.
Есть ещё один важный момент: ни конструктор, ни методы clone, readObject не должны вызывать перегружаемые методы, прямо или косвенно. В книге приводится хороший пример, демонстрирующий это.

Item 18. Предпочитайте интерфейсы абстрактным классам.
Поскольку Java не поддерживает множественное наследование, применение абстрактных классов сильно ограничено по сравнению с интерфейсами. Вообще, у интерфейсов много преимуществ по сравнению с абстрактными классами, достаточно очевидных, но есть и недостаток: внести изменения в уже существующий, широко применяемый интерфейс практически невозможно.
Стоит заметить возможность комбинирования преимуществ абстрактных классов и интефейсов путём введения т.н. skeletal implementation. Наиболее известные примеры этого - AbstractCollection, AbstractMap, AbstractSet и AbstractList.

Item 19. Используйте интерфейсы только для определения типов.
Другими словами, не нужно их использовать не по назначению, например, для хранения значений констант.

Item 20. Предпочитайте иерархии классов вместо tagged классов.
Под tagged классом имеется в виду такой класс, который содержит некоторое поле-тег, определяющее его поведение. Приведён пример такой реализации класса Shape, в котором есть поле shape, определяющее конкретную форму объекта. Такой подход имеет ряд недостатков и не имеет значительных преимуществ. Вместо этого рекомендуется строить иерархию классов. В данном случае следовало бы организовать абстрактный класс Figure, в котором объявляются основные методы, и классы-наследники, каждый из которых представляет конкретную фигуру.

Item 21. Используйте объекты-функции (function objects) для представления стратегий (strategies).
Шаблон проектирования Стратегия стоит использовать, когда необходимо определить поведение некоторой функции путём передачи ей другой функции. Ярким примером использования этого шаблона в Java является интерфейс Comparator.

Item 22. Предпочитайте статические внутренние классы вместо нестатических.
Есть 4 типа внутренних классов: статические, нестатические, анонимные и локальные. Каждый из этих типов имеет своё применение, о чём и рассказано в параграфе.
Хотелось бы отметить следующее: синтаксически разница между статическими и нестатическими внутренними классами очень мала - первый объявлен с модификатором static, второй - нет. Однако, на деле эти два типа имеют значительные различия. Общее правило для выбора между ними таково: если внутренний класс не требует доступа к содержащему его экземпляру, то следует использовать статический класс.

Effective Java: Общие для всех объектов методы

2010-09-29T19:04:00.004+04:00

Следующая глава книги.

Item 8. Соблюдайте контракт метода equals, переопределяя его.

Случаи, когда переопределять метод equals не требуется:

каждый экземпляр класса по определению уникален;
нет необходимости сравнивать экземпляры "логически";
суперкласс переопределил этот метод, и его поведение подходит и для данного подкласса;
класс приватный или package-private и вы уверены, что метод equals не используется.

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

всегда следует переопределять метод hashCode при переопределении equals;
не надо увлекаться: к примеру, класс File не углубляется до проверки, указывают ли различные символические ссылки на один и тот же файл;
объявление метода equals стоит писать очень внимательно, в противном случае вместо override можно сделать overload и ошибку будет довольно сложно найти.

Item 9. Всегда переопределяйте метод hashCode при переопределении equals.

Эквивалентные объекты должны иметь одиннаковый хэш-код. Несоблюдение этого правила приведёт к нарушению работы, как минимум, некоторых коллекций.
В параграфе приводится ряд рекомендаций по написанию удачной хэш-функции.

Item 10. Всегда переопределяйте метод toString.

Это добавляет удобства при использовании класса, так как строка (707) 867-5309 говорит гораздо больше, чем PhoneNumber@163b91.
Формат возвращаемой строки может быть как описан, так и не описан в документации класса. Естественно, будучи объявленным в документации, формат не сможет быть изменён в дальнейшем. В любом случае следует обеспечивать программный доступ к полям, используемым в toString, чтобы не провоцировать клиентский код парсить строку, возвращаемую последним.

Item 11. Переопределяйте метод clone с умом.

Этот параграф содержит слишком много пунктов, которые следовало бы написать сюда, поэтому я этого делать не буду. Если нужно спроектировать объект с возможностью клонирования, придётся перечитать параграф целиком. Однако, отдельно хотелось бы отметить следующие факты:

При переопределении метода clone в non-final классе всегда следует возвращать объект, полученный вызовом super.clone, только тогда он будет иметь правильный тип.
Если класс содержит ссылки на изменяемые (mutable) объекты, то при клонировании эти объекты должны быть рекурсивно склонированы вместо простого копирования ссылок на них, которое происходит по умолчанию. Общее правило таково, что клон и оригинал не должны иметь общих внутренностей, кроме неизменяемых (immutable).
Иногда можно обойтись копирующим конструктором, это гораздо проще.

Item 12. Подумайте об имплементации интерфейса Comparable.

Если для объектов рассматриваемого класса существует некоторый естесственный порядок (natural order), имеет смысл имплементировать этот интерфейс. Небольшие усилия, затраченные на создание функции сравнения, открывают для класса всю мощь стандартных алгоритмов и коллекций, требующих существование этого порядка. Обычно этот интерфейс имплементируют классы, представляющие какое-либо значение: число, дату и время и т.д.