JDK-8027711 : Unify wildcarding syntax for CompileCommand and CompileOnly
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: hs25,9,10
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2013-11-01
  • Updated: 2023-07-24
  • Resolved: 2023-06-09
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 22
22 b02Fixed
Related Reports
Blocks :  
JDK-8046155 - JEP 165: Compiler Control
CSR :  
JDK-8308287 - Unify syntax of CompileOnly and CompileCommand
Duplicate :  
JDK-8302639 - Add support for asterisk operator for -XX:CompileOnly
Relates :  
JDK-8308662 - Update the "java" tool specification for CompileOnly
Relates :  
JDK-8282797 - CompileCommand parsing errors should exit VM
Relates :  
JDK-8312573 - Failure during CompileOnly parsing leads to ShouldNotReachHere
Sub Tasks
JDK-8309186 :  
Release Note: Unify Syntax of CompileOnly and CompileCommand - Resolved
Description
At the moment CompileCommand and CompileOnly use different syntax for wildcarding.
In some cases it is impossible to just take pattern used with CompileOnly and plug it into compile command file. Syntax used by CompileOnly is also not very intuitive.

It would be nice if both commands will use the same syntax for wildcarding.
Comments
Changeset: f5cbe53f Author: Tobias Holenstein <tholenstein@openjdk.org> Date: 2023-06-12 07:39:23 +0000 URL: https://git.openjdk.org/jdk/commit/f5cbe53fdd736f54a140e9db2499a7439f8752c4
12-06-2023
A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/13802 Date: 2023-05-04 13:36:22 +0000
17-05-2023
Still valid. Fix this when touching this code the next time.
23-03-2018
-XX:CompileOnly is used in about 110 tests. Many of them rely on multiple patterns, and most reply on implicit wildcard matching. Alternatives: 1) Fix same wildcarding as rest of compile command and change patterns in all the tests 2) Remove CompileOnly and change to CompileCommand in all the tests including wildcarding (We could consider multipatterns too - CompileCommand=compileonly,java.*,com/sun.*,...) 3) Close as WNF and fix the documentation (JDK-8071652)
03-11-2015
Sounds good.
20-03-2015
I think the consensus is to remove the standalone CompileOnly flag. I will not do this as part of the compiler control JEP. Will follow up with this after Compiler Control is integrated.
20-03-2015
CompileOnly is used in 104 files in the JDK. Investigate making it an alias for -XXCompileCommnad=compileonly instead
21-11-2014
There already are a commandline CompileCommand for compileonly. "-XX:CompileCommand=compileonly,java.lang.String::length". We could just retire the standalone version.
17-11-2014
It is good suggestion. We will do it when we have time.
01-11-2013
Note that CompileOnly may accept incorrect patterns like "java::lang::String::length" and treat it as a method "length" defined in any class that has substring "java" it fully qualified name. The same in case of "java.lang.String.length". Since it does not print any warnings/errors or messages that describe what pattern will be used (as in case of CompileCommand), it could lead to unwanted behaviour of compiler. If you think that this RFE should be closed, then please file a new bug to address this particular issue.
01-11-2013