Как стать автором
Обновить

Комментарии 97

Java — это лакомый кусок злоумышленников т.к. по статистике riastat на текущий момент Java VM установлена более чем на 1 биллионе клиентских машин.

«биллионе»? Вы серьёзно? Ладно бы это был перевод, но авторский текст…
Да ладно бы только это… Текст ужасает количеством банальных грамматических и пунктуационных ошибок, не говоря уже о лексических несогласованностях.
Будьте добры в пм все ошибки. Поправим и сделаем все в лучшем виде.
Статистика не моя. Я привел лишь цифры которые слышал ранее, к сожалению riastats.com/ у меня не корректно открывается и я не могу сказать точных цифр.
Я это просто к тому написал, что если вы хотите донести какую-то информацию до русскоязычных специалистов, то лучше разговаривать с ними на одном языке. Слова «биллион» я не знаю, но могу подсказать похожее по смыслу слово «миллиард».
Слово биллион очень часто встречается в науке и математике. Это слово я еще по школьному курсу математики знаю. ru.wikipedia.org/wiki/%D0%91%D0%B8%D0%BB%D0%BB%D0%B8%D0%BE%D0%BD
Теперь и вы будете знать, что это число 10 в 9й степени.
Слово «биллион» есть, и используется, просто это из длинной записи.
Только не длинной, а короткой. см. выше ссылку в википедии.
«billion» с английского на русский — «миллиард». С этой цифрой нормально все.
Получается уязвимость-то в Firefox (или java плагине), поскольку temp папку можно и угадать.
Это 2 разные уязвимости. Уязвимость в firefox позволяет выполнить с локального диска привилегированный код java. Уязвимость в самом плагине Java для FF. По соображениям безопасности описание уязвимости не буду выкладывать.
Oracle об этом в курсе? Если да, почему нельзя выложить? Если нет, почему им не сообщили?
Все вкурсе. По причине того, что хакеры недоучки начнут с помощью этих методов распространять малварь.
Классический пример того, что называется bad design. Но, с одной стороны, это ж Sun Oracle, «кто его посадит, он же памятник», с другой — официальное отсутствие гарантии повторяемости в следующих версиях;-).

Кстати, в коде самих системных классов языка Java я вообще встречал кучу примеров кода, который на моей предыдущей работе зарубили бы на review ;-)
Это точно подмечено. Код очень замусоренный и не оптимизированный. Единственное меня порадовало, что где-то год назад они в своем коде bad style обработку массивов и коллекций перевели с for на цикл while и извлечение при каждой новой итерации значения и тем самым при каждом цикле уменьшая массив. Что работает быстрее и жрет меньше памяти.
Можно пример
Было:
for (String str: localList)
if (paramString.equals(str))
try {
ScriptEngine localScriptEngine2 = localScriptEngineFactory.getScriptEngine();
localScriptEngine2.setBindings(getBindings(), 200);
return localScriptEngine2;
}
catch (Exception localException3)
{
}

Стало:
Iterator localIterator = localList.iterator();
while (localIterator.hasNext())
{
String str = (String)localIterator.next();
if (paramString.equals(str))
try
{
ScriptEngine localScriptEngine2 = localScriptEngineFactory.getScriptEngine();
localScriptEngine2.setBindings(getBindings(), 200);
return localScriptEngine2;
}
catch (Exception localException3)
{
}
}
Подобных замен кусков кода очень много oracle сделала.
А я всегда думал, что эти записи эквивалентны…
Функционал эквивалентен, но скорость работы и использование памяти разное.
Это примерно, из той же оперы, что использование конкатенации строк в java и StringBuffer(StringBuilder).
Второе работает быстрее и использует меньше памяти. В этом легко убедится на простом примере:
public class Main
{
public static void main(String[] args)
{
long now = System.currentTimeMillis();
slow();
System.out.println(«slow elapsed » + (System.currentTimeMillis() — now) + " ms");

now = System.currentTimeMillis();
fast();
System.out.println(«fast elapsed » + (System.currentTimeMillis() — now) + " ms");
}

private static void fast()
{
StringBuilder s = new StringBuilder();
for(int i=0;i<100000;i++)
s.append("*");
}

private static void slow()
{
String s = "";
for(int i=0;i<100000;i++)
s+="*";
}
}
А вот это, извините, совсем не из той оперы…
Я не исследовал сам, но если верить приведенному дизассемблированному коду по этой ссылке (одна из первых в Гугле):

