спасибо, исправил. А по поводу Unsafe — класс не документирован. Можно попробовать скачать исходники, однако java.net уже как два дня на maintenance. Ну или почитать Unsafe java на wasm.ru: часть 1 и часть 2
sun.misc.Unsafe это частный класс частной проприетарной либы одной частной конторки. Ни к JLS, ни к JVMS пакеты sun.* и com.sun.* отношения не имеют и уж тем более их тупо ет ни в одной другой реализации JVM (коих довольно-таки и у каждой свой смысл).
Ключевые слова — «в системном коде». Черт, да с тем же успехом там может быть код, выделяющий память и возвращающий указатели на нее, да хоть полная реализация сишной модели работы с памятью; все равно это будут детали имплементации одной конкретной JVM (и то, что большинство JVM в той или иной степени стырены с сановской реализации, не умаляет этого факта).
Иными словами: используя эти классы и рассчитывая на их наличие в составе JVM вы пишете не на Java под ява-машину, а на каком-то своем выдуманном, очень похожем на яву языке, под совершенно левый интерпретатор этого языка, и никакой гарантии, что ваш код запустится у пользователя, у вас нет (если вы только не поставляете JVM в комплекте со своим коммерческим продуктом; и, конечно, уже договорились с Sun на эту тему). На какой-нибудь WebSphere, которая запускается на IBM-овской JVM, ваше решение просто не взлетит, да и (забавно кстати, в ru_java мы сейчас это же самое обсуждаем) сама необходимость применить подобные решения — с хорошей вероятностью показатель ошибки в архитектуре приложения.
Окей, теперь я вконец запутан. Все вышеперечисленное — опять детали реализации JVM, которые пользователю (т.е. не человеку, разрабатывающему собственную JVM) не видны. Ладно, это понятно. Зато теперь я опять не понимаю, кто у кого «вынужден идти на поводу». Тот факт, что это удобный инструмент для реализации механизмов JVM — это понятно, но это факт отнюдь не из Java, скорее уж, из жизни сишников. То, что многие компании, пишушие собственные JVMы, решают не изобретать велосипедов, а переиспользуют имеющиеся Unsafe биндинги в натив — это тоже понятно; но ведь ни Sun после этого не вынужден поддерживать для них актуальную версию Unsafe, ни для них это не является вынужденным решением, а всего лишь способом срезать путь (и код они в дальнейшем поддерживают уже самостоятельно, ну либо перетыривают более свежие версии), ни уж тем более конечный пользователь ничего об этом не знает. Т.е. опять же, это не ява, так же, как не ява тот компилятор, что используется, чтобы собрать бинарники JVM.
Про серриализацию, есть более интересная статья на русском www.skipy.ru/technics/serialization.html
Там кстати много статей по базовым вещам с неплохой детализацией.
С применениме «Полузакрытых конструкторов», как вы их называете, следует быть осторожным.
Часто метод equals пишется так, что
new User(1) {} != new User(1),
поскольку это разные классы. Соответственно, в тестах можно нарваться на поведение, отличное от обычного.
В общем, я за другие способы, хотя и про этот знать тоже неплохо.
Другие возможности Java