Я видел множество приложений, которые берут классы инструментов и берут -javaagent в качестве параметра при загрузке, также помещая -noverify в командную строку.
В документе Java указано, что -noverify отключает проверку класса.
Однако почему кто-то хочет отключить проверку, даже если они являются инструментальными классами?
Время запуска, я бы сказал. Проверка правильности классов занимает некоторое время, когда класс загружается. Поскольку классы могут загружаться ленивым способом (не при запуске приложения, а при первом использовании), это может вызвать непредвиденные и нежелательные задержки во время выполнения.
На самом деле класс вообще не нужно проверять. Компилятор не выдаст какой-либо недопустимый байт-код или конструкцию класса. Причина проверки заключается в том, что класс может быть построен на одной системе, размещаться в Интернете и передаваться вам через незащищенный интернет. На этом пути злоумышленник может изменить байт-код и создать то, что компилятор никогда не сможет создать; что может привести к сбою JVM или, возможно, обойти ограничения безопасности. Таким образом, класс проверяется до его использования. Если это локальное приложение, обычно нет необходимости снова проверять байт-код.
Когда он используется вместе с -javaagent, он скорее всего не по соображениям производительности, а потому, что агент намеренно создает "недействительный" байт-код.
Следует отметить, что недопустимый байт-код все равно может выполняться нормально, потому что некоторые правила проверки довольно строгие. Например, this не должен быть доступен в конструкторе перед вызовом супер-конструктора, потому что переменные не инициализируются в этой точке. Но могут быть и другие вещи, которые вы хотите сделать (см. Пример JRebel). Затем используйте -noverify, чтобы обойти это правило.
Debugging! На самом деле, что я сейчас делаю, и как я наткнулся на этот вопрос. В Terracotta мы делаем много инструментов для бат-кодов, и иногда это помогает отключить верификатор при отладке адаптеров класса, поэтому мы можем видеть, где именно они терпят неудачу во время выполнения.
Вы правы, мы хотим, чтобы верификатор оставался на производстве.
Использование JRebel без -noverify даст это предупреждение при запуске:
JRebel: '-noverify' отсутствует, изменения/добавления/удаления конструкторов не будут включены!
Итак, появляется, что -noverify позволяет перекодировать байт-код для выполнения некоторых действий, которые иначе не были бы возможны.
Время запуска - это проблема. Тем не менее, верификаторы теперь быстрее, также как и процессоры. Код, скомпилированный с JDK6 javac, будет по умолчанию включать дополнительную информацию, чтобы ускорить шаг проверки. Apache Harmony использует гораздо более быстрый алгоритм проверки.
Некоторые очень старые версии javac произвели неправильный байт-код. На самом деле Sun Plugin по-прежнему включает в себя исправление кода, чтобы убедиться, что некоторые файлы сломанного класса проверены.
Новый верификатор, который введен в JAVA 6, очень сложный для обработки кода.
Взгляните на это: http://chrononsystems.com/blog/java-7-design-flaw-leads-to-huge-backward-step-for-the-jvm
и соответствующий отчет об ошибке: http://bugs.sun.com/view_bug.do?bug_id=8009595