stackoverflow.com/questions/2113216/which-is-more-efficient-a-for-each-loop-or-an-iterator

то for-each loop в Java пользуется итератором, то есть абсолютно эквивалентен ручному использованю итератора.

И даже простая логика то-же самое подсказывает — он просто не может по другому работать.

List<Integer>  a = new ArrayList<Integer>();
for (Integer integer : a)
{
  integer.toString();
}
// Byte code
 ALOAD 1
 INVOKEINTERFACE java/util/List.iterator()Ljava/util/Iterator;
 ASTORE 3
 GOTO L2
L3
 ALOAD 3
 INVOKEINTERFACE java/util/Iterator.next()Ljava/lang/Object;
 CHECKCAST java/lang/Integer
 ASTORE 2 
 ALOAD 2
 INVOKEVIRTUAL java/lang/Integer.toString()Ljava/lang/String;
 POP
L2
 ALOAD 3
 INVOKEINTERFACE java/util/Iterator.hasNext()Z
 IFNE L3

Только что проверил на коде:

import java.util.*;

public class test{

public static void main(String args[]){
List<Integer>  a = new ArrayList<Integer>();

for (Integer in : a){
int c = in;
}

Iterator localIterator = a.iterator();
while (localIterator.hasNext()){
int d = (Integer)localIterator.next();
}
}
}

Результат почти идентичен, но второй вариант короче на 2 инструкции.
new java/util/ArrayList
dup
invokespecial java/util/ArrayList/<init>()V
astore_1


aload_1
invokeinterface java/util/List/iterator()Ljava/util/Iterator; 1
astore_2
aload_2
invokeinterface java/util/Iterator/hasNext()Z 1
ifeq 19
aload_2
invokeinterface java/util/Iterator/next()Ljava/lang/Object; 1
checkcast java/lang/Integer
astore_3
aload_3
invokevirtual java/lang/Integer/intValue()I
istore 4
goto 8


aload_1
invokeinterface java/util/List/iterator()Ljava/util/Iterator; 1
astore_2
aload_2
invokeinterface java/util/Iterator/hasNext()Z 1
ifeq 31
aload_2
invokeinterface java/util/Iterator/next()Ljava/lang/Object; 1
checkcast java/lang/Integer
invokevirtual java/lang/Integer/intValue()I
istore_3
goto 22

return
Ну ладно, это уже не серьезно :-) такая разница даже упоминания не стоит — это зависит от кодогенератора и от JIT-компилятора, и может случайно поменяться даже при минорном апдейте виртуальной машины
Вполне может. Но факт остается фактом, и оракл много где подобный код заменила.
Я думаю, они старый for(int i = 0; i < x; ++i) поменяли, а не for-each… такая замена имеет смысл…
На самом деле, оракл довольно много сделала замен кода, подобный куски кода мне просто чаще попадаются на глаза. Возможно это они сделали в самом оптимизаторе, я просто анализировал декомпилированный код из байкоткода.
Oracle ничего не меняла, просто ваш декомпилятор перестал понимать foreach-лупы. Убирание пары инструкций astore_3/aload_3 на производительность не влияет.
Все зависит в каком контексте выполняется код. При несколько тысяц экземплеров класса и одновременном выполнении одного и тоже метода эти 2 инструкции могут сказаться в производительности и в расходе памяти. Как видим astore записывает значение из стека в переменную, а потом aload берет значение из этой переменной и ложит в стек. Декомпилятор тот же, просто на разных версиях библиотек результат разный. Да и я пример байткода привел, что он разный. А кто тогда менял? Нло прилетело и оптимизировало?
Компиляторы разные. Возможно более новый компилятор генерит код получше.
Процентов 5 разница в производительности в худшем случае, хоть на сколько тысяч можно умножать. Всё равно от третьей переменной не избавились, так что по части памяти разницы нет.
Конечно он будет короче.
Идентичный код должен выглядеть так:

