Битовые сдвиги и приведения в Java: подводные камни

1. Операции сдвига

Сначала вкратце самые основы. Как известно, в Java все примитивные типы знаковые, и есть несколько вариантов побитовых операций сдвига:

• >> сдвиг вправо
• << сдвиг влево
• >>> сдвиг вправо («беззнаковый»)

Как видно, в дополнение к классическим сдвигам есть также «беззнаковый» сдвиг, который игнорирует знаковый левый бит и сдвигает его как обычный. Также эти сдвиги называются, соответственно, логический (когда первый бит теряется а последний заполняется нулём) и арифметический (аналогично, но значение считается значением в дополнительном коде и последний бит (знаковый) сохраняет своё значение).

java: Почему Thread.stop, Thread.suspend, Thread.resume и Runtime.runFinalizersOnExit объявлены deprecated?

Это я на скорую руку по надобности переводил доку оракловскую. Часть этих док я ещё на тысячах в аспирантуре переводил…
Оригинал (английский): Why Are Thread.stop, Thread.suspend, Thread.resume and Runtime.runFinalizersOnExit Deprecated?
http://docs.oracle.com/javase/1.5.0/docs/guide/misc/threadPrimitiveDeprecation.html

Почему не рекомендуется использовать Thread.stop?

Потому что это по своей сути небезопасно. Это приводит к разблокировке всех залоченных мониторов (исключение ThreadDeath пробрасывается вверх по стеку). Если любой из объектов, ранее защищенный мониторами, был в неустойчивом состоянии, таким его теперь могут увидеть другие потоки. Это может привести к неопределённому поведению, как скрытому труднообнаружимому, так и ярковыраженному. В отличие от других unchecked-исключений, ThreadDeath убивает потоки молча, так что пользователь может и не узнать, что его программа, вероятно, повреждена. Повреждение может проявиться в любое время после реальной аварии, через несколько часов или даже дней.

java и чтение unicode BOM

Ошибка древняя, как гавно мамонта, запишу здесь для истории. Проблема в том, что стандартными методами ридеров и стримов (с указанием, разумеется, соответствующих кодировок) в Java осуществлена неполная поддержка юникодовских кодировок, а именно полное игнорирование любых BOM-ов (в начале файлов). То есть если вы сохраните файл в любую юникодную кодировку «плохим» редактором (например, в виндовом блокноте), приложив BOM, то в Java без костылей прочитать не получится никак.

Баг на сане был открыт ещё в 2001 году, на данный момент помечен как «исправляться не будет», с объяснением «иначе некоторый софт может сломаться», т.е. баги тоже должны быть обратно совместимы ;) В каментах к багу много негодований, но обсуждение правильности этого решения пусть останется за рамками этой заметки.

На данный момент (конец jdk6 - начало jdk7) ошибка не исправлена и исправляться не собирается.

В качестве решения предлагается обрабатывать BOM-ы самостоятельно в коде. Готовые классы-обёртки находятся здесь: http://koti.mbnet.fi/akini/java/unicodereader/.

Например, UnicodeReader оттуда работает как замена InputStreamReader в такой конструкции:

new InputStreamReader( new FileInputStream( new File( "config.txt" ) ), "UTF-8" )

и является просто обёрткой над ним, создавая InputStreamReader внутри себя с кодировкой согласно прочитанным BOM из файла, либо указанной в конструкторе (как и в конструкторе InputStreamReader) конкретной дефолтной кодировке.

расчёт dpi монитора и настройка в linux (черновик)

Началось с того, что меня бесило, что gnome ставил 96 dpi мне, хотя, очевидно, настоящий dpi другой. Также запросто может быть (у меня на прошлом мониторе был) совершенно разное значение DPI по горизонтали и вертикали. Потом я перестал пользоваться gnome и начал сталкиваться с такой же настройкой в целом во всей системе. Как и положено в linux это приводило к гемору и тому, что иногда это работало, иногда нет, итп. И руководство давности годовой из инета оказывались неактуальными совершенно, потому что всё уже deprecated и работает по-другому.

[!]з.ы. по сути это черновиком так и осталось, так что пользы мало.

django: предпросмотр картинки (поля ImageField) в админке

Выводить буду предпросмотр в таблице списка элементов модели (у меня это Image — "картинка") и, самое главное, в форме редактирования модели.

linux: fedora 16 64 yum защищённые версии multilib

В бете федоры 16 x86_64 при попытке вытянуть через yum зависимости для i686 пишет что-то типа:

Ошибка: Защищённые версии multilib ....

Решается включением репозитория updates-testing:

yum install пакет.i686 --enablerepo=updates-testing

linux: flac cue ape разрезание на треки

Часто музыкальные альбомы представляют из себя цельный flac. К нему, как правило, прилагается cue-файл с метаданными, который описывает раскладку треков в нём. Иногда это неудобно: нельзя отделить треки, проблема с проигрывателями (мы же в linux, не так ли;) и т.д. Мы хотим разрезать изначальный музыкальный файл на отдельные flac-треки, чтобы было всё красиво, с метаданными, с тегами. На самом деле cue используется с любыми форматами, а не только с flac. Наша изначальная задача разбивается на две: работа с cue и резка flac/ape/… . Кодировать на выходе будем во flac.