JDK-8027411 : javap tonga tests cleanup: write a java program to test invalid options -h and -b
  • Type: Enhancement
  • Component: tools
  • Sub-Component: javap
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2013-10-28
  • Updated: 2013-11-22
  • Resolved: 2013-11-05
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 8 Other
8 b117Fixed port-stage-ppc-aixFixed
Related Reports
Relates :  
This is to replace tonga tests javap_help, javap_t15, and javap_t3a on this page http://wiki.se.oracle.com/display/JPG/ToolsTestsByTestlist-javap.

javap_help also tests -help option, but I found that it is already covered by developers' test T4501660.java.

javap_help test -xx, which is the same result as -b in javap_t3a. So I only do -b and no -xx.
8-critical-sqe: this is a part of the SQE test collocation. Based on the agreement with Michel, Bernard and Ken in the Langtools EFP review on 10/30, SQE will continue pushing tests to JDK 8 repo until RD2.

8-critical-dev: this is part of the effort to convert tonga tests to jtreg

Code review has been approved by Jonathan.

The test as proposed is reasonably good, subject to a couple of minor feedback comments, so once those are addressed, the test can go in. We should remove the code for -h, and when we do that, we should remove the test case from this test. I think it is too late to be tinkering like that now, so this will happen in 9.

I have submitted a RFE https://bugs.openjdk.java.net/browse/JDK-8027415 for JDK9. Code review is in progress https://sthinfra10.se.oracle.com/cru/CR-JDK8TL-308.

Is there another test that checks the javap output on invalid parameter? If not and the proposed fix is not the most suitable one, what's a better way to test the expected exit and expected error message? I agree with Jon on having an RFE to remove the special message for -h and other deprecated options and reflecting that in the test.

The overall goal here should be to improve the JDK's regression tests. One way to do that may be porting existing SQE regression tests to the JDK repo and toolset.However, if an SQE test is not sufficiently useful, it should just be abandoned.

It would be better to file an RFE against javap to remove support for the -h option altogether.

This is a negative test for diagnostic purpose. We want to cover both kinds of invalid options: -h used to be valid but obsolete. -b is an invalid option just like tens gazillion invalid options. We only use -b to represent them. -h and -b generate different output. javap -h shows Error: -h is no longer available - use the javah program javap -b shows Error: unknown option: -b Usage: javap <options> <classes> use -help for a list of possible options

This seems like a waste of time. There are ten gazillion options that are invalid. Why focus on these two? Yes, they may have been valid options at some point in the past, but is it *really* worth a test to verify that they are no longer supported. The corresponding Tonga tests should just be deleted.