while (localIterator.hasNext()){
    Integer in = (Integer)localIterator.next();
    int d = in;
}
Тут не говорится как будет выглядеть идентичный код. Тут даются вырезки реального кода. И второй вариант как факт на 2 инструкции короче.
Какие-то проблемы с логикой в вашем ответе.

Посмотрите ваш пример внимательно.

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

Вы же на основании примера без локальной переменной делаете вывод, что while эффективней for.
И как при этом массив уменьшается? Понимаю, что ListIterator вместо List.get(int), наверное, делает прямое обращение к массиву, и это немного ускоряет работу…
Возможно ошибаюсь, но вроде Iterator при каждом вызове next() берет значение с вершины списка и удаляет его.
Изначально просто не правильно выразился.
Удаляет метод remove() вызванный после next().
А ещё есть опциональный метод previous()...;-)
Поискал по исходному коду JDK 1.7.0_07, такого кода там нет. Можно полное имя класса?
На самом деле запуск Java Applet для меня кажется уже чем-то архаичным.
Я к тому, что браузер всегда должен спрашивать хочу ли я запустить апплет с такого-то сайта и такими-то привилегиями. Java client стоит у большего числа людей, следовательно все преимущества Java + AWT и rich client можно использовать.
НЛО прилетело и опубликовало эту надпись здесь
У Java огромная стандартная библиотека, и во многих местах написана она не очень хорошо. По сути безопасность предполагает, что все десятки мегабайтов байткода не содержат ни одной уязвимости. К сожалению очень часто это предположение оказывается неверным, уязвимости находят.

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

Я лично хоть и люблю джаву и деньги зарабатываю написанием кода на ней, любому порекомендую отключить её в браузере, если нет очень веских причин её использовать. Безопасность песочницы в джаве продумана плохо.
Я отключаю любые плагины. В Chrome можно настроить запуск плагина только после клика — очень удобно. Не только в Java, баги могут быть везде.
А никто не пробовал требовать всегда писать в таких топиках не «Уязвимость jvm», а «Уязвимость java-плагина к браузеру»? Дело в том, что меня уже замучили спрашивать «видел новую уязвимость? У вас же сервера на Java, как у вас с этим?» А у меня же сервера! Там ни браузера, ни иксов, ни даже песочницы — весь код доверенный. И даже если его кто-то взломает, пусть он хоть что от того выделенного пользователя в системе делает. Вот локальное повышение привилегий в Linux — это было бы для меня страшно. А эти уязвимости… Ну то же самое, как если бы в BeOS уязвимость нашли.

Извините, просто наболело.
Уязвимость серьёзная. Она позволяет выполнять произвольный код просто зайдя на заражённый сайт из браузера, в котором включен Java-плагин. Например произвольный код может просканировать все ваши пользовательские файлы и отослать некоторые злоумышленнику, или внедрить в браузер код, который будет логгировать весь HTTP траффик, включая ваши пароли, передаваемые через HTTPS-соединения.

Лично для меня это куда более страшно, чем если вирус может повысить привилегии до рута. У меня под рутом ничего ценного нет, всё под пользователем.

