Комментарии 25
По поводу черной магии и пункта 5 — это же самое можно делать кастомным класслоадером, так что было бы интересно узнать про применение именно Unsafe.
И, простите, безотносительно
>>без вывоза конструктора
улыбнуло :)
И, простите, безотносительно
>>без вывоза конструктора
улыбнуло :)
> Ключевое слово this позволяет получить доступ к полям и методам из внутненнего (inner) класса.
Только в случае не-статического inner класса.
> Для float i = Float.NaN – выражение i == i равно false
Сказали бы почему это так и что с этим делать. Это требование IEEE 754. Проверить double на NaN можно при помощи Double.isNan().
Только в случае не-статического inner класса.
> Для float i = Float.NaN – выражение i == i равно false
Сказали бы почему это так и что с этим делать. Это требование IEEE 754. Проверить double на NaN можно при помощи Double.isNan().
javap всё же дизассемблер, а не декомпилятор.
Я думаю, что вряд ли буду использовать бОльшую часть описанного, но вот про конкатенацию строк действительно полезно :)
НЛО прилетело и опубликовало эту надпись здесь
я так понимаю с помощью sun.misc.Unsafe прикручивают к джаве указатели? :)
sun.misc.Unsafe это частный класс частной проприетарной либы одной частной конторки. Ни к JLS, ни к JVMS пакеты sun.* и com.sun.* отношения не имеют и уж тем более их тупо ет ни в одной другой реализации JVM (коих довольно-таки и у каждой свой смысл).
*нет
А что же они тогда делают в rt.jar в JRE от Sun?
НЛО прилетело и опубликовало эту надпись здесь
Ключевые слова — «в системном коде». Черт, да с тем же успехом там может быть код, выделяющий память и возвращающий указатели на нее, да хоть полная реализация сишной модели работы с памятью; все равно это будут детали имплементации одной конкретной JVM (и то, что большинство JVM в той или иной степени стырены с сановской реализации, не умаляет этого факта).
Иными словами: используя эти классы и рассчитывая на их наличие в составе JVM вы пишете не на Java под ява-машину, а на каком-то своем выдуманном, очень похожем на яву языке, под совершенно левый интерпретатор этого языка, и никакой гарантии, что ваш код запустится у пользователя, у вас нет (если вы только не поставляете JVM в комплекте со своим коммерческим продуктом; и, конечно, уже договорились с Sun на эту тему). На какой-нибудь WebSphere, которая запускается на IBM-овской JVM, ваше решение просто не взлетит, да и (забавно кстати, в ru_java мы сейчас это же самое обсуждаем) сама необходимость применить подобные решения — с хорошей вероятностью показатель ошибки в архитектуре приложения.
Иными словами: используя эти классы и рассчитывая на их наличие в составе JVM вы пишете не на Java под ява-машину, а на каком-то своем выдуманном, очень похожем на яву языке, под совершенно левый интерпретатор этого языка, и никакой гарантии, что ваш код запустится у пользователя, у вас нет (если вы только не поставляете JVM в комплекте со своим коммерческим продуктом; и, конечно, уже договорились с Sun на эту тему). На какой-нибудь WebSphere, которая запускается на IBM-овской JVM, ваше решение просто не взлетит, да и (забавно кстати, в ru_java мы сейчас это же самое обсуждаем) сама необходимость применить подобные решения — с хорошей вероятностью показатель ошибки в архитектуре приложения.
НЛО прилетело и опубликовало эту надпись здесь
А, понял.
А можно примеры «системного кода», кстати?
А можно примеры «системного кода», кстати?
НЛО прилетело и опубликовало эту надпись здесь
Окей, теперь я вконец запутан. Все вышеперечисленное — опять детали реализации JVM, которые пользователю (т.е. не человеку, разрабатывающему собственную JVM) не видны. Ладно, это понятно. Зато теперь я опять не понимаю, кто у кого «вынужден идти на поводу». Тот факт, что это удобный инструмент для реализации механизмов JVM — это понятно, но это факт отнюдь не из Java, скорее уж, из жизни сишников. То, что многие компании, пишушие собственные JVMы, решают не изобретать велосипедов, а переиспользуют имеющиеся Unsafe биндинги в натив — это тоже понятно; но ведь ни Sun после этого не вынужден поддерживать для них актуальную версию Unsafe, ни для них это не является вынужденным решением, а всего лишь способом срезать путь (и код они в дальнейшем поддерживают уже самостоятельно, ну либо перетыривают более свежие версии), ни уж тем более конечный пользователь ничего об этом не знает. Т.е. опять же, это не ява, так же, как не ява тот компилятор, что используется, чтобы собрать бинарники JVM.
Про серриализацию, есть более интересная статья на русском www.skipy.ru/technics/serialization.html
Там кстати много статей по базовым вещам с неплохой детализацией.
Там кстати много статей по базовым вещам с неплохой детализацией.
Клева было бы назвать фишку со списком аргументов произвольной длинны вслух по имени: Varargs.
С пятой версии Java конкатенация строк компилятором приводится к цепочке на базе StringBuilder, а не StringBuffer. Исправьте или сделайте объяснение.
Ну и да, ваша магия под номером 5 — это просто ха. Я тогда целыми днями занимаюсь черной магией.
С пятой версии Java конкатенация строк компилятором приводится к цепочке на базе StringBuilder, а не StringBuffer. Исправьте или сделайте объяснение.
Ну и да, ваша магия под номером 5 — это просто ха. Я тогда целыми днями занимаюсь черной магией.
С применениме «Полузакрытых конструкторов», как вы их называете, следует быть осторожным.
Часто метод equals пишется так, что
new User(1) {} != new User(1),
поскольку это разные классы. Соответственно, в тестах можно нарваться на поведение, отличное от обычного.
В общем, я за другие способы, хотя и про этот знать тоже неплохо.
Часто метод equals пишется так, что
new User(1) {} != new User(1),
поскольку это разные классы. Соответственно, в тестах можно нарваться на поведение, отличное от обычного.
В общем, я за другие способы, хотя и про этот знать тоже неплохо.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Другие возможности Java