Let jvmtiGen exit with a non-zero exit code upon failure
serguei.spitsyn at oracle.com
serguei.spitsyn at oracle.com
Thu Oct 29 22:41:35 UTC 2015
Hi Carsten,
The fix looks good.
I share the Staffan's comments though.
If understand correctly, you do not have an openjdk author status yet.
I will sponsor your fix.
Please, let me know the bug ID after you create one.
Thanks,
Serguei
Please, let me know
On 10/29/15 14:22, Staffan Larsen wrote:
> Carsten,
>
> This looks good with a few comments:
>
> 1) If you make the “verbose” variable into a static field, you can avoid the final-copying.
> 2) nit: Line 216: put "System.exit(1);” on it’s own line
>
> Oh, and create a bug: https://bugs.openjdk.java.net
>
> Thanks,
> /Staffan
>
>> On 29 okt. 2015, at 14:54, Daniel D. Daugherty <daniel.daugherty at oracle.com> wrote:
>>
>> JVM/TI belongs to the Serviceability team so adding serviceability-dev at ...
>>
>> Dan
>>
>>
>>
>> On 10/28/15 8:45 PM, Carsten Varming wrote:
>>> webrev: http://cr.openjdk.java.net/~cvarming/jvmtiGen/
>>> bug: ?
>>>
>>> jvmtiGen is used to process a number of xml and xslt files in OpenJDK.
>>> Currently jvmtiGen exits with exit code 0 regardless of its success. This
>>> causes make to often consider a target finished when in fact the target
>>> failed. It also leads to funny error checking after the execution of
>>> jvmtiGen. For instance, in many trace.make files[*] a test for the
>>> existence of the output file is carried out after the completion of
>>> jvmtiGen. In a clean working repository that test is equivalent to jvmtiGen
>>> exiting with a proper exit failure code on failure, but in a dirty working
>>> repository the target file might just be pre-existing. This causes
>>> unnecessary pain when working with files processed by jvmtiGen.
>>>
>>> In this change I chose to exit with exit code 1 whenever a failure is
>>> detected, be it a dtd validation failure, an IO failure, or something else
>>> entirely. This halts the building of OpenJDK on failures and ultimately
>>> makes development easier. I also added a verbose option such that warnings
>>> from the xml parser and dtd checker can be printed on stderr if desired.
>>> Finally, I changed all the error message printing to stderr. :-)
>>>
>>> Let me know what you think.
>>>
>>> BTW. This is the first time I tried the webrev system, so hopefully it all
>>> looks good. I havn't figured out how to create a bug yet, whence the
>>> question mark.
>>>
>>> I wasn't sure if hotspot-runtime-dev is the right email alias. Please let
>>> me know if there is a more appropriate alias for this email.
>>>
>>> [*] Why are so many of the non-shared makefiles almost identical?
More information about the hotspot-runtime-dev
mailing list