К серверам на Java, конечно, уязвимость отношения не имеет. Но технологию в глазах несведущих людей, к сожалению, дискредитирует, есть такое.
Уязвимость показала, что можно узнать значение любой System property. Как это поможет запустить код?
Никак. Эта уязвимость относится к уязвимостям раскрытия информации об удаленной системе. Это лишь пример. Более серьезные уязвимости я не собираюсь выкладывать в публичный доступ, этого только и ждут хакеры, чтобы начать использовать эти методы в своих корыстных целях. Java все таки не у всех оперативно обновляется!
Ну и таки это именно уязвимость JVM. Песочница это стандартный механизм JVM, то, что апплеты используют её не значит, что это уязвимость java-плагина. Песочница может использоваться и в других целях, например обучающий сайт с автоматической проверкой задач, который запускает переданный код в песочнице. Уязвимость может позволить взломать такой сайт.
Это не уязвимости самого браузера, это уязвимости самой java. К примеру у вас есть серверное бизнес приложение, вы его запускается в песочнице давая ему минимальные привилегии с помощью policy файлов, вы сериализуете объекты и передаете их на сторону клиента. Клиент может специальным образом сериализовать зловредный объект и передать обратно вам. Используя уязвимость в вашем приложении получить доступ к нему, но он будет работать с минимальными права, тут-то и пригодится уязвимость с повышением привилегий в JAVA. А дальше ничего не составит уже получить доступ к системе.
Ну да, конечно, что же такое опасное клиент засунет в json? А передавать сериализованные java объекты по сети клиенту для исполнения и исполнять на сервере полученные от клиента… Это как-то совсем страшно неправильно. Даже безо всяких уязвимостей.
А что сериализация это только JSON и XML? В java к примеру почти весь Beans работает на сериализованных объектах JAVA, а как же rmi service?
Java != JEE. У меня сейчас ни одного приложения в продакшене построенном на ванильном J2EE. Сейчас так много JVM-языков и java-фреймворков, большинство из которых лучше подходят конкретным задачам, что ни осталось причин использовать монстра J2EE, который подходит под любую задачу в какой-то степени, но ни к одной не подходит идеально.
Кстати разочарую вас но в xml тоже можно байткод зашить.
docs.oracle.com/javase/6/docs/api/java/beans/XMLEncoder.html
В последнем релизе Java VM как раз серьезную уязвимость в безопасности пофиксили в XMLDecoder.
CVE-2012-5086 XMLDecoder sandbox restriction bypass
Меня? У меня переопределение Resolve External Entity для JAXB-парсера уже в мозжечке, наверное, сидит. Я вообще-то про JSON писал…
Вы это серьезно? В Java нельзя сериализовать методы.
А разве кто-то писал, что можно сериализовать методы? можно сериализовать объекты. ru.wikipedia.org/wiki/RMI
Да, voronaam писал:
А передавать сериализованные java объекты по сети клиенту для исполнения и исполнять на сервере полученные от клиента…

Исполнить можно только то, что УЖЕ есть на сервере. Ничего другого передать от клиента на сервер и исполнить нельзя.
См ответ ниже…
Любые капризы за ваши деньги :) Во-первых, никто не запрещает передавать сериализованный байт код и подгружать его в рантайме. Если использовать динамический язык типа Groovy, так это ещё и тривиально делается. Во-вторых, даже в обычном J2EE приложении я легко представляю себе как можно разрешить одному приложению (админке) подменять JSP страницы в рантайме. Для ясности: никогда так не делал, но легко себе это представляю. Собственно точно были менеджеры с такими предложениями.
Как я уже писал, никто не мешает удалять все данные при получении строки FATALITY, но при чем тут Java? :-)
Что такое FATALITY и причем тут сериализованные данные? И как ее будет получать серверное приложение?
Вы выше писали «уязвимости самой java» и voronaam написал «А передавать сериализованные java объекты по сети клиенту для исполнения и исполнять на сервере полученные от клиента» — вот я и написал, что это не Java, это проблемы программиста.

