JDK-8214719 : Deprecate -Xverify:none option
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 12
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2018-12-03
  • Updated: 2022-07-26
  • Resolved: 2019-02-20
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 13
13 b09Fixed
Related Reports
CSR :  
JDK-8214731 - Deprecate -Xverify:none option
Relates :  
JDK-8224763 - Update man pages to show deprecation of -Xverify:none
Sub Tasks
JDK-8218003 :  
Release Note: Deprecated Java Options -Xverify:none and -noverify - Closed
JDK-8230630 :  
Release Note: Deprecated Java Options -Xverify:none and -noverify - Closed
Description
Deprecate the -Xverify:none option because it allows execution of Java code that violates the Java Virtual Machine Spec.
Comments
Some feedback for consideration when removing -Xverify:none so a complete strategy can be employed: 1) Some users may care about archive dump time performance and desire to avoid verification overhead when it is not necessary (loaded classes are 'trusted'). 2) There may be use cases where CDS is not enabled. Today users can still use -Xverify:none to avoid verification overhead in those cases where verification is not necessary. 3) This is an indirect and is a CDS only issue today. With dynamic archiving, users must remove -Xverify:none from their command line options at dump time to successfully generate a shared archive.
19-11-2019
URL: http://hg.openjdk.java.net/jdk/jdk/rev/7ca9e625d6b2 User: hseigel Date: 2019-02-20 18:25:26 +0000
20-02-2019
Users can get their performance boost for well formed class files by using AppCDS instead of -Xverify:none. AppCDS will verify their code before archiving it so users will be able to both verify their code and get their desired performance boost. The plan is not to just take away the flag. That is why this step is to deprecate the flag. Deprecating the flag does not change its behavior other than to issue a warning when it is used.
06-02-2019
The use of this flag can be a performance boost for apps that already know they have well formed and correct classfiles. Why should they be penalised just because someone might use this flag in a situation where they can allow external non-verified code into the system? This flag has been around for a very, very long time and I don't think it reasonable to just take it away. Moving to a -XX flag is also not an option as some users won't allow their use in production, whereas this -X flag can be used (that's conjecture based on previous suggestions to turn flags into -XX variants).
03-12-2018