Coding Break

Переезд блога

2013-07-18T22:11:00.000+04:00

Привет!

Я возобновил блог по новому адресу: thewonderbird.com
Лента: http://thewonderbird.com/wp/feed/

Присоединяйтесь!

Не работает автодополнение в 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 совершенно устарел. Нет причин использовать его в коде.

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 проигнорирован.

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

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

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 для последующего её применения.

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-ы не очень хороши и рекомендуется их избегать. Читать.

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), имеет смысл имплементировать этот интерфейс. Небольшие усилия, затраченные на создание функции сравнения, открывают для класса всю мощь стандартных алгоритмов и коллекций, требующих существование этого порядка. Обычно этот интерфейс имплементируют классы, представляющие какое-либо значение: число, дату и время и т.д.

Effective Java: Создание и уничтожение объектов

2010-09-29T01:48:00.002+04:00

Дочитал книгу Effective Java 2nd ed. и решил выделить основные идеи каждого из её параграфов. Прочтение этого никак не может заменить прочтения самой книги, но может послужить, например, для повторения материала.
Итак, первая после введения глава, Создание и уничтожение объектов (Creating and Destroying Objects).

Item 1. Как насчёт использования статических фабричных методов (static factory methods) вместо конструкторов?

Фабричные методы имеют следующие преимущества перед конструкторами:

Им можно подбирать "говорящие" названия. Сравните: new BigInteger(int, int, Random) и BigInteger.probablePrime(int, Random) (этот конструктор и фабричный метод делают, по сути, одно и то же).
Фабричный метод не обязательно должен создавать новый объект, а может, например, получать его из кэша. Например, Integer.valueOf(int).
Фабричный метод может вернуть экземлпяр подкласса возвращаемого типа. Например, EnumSet.of(...).
Использование фабричных методов позволяет избежать повторения параметров при создании объектов параметризированных типов:
Map<String, List<String>> m = HashMap.newInstance();
(на самом деле такого фабричного метода нет в HashMap)
против
Map<String, List<String>> m = new HashMap<String, List<String>>();.

Конечно, есть и обратная сторона медали:

Если класс не предоставляет ни одного public или protected конструктора, то от него нельзя будет отнаследоваться.
В javadoc-документации фабричные методы не отличимы от других статических методов, в отличие от конструкторов, которые выделены в отдельную таблицу.

Item 2. Примите во внимание использование шаблона Builder вместо конструктора с большим числом параметров.

Если класс предоставляет конструкторы с большим числом параметров, в том числе телескопические (telescoping constructor), клиентский код этого класса будет трудно писать и ещё труднее читать. Паттерн JavaBeans (с конструктором без параметров, но с гетерами и сетерами) "многословен", лишает возможности создания неизменяемых объектов (immutable objects) и оставляет возможность использования не инициализированных до конца объектов. Шаблон Builder лишён вышеперечисленных недостатков, хотя имеет и парочку своих.

Item 3. При создании классов-одиночек (singleton) используйте приватные конструкторы и перечисления (enum).

Название говорит само за себя. Приватный конструктор можно вызвать, используя reflection, и он не подходит для сериализуемых синглтонов (об этом в последней главе книги), поэтому самый надёжный способ организовать синглтон в Java - использовать для этого Enum с единственным элементом.

Item 4. Запрещайте создание экземпляров класса с помощью приватного конструктора.

Бесполезно делать инструментарные классы (которые содержат только статические методы) абстрактными - от них можно будет отнаследоваться (а делать класс abstract и final одновременно запрещено). Лучше для таких классов писать приватный конструктор.

Item 5. Избегайте создания лишних объектов.

Основные идеи: неизменяемые объекты (immutable objects) можно использовать многократно, не создавая новые экземпляры; необходимо следить за автобоксингом (autoboxing), использовать, где возможно, примитивы.

Item 6. Избавляйтесь от устаревших объектов.

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

Item 7. Избегайте использование финализаторов.

Правильно писать методы-финализаторы сложно и чаще всего не нужно. Они опасны и непредсказуемы. Единственная здравая причина написать финализатор - необходимость предупреждать автора клиентского кода о том, что ваш объект не был завершён (terminated) должным образом.

Элементарный графический движок на Java

2010-09-17T02:35:00.001+04:00

Disclaimer. Данный "движок" написан исключительно for fun и вряд ли сможет найти реальное применение.

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

Решение. Для решения задачи был использован т.н. метод Ray casting. Грубо говоря, программа "стреляет" лучами через "окно" и определяет, с каким из треугольников луч пересечётся ближе к наблюдателю.

Обозначения
O - точка, в которой находится наблюдатель
G, H, I - три угла "окна". Со стороны наблюдателя: G - верхний-левый, H - нижний-левый, I - нижний-правый.

Самое интересное здесь - геометрия. Объясню вкратце, что да как.

Во-первых, построение луча. Конец луча - всегда точка O. Вторая точка P, через которую проходит луч, лежит в "окне" и выбирается следующим образом:
P = G + HI * w/resW + GH * h/resH,
где HI - вектор из H в I, GH - вектор из G в H,
w и h - координаты простреливаемой точки в окне,
resW и resH - количество точек(разрешение) по горизонтали и вертикали.

Далее для каждого треугольника ищем точку пересечения с ним луча и среди всех пересечений выбираем ближайшее.
Для начала находим точку пересечения луча и плоскости, в которой лежит треугольник. Уравнение плоскости находим так, а точку пересечения - так. Далее, если точка пересечения существует, необходимо определить, лежит ли она внутри треугольника. Для этого был использован следующий факт: точка Q лежит внутри треугольника ABC тогда и только тогда, когда площадь треугольника ABC равна сумме площадей треугольников ABQ, ACQ и BCQ. Площадь треугольника подсчитывается по векторному произведению двух его сторон. Возвращаясь к точке пересечения с плоскостью: там в результате получилось значение мю, которое представляет собой параметр при параметрическом задании луча. То есть чем больше мю, тем дальше точка пересечения находится от наблюдателя. Поэтому это значение мю очень удобно использовать для поиска ближайшего пересекаемого треугольника: достаточно среди всех мю выбрать наименьшее неотрицательное(отрицательное мю означает, что треугольник находился позади наблюдателя).

После нахождения ближайшего пересекаемого треугольника рисуем пиксель цвета этого треугольника в точке (w, h).

Спецификация входного файла
Координаты точек представляют собой вещественные или целые числа, записанные через пробел или табуляцию. Координат три и записываются в привычном порядке: x, y, z. Цвет записывается в виде трёх целых чисел из множества [0, 255] - это R, G и B соответственно.

Входной файл называется input и должен быть расположен в текущей директории.

Входной файл должен содержать в указанном порядке:
Координаты точки O;
координаты точек G, H, I;
разрешение картинки по горизонтали и вертикали resW и resH(целые, положительные);
количество треугольников - целое, неотрицательное;
затем для каждого треугольника: координаты трёх вершин и цвет.

Переводы строк допустимы между любыми числами.

Примеры
Привожу скриншоты и ссылки на исходники файла input в двух экземлярах.
1. Пирамида

http://pastebin.com/Pr8ehGUs
http://paste.org.ru/?0tcyqw

2. Пересечение двух треугольников

http://pastebin.com/wUVWLvwN
http://paste.org.ru/?k4nyz8

3. Перспектива
Смежные плоскости образуют прямой угол.

http://pastebin.com/y95Trgdf
http://paste.org.ru/?c0y6ds

4. Рандом
100 произвольных треугольников в кубе 200x200x200. Картинка рендерится заметно дольше остальных.

http://pastebin.com/TtbwWE5U
http://paste.org.ru/?t0i3rc

5. Поворот
Если вместо угла H указать противоположный, то картинка повернётся.

http://pastebin.com/QKQHut45
http://paste.org.ru/?jqgdl9

А при первом запуске я получил такую картину:

Дело в том, что в программе используется не очевидное сравнение вещественных чисел с нулём a == 0, а более правильное Math.abs(a) < EPS, где EPS - маленькое число. Так вот, оказалось, что константа EPS у меня была настолько маленькой, а float настолько невместительным, что сумма площадей треугольников(см. выше) не сходилась. Поэтому не все пересечения посчитались правильно и оказались видны задние стенки пирамиды.
Кстати, то же самое касается сравнения на равенство двух вещественных чисел - это общий случай: вместо a == b следует делать Math.abs(a-b) < EPS.

Исходный код
Расположение файлов в папках несложно определить из имени пакета.

GeometryHelper.java

package com.blogspot.codingbreak.simple3d.geometry;

public class GeometryHelper {

    /**
     * 
     * @return value m >= 0 so that p = ray.p1 + m * (ray.p2 - ray.p1) is the
     *         intersection point. Null if there is no interection points.
     */
    public static Float intersectRayAndTriangle(final Ray ray,
            final Triangle triangle) {
        // calculating the triangle's plane equation:
        final float a = triangle.getA().getY()
                * (triangle.getB().getZ() - triangle.getC().getZ())
                + triangle.getB().getY()
                * (triangle.getC().getZ() - triangle.getA().getZ())
                + triangle.getC().getY()
                * (triangle.getA().getZ() - triangle.getB().getZ());
        final float b = triangle.getA().getZ()
                * (triangle.getB().getX() - triangle.getC().getX())
                + triangle.getB().getZ()
                * (triangle.getC().getX() - triangle.getA().getX())
                + triangle.getC().getZ()
                * (triangle.getA().getX() - triangle.getB().getX());
        final float c = triangle.getA().getX()
                * (triangle.getB().getY() - triangle.getC().getY())
                + triangle.getB().getX()
                * (triangle.getC().getY() - triangle.getA().getY())
                + triangle.getC().getX()
                * (triangle.getA().getY() - triangle.getB().getY());
        final float d = -triangle.getA().getX()
                * (triangle.getB().getY() * triangle.getC().getZ() - triangle
                        .getC().getY()
                        * triangle.getB().getZ())
                - triangle.getB().getX()
                * (triangle.getC().getY() * triangle.getA().getZ() - triangle
                        .getA().getY()
                        * triangle.getC().getZ())
                - triangle.getC().getX()
                * (triangle.getA().getY() * triangle.getB().getZ() - triangle
                        .getB().getY()
                        * triangle.getA().getZ());
        http://codingbreak.blogspot.com/ 
        {}
        final float numerator = a * ray.getP1().getX() + b * ray.getP1().getY()
                + c * ray.getP1().getZ() + d;
        final float denominator = a * (ray.getP2().getX() - ray.getP1().getX())
                + b * (ray.getP2().getY() - ray.getP1().getY()) + c
                * (ray.getP2().getZ() - ray.getP1().getZ());

        Float mu;
        if (Math.abs(denominator) < 1e-6) {
            // denominator == 0 => ray is parallel to triangle, there is no
            // intersection point
            mu = null;
        } else {
            mu = Float.valueOf(-numerator / denominator);
        }

        if (mu != null) {
            final float px = ray.getP1().getX() + mu
                    * (ray.getP2().getX() - ray.getP1().getX());
            final float py = ray.getP1().getY() + mu
                    * (ray.getP2().getY() - ray.getP1().getY());
            final float pz = ray.getP1().getZ() + mu
                    * (ray.getP2().getZ() - ray.getP1().getZ());
            final Point p = new Point(px, py, pz);
            if (!isPointLiesInsideTriangle(p, triangle)) {
                mu = null;
            }
        }
        return mu;
    }

    static boolean isPointLiesInsideTriangle(final Point p,
            final Triangle triangle) {
        float s0 = areaOfTriangle(triangle.getA(), triangle.getB(), triangle
                .getC());
        float s1 = areaOfTriangle(triangle.getA(), triangle.getB(), p);
        float s2 = areaOfTriangle(triangle.getA(), triangle.getC(), p);
        float s3 = areaOfTriangle(triangle.getC(), triangle.getB(), p);
        return Math.abs(s0 - s1 - s2 - s3) < 1f;
    }

    static float areaOfTriangle(Point a, Point b, Point c) {
        float px = b.getX() - a.getX();
        float py = b.getY() - a.getY();
        float pz = b.getZ() - a.getZ();

        float qx = c.getX() - a.getX();
        float qy = c.getY() - a.getY();
        float qz = c.getZ() - a.getZ();

        float x = py * qz - pz * qy;
        float y = pz * qx - px * qz;
        float z = px * qy - py * qx;

        float s = (float) (.5 * Math.sqrt(x * x + y * y + z * z));
        return Math.abs(s);
    }
}

Point.java

package com.blogspot.codingbreak.simple3d.geometry;

public class Point {
    private final float x;
    private final float y;
    private final float z;

    public Point(float x, float y, float z) {
        this.x = x;
        this.y = y;
        this.z = z;
    }

    public float getX() {
        return x;
    }

    public float getY() {
        return y;
    }

    public float getZ() {
        return z;
    }
}

Ray.java

package com.blogspot.codingbreak.simple3d.geometry;

public class Ray {
    private final Point p1;
    private final Point p2;

    public Ray(Point p1, Point p2) {
        this.p1 = p1;
        this.p2 = p2;
    }

    public Point getP1() {
        return p1;
    }

    public Point getP2() {
        return p2;
    }
}

Triangle.java

package com.blogspot.codingbreak.simple3d.geometry;

import java.awt.Color;

public class Triangle {
    private final Point a;
    private final Point b;
    private final Point c;
    private final Color color;

    public Triangle(Point a, Point b, Point c, Color color) {
        this.a = a;
        this.b = b;
        this.c = c;
        this.color = color;
    }

    public Point getA() {
        return a;
    }

    public Point getB() {
        return b;
    }

    public Point getC() {
        return c;
    }

    public Color getColor() {
        return color;
    }
}

DemoFrame.java

package com.blogspot.codingbreak.simple3d;

import java.awt.Color;
import java.io.File;
import java.io.FileNotFoundException;
import java.util.HashSet;
import java.util.Scanner;
import java.util.Set;

import javax.swing.JFrame;

import com.blogspot.codingbreak.simple3d.geometry.Point;
import com.blogspot.codingbreak.simple3d.geometry.Triangle;

class DemoFrame extends JFrame {

    public static void main(String[] args) {
        new DemoFrame().setVisible(true);
    }

    public DemoFrame() {
        super("Simple3D demo frame");
        setDefaultCloseOperation(DISPOSE_ON_CLOSE);

        Simple3DDrawingPanel drawing = null;
        try {
            drawing = loadFromFile(new File("input"));
            getContentPane().add(drawing);
            this.pack();
        } catch (FileNotFoundException e) {
            e.printStackTrace();
        }
    }

    /**
     * Loads all the space information(objects, camera coordinates, etc) from file and
     * constructs Simple3DDrawingPanel object.
     * 
     * @param file
     * @return Simple3DDrawingPanel object
     * @throws FileNotFoundException
     */
    private static Simple3DDrawingPanel loadFromFile(final File file)
            throws FileNotFoundException {
        final Scanner in = new Scanner(file);
        
        final Point o = readPoint(in);
        final Point g = readPoint(in);
        final Point h = readPoint(in);
        final Point i = readPoint(in);
        final int resolutionW = in.nextInt();
        final int resolutionH = in.nextInt();

        final int n = in.nextInt(); // the number of triangles
        final Set<Triangle> triangles = new HashSet<Triangle>(n);
        for (int j = 0; j < n; ++j) {
            final Point a = readPoint(in);
            final Point b = readPoint(in);
            final Point c = readPoint(in);
            final Color color = readColor(in);
            
            final Triangle triangle = new Triangle(a, b, c, color);
            triangles.add(triangle);
        }

        in.close();
        final Simple3DDrawingPanel drawingPanel = new Simple3DDrawingPanel(o,
                g, h, i, resolutionW, resolutionH, triangles);
        return drawingPanel;
    }

    private static Point readPoint(final Scanner in) {
        final float x = in.nextFloat();
        final float y = in.nextFloat();
        final float z = in.nextFloat();
        return new Point(x, y, z);
    }

    private static Color readColor(final Scanner in) {
        final int colorR = in.nextInt();
        final int colorG = in.nextInt();
        final int colorB = in.nextInt();
        return new Color(colorR, colorG, colorB);
    }

}

RandomGenerator.java

package com.blogspot.codingbreak.simple3d;

import java.io.File;
import java.io.FileNotFoundException;
import java.io.PrintWriter;
import java.util.Random;

public class RandomGenerator {

    private static float bound = 200f;
    private static float deltaX = 1000f;

    public static void main(String[] args) throws FileNotFoundException {
        PrintWriter out = new PrintWriter(new File("random"));

        out
                .print("0 0 0\n\n500 -320 240\n500 -320 -240\n500 320 -240\n\n640 480\n\n");

        int n = 100;
        out.print(n);
        out.print("\n\n");

        Random generator = new Random();
        for (int i = 0; i < n; ++i) {
            for (int j = 0; j < 3; ++j) {
                float x = (generator.nextFloat()-.5f) * bound+deltaX;
                float y = (generator.nextFloat()-.5f) * bound;
                float z = (generator.nextFloat()-.5f) * bound;

                out.printf("%f %f %f\n", x, y, z);
            }
            int r = generator.nextInt(256);
            int g = generator.nextInt(256);
            int b = generator.nextInt(256);
            out.printf("%d %d %d\n\n", r, g, b);
        }

        out.close();
    }

}

Simple3DDrawingPanel.java

package com.blogspot.codingbreak.simple3d;

import java.awt.Color;
import java.awt.Dimension;
import java.awt.Graphics;
import java.util.Set;

import javax.swing.JPanel;

import com.blogspot.codingbreak.simple3d.geometry.GeometryHelper;
import com.blogspot.codingbreak.simple3d.geometry.Point;
import com.blogspot.codingbreak.simple3d.geometry.Ray;
import com.blogspot.codingbreak.simple3d.geometry.Triangle;

public class Simple3DDrawingPanel extends JPanel {

    private static Color BACKGROUND_COLOR = Color.BLACK;

    private Point O;
    private Point G;
    private Point H;
    private Point I;
    private Set<Triangle> triangles;
    private int resolutionW;
    private int resolutionH;

    public Simple3DDrawingPanel(final Point o, final Point g, final Point h,
            final Point i, final int resolutionW, final int resolutionH,
            final Set<Triangle> triangles) {
        this.G = g;
        this.H = h;
        this.I = i;
        this.resolutionW = resolutionW;
        this.resolutionH = resolutionH;
        this.triangles = triangles;
        this.O = o;
        setPreferredSize(new Dimension(resolutionW, resolutionH));
    }

    private Point getPointByCoordinates(final int w, final int h) {
        final float x = G.getX() + (I.getX() - H.getX()) * w / resolutionW
                + (H.getX() - G.getX()) * h / resolutionH;
        final float y = G.getY() + (I.getY() - H.getY()) * w / resolutionW
                + (H.getY() - G.getY()) * h / resolutionH;
        final float z = G.getZ() + (I.getZ() - H.getZ()) * w / resolutionW
                + (H.getZ() - G.getZ()) * h / resolutionH;
        return new Point(x, y, z);
    }

    @Override
    public void paintComponent(Graphics g) {
        super.paintComponent(g);
        g.setColor(Color.BLACK);
        for (int w = 0; w < resolutionW; w++) {
            for (int h = 0; h < resolutionH; ++h) {
                final Point point = getPointByCoordinates(w, h);
                final Ray ray = new Ray(O, point);

                Float mu = null;
                Color color = null;
                for (final Triangle triangle : triangles) {
                    final Float muCurrent = GeometryHelper
                            .intersectRayAndTriangle(ray, triangle);
                    if (muCurrent != null && (mu == null || mu > muCurrent)) {
                        mu = muCurrent;
                        color = triangle.getColor();
                    }
                }
                if (mu == null) {
                    color = BACKGROUND_COLOR;
                }

                g.setColor(color);
                g.drawRect(w, h, 1, 1);
            }
        }
    }

}