voronaam описывает способы выстрелить себе в ногу. Я пишу, что можно точно так же удалять все данные при получении от клиента какой-то строки, это функционально ничем не отличается. Но Java тут ни при чем.
Да это проблема самого программиста. Но эти методы очень часто используются в больших проектах, где ради производительности и масштабируемости проекта приходиться делать такие вещи. Это хорошо когда у вас 1 сервер приложения и приложение простое и вы можете обойтись без это. Да и фреймворки внутри себя тоже очень любят бинарную сериализацию. Как не крути но быстрый экспорт данных позволяет сделать только бинарная сериализация. Даже в XML можно зашить байткод, как писал уже выше docs.oracle.com/javase/6/docs/api/java/beans/XMLEncoder.html
В последнем релизе Java VM как раз серьезную уязвимость в безопасности пофиксили в XMLDecoder.
CVE-2012-5086 XMLDecoder sandbox restriction bypass. Каким бы крутым программистом не был человек, все равно всех моментов он учесть не сможет.
А, теперь понятней. Но опять же, это про песочницу, насколько я понял из скудной информации по CVE-2012-5086. То есть выполнить свой код на сервере все равно не получится — или получится?

Информации в публичном доступе действительно мало, в чем ошибка, что именно исправили — не ясно.
Получится, так как класс как раз отвечает за сериализацию в xml бинарных объектов. При этом мы можем создать свои XML с объектами который отключит секурити менеджер и сможем выполнить на стороне сервера свой код. Только не надо путать XMLDecoder с SaxParser который служит для обработки XML данных. XMLDecoder используется для представления java объектов и использует SaxParser для парсинга XML. Уязвимость затронула java.beans.XMLDecoder, com.sun.beans.decoder.DocumentHandler, com.sun.beans.decoder.PropertyElementHandler. Только, чтобы провернуть надо очень хорошо понимать архитектуру приложения. Слепой поиск очень сложен. К примеру отключение песочницы может быть использовано, когда есть крупный проект, сервер приложения, и много разработчиков и к примеру есть разработчик «Вася». Права каждого разработчика ограничены c помощью policy файлов и Вася может только обращаться к методам определенных классов внутри проекта, а какие-то классы ему запрещены для использования. Но наш Вася хитрый хакер ему чужды новые знания и он хочет узнать архитектуру лучше, он может написать зловредный код и задеплоить приложение. Код отключит песочницу и Вася сможет, собрать статистику какие классы есть в приложении, с помощью рефлекшена собрать данные о методах и полях класса. И даже сериализовать объекты или задампить байткод с помощью Unsafe методов.
Ух ты, интересно. Надеюсь, напишете статью с деталями про это?

Единственное, что я смог найти, вот это hg.openjdk.java.net/jdk7u/jdk7u-dev/jdk/rev/dfffff29f870
Но, похоже, это не то
Уязвимость не позволяет повысить привилегии в java. Повысить привилегии в java позволяет уязвимость в java-плагине.
В случае с этой уязвимостью то да. А в случае с другими уязвимостями, повышение привилегий не только в браузере клиента можно использовать.
А еще можно, при получении команды FATALITY от клиента, удалять все данные на сервере. И зловредные клиенты смогут посылать зловредные сообщения! Ужас! Ужас! Java полна дыр!

Еще раз — методы нельзя сериализовать. В Java нет переполнения буфера. НИКАК нельзя запустить ваш код на сервере без специальных извращений.
И опять это про апплеты. Ну какой сервер будет играть midi-файлы? И при чем тут сериализация?

Все еще жду от вас примера взлома сервера, «специальным образом сериализуя зловредный объект»
То, что описано в этой статье — это не уязвимость песочницы и не уязвимость jvm, это даже не уязвимость стандартной библиотеки, это уязвимость прослойки между стандартной библиотекой и jvm. Не надо усердно экономить переменные — вот и всё.
Я бы не сказал, что в коде системных библиотек JAVA очень экономят переменные, наоборот там очень много инди стайл кода, где примитивный код в 2-3 строки написан к примеру в 10 строк. И по этой причине многие специалисты ругают JAVA, что код не оптимизирован.
Ну, значит, всё ещё хуже — заморачивают код чтоб больше строк было. Наверно оплачиваются или измеряются построчно…

В этом случае — как раз пример экономии и переиспользования переменной.
Сейчас от таких кусков кода стараются избавляться в oracle, но они до сих пор присутствую в очень сложных библиотеках. Код которых труден для понимания и не каждый Java программист сможет переписать его. Но в старых версиях Java его было очень много.
Мне кажется, что эти специалисты могут ругать Java только за то, что такой код хуже читается, потому что в большинстве случаев JIT compiler сведет и 2-3 строки, и 10 строк к одному и тому же коду.
Такой код получает при декомпиляции, тоесть уже после оптимизатора.
Декомпиляции чего? Байткода?
Конечно байткода.
большинстве случаев JIT compiler сведет и 2-3 строки, и 10 строк к одному и тому же коду

JIT compiler производит оптимизации во время исполнения программы, компилятор из Java в байткод оптимизаций практически не делает.
Более того, вот такой простой код:
public static void main(String[] args) {
  System.err.println("Hello" + args[0]);
}
после декомпиляции байткода превращается в:
public static void main(String args[]) {
  System.err.println((new StringBuilder()).append("Hello").append(args[0]).toString());
}


Так что делать выводы о неоптимизированности на основе декомпилированного байткода как минимум странно
Мало строк конкатенируете. Нужно побольше и посложнее, и половину — через +=.
Кроме байткода классы JAVA содержат отладочную информацию по которой можно восстановить исходный код. Это все понятно, что код оптимизируется и Java не стоит на месте и создала кучу синтаксического сахара. Но этот сахар на подобный код не распространяется:
public class Test{

public static void main(String[] args)
{
long sa = System.currentTimeMillis();
slow();
System.out.println("slow elapsed " + (System.currentTimeMillis() - sa) + " ms");

sa = System.currentTimeMillis();
fast();
System.out.println("fast elapsed " + (System.currentTimeMillis() - sa) + " ms");
}

private static void fast()
{
StringBuilder s = new StringBuilder();
for(int i=0;i<100000;i++)
s.append("*");
}

private static void slow()
{
String s = "";
for(int i=0;i<100000;i++)
s+="*";
}

}

Результат:

slow elapsed 7687 ms
fast elapsed 16 ms
1) Вы никогда не узнаете, какой код исполняется в рантайме, и дело здесь не в синтаксическом сахаре. JIT compiler во время исполнения преобразует код, основываясь на статистике. Т.е. чем дольше работает программа, тем эффективнее работа JIT compiler. Поэтому одна и та же программа, работающая под нагрузкой в 1 запрос/сек и в 1000 запросов/сек фактически выполняет разный код, оптимизированный JIT

2) Ваш пример некорректен, несмотря на впечатляющие цифры. s1 + s2 + s3 будут заменены компилятором на использование StringBuilder. Просто ваш цикл ведет к тому, что в каждом цикле будет выполняться new StringBuilder(s).append("*")

Более того, JIT вообще может вырезать ваш цикл, потому что переменная 's' больше нигде не используется. Для того, чтоб он гарантированно этого не сделал, можно добавить в цикле print(s), но это внесет погрешность.
Увеличте время работы моего примера и ответьте на вопрос почему всемогущий jit не оптимизирует код? Это очень глупо постоянно надеятся на то, что за вас работу выполнит jit компилятор.
Практчиески все уязвимости касаются внутренних API com.sun.*, которые согласно рекомендациям вообще не должны использоваться программами. Тем более странно, если какой-то untrusted код лезет в com.sun.*. Почему бы в таком случае просто не запретить апплетам доступ к внутренним классам? Проблема решается элементарно посредством classloader-а. Ведь безопасность дороже каких-то экзотических случаев, когда напрямую нужен функционал com.sun.*.
Вроде как к такому коду просто так не обратишься, только через reflection. Этот код до сих пор использует очень много библиотек, тоесть уязвимости можно попытаться выполнить от лица этих библиотек, да и новые библиотеки тоже подвержены уязвимостям. Пару раз было, что какой-то функционал добавляли и в новом релизе уязвимости появились, когда в старом их не было.
Какие библиотеки? Какие новые? Вы так абстрактно говорите, хотелось бы примеров.
Имеется виду, что java переписывает некоторые классы от версии к версии или добавляет новый функцинал. Например есть уязвимый класс А, класс А к примеру не доступен из вне, но зато есть внутри системных бибиотек например в java.util класс Б, который нельзя запретить клиенту и он вызывает методы класса А, к примеру если в классе Б плохо настроенна фильтрация параметров, то можно провернуть уязвимость. Разве до такого додуматься сложно?
Ну вот опять абстрактно. Мы же не филосифией занимаемся, а программированием. Вы описали 1 уязвимость, а говорите об уязвимостях вообще. Наверное, вы знаете их гораздо больше, для вас это очевидно, но не для меня. Поэтому я и попросил примеров. Если не сложно, конечно.
Просто модель которую я описал выше очень часто используется в эксплоитах. Мой пример эксплоита, кстати тоже используется такую модель ибо на прямую не обратишься к классу и используется класс рефлекшена как прослойка. Если хотите примеров, я на основе других язвимостей в другой статье могу показать примеры, где будут использоваться более сложные методы. Данный пример уязвимости очень хорошо подходит для понимания как вводный в данную тему. Это самый примитив уязвимости и такое практически не встречается. В октябрьском релизе к примеру оракл не только эту уязвимость исправила, есть более серьезные уязвимости. Но по причине того, что злоумышленники смогут использовать их, то я не выкладываю описание. Если сразу перейти к сложным примерам не подготовленный читатель просто не поймет.
Эта уязвимость касается любой JVM, или иключительно «канонической» оракловой? Действительно ли тоже для JRockit или например SAP JVM, которые вполне имеют место быть?
Только тех, в которых есть класс com.sun.jmx.mbeanserver.GetPropertyAction;-)
Зачем декомпилировать, если с JDK поставляются исходники?

Вот этот метод:
    public static boolean computeBooleanFromString(
            Map<String, ?> env, String prop,
            boolean systemProperty, boolean defaultValue) {

        if (env == null)
            throw new IllegalArgumentException("env map cannot be null");

        String stringBoolean = (String) env.get(prop);
        if (stringBoolean == null && systemProperty) {
            stringBoolean =
                    AccessController.doPrivileged(new GetPropertyAction(prop));
        }

        if (stringBoolean == null)
            return defaultValue;
        else if (stringBoolean.equalsIgnoreCase("true"))
            return true;
        else if (stringBoolean.equalsIgnoreCase("false"))
            return false;
        else
            throw new IllegalArgumentException(prop +
                " must be \"true\" or \"false\" instead of \"" +
                stringBoolean + "\"");
    }

Так гораздо лучше читается, разве нет?
За что минус? Да еще и в карму. Или взять исходники из JDK — это не по хакерски?
Каждый делает как ему удобно. Я же вам не говорю как надо делать вашу работу. Вы очень сильно придираетесь к каждому слову и переворачиваете смысл. Будте проще. Код изначально был такой, но по правилам оформления статей на хабре нельзя использовать двойные пробелы и было решено все-таки сделать код плоским. Читаем выше где я писал, что если есть где-то ошибки и есть предложения то пишите в пм, все исправим и сделаем в лучшем виде. Ваше сообщение насчет кода выглядит очень не корректно и как претензия. И пожалуйста не надо тут навешивать ярлыков, никто тут не писал, что я хакер. И тем более делать выводы за других, как делать хорошо, а как нет.
Оно выглядит как уважение о читателях, ибо я лично сломал глаза о ваш плоский код. Хабр дает замечательные средства для форматирования, их можно и нужно использовать.
Кстати src.zip из JDK имеет не все файлы, к примеру отсутствует полностью папка sun. src.zip полезен когда вы хотите дебагать свое приложении и хотите узнать, что происходит внутри системных библиотек, к примеру анализировать работу эксплоита, но некоторых файлов все равно не хватает.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.