RFR(T): 8221738: ErrorFile option does not handle pre-existing error files of the same name

[Thomas Stüfe]

Hi Coleen,

thank you for your review, and sorry for the belated response.

As for OutputAnalyzer(Path), I honestly like my version more. It allows me
to scan for a sequence of pattern which should appear in order in the file,
but not necessarily one after the other. The way to do that with
OutputAnalyzer would be to put all patterns in one regex separated by
wildcards and apply that to the whole output but I find that would be way
less readable and probably also less efficient.

I have earmarked this functionality (scan for a collection of Pattern which
are supposed to appear in order) for future inclusion into OutputAnalyzer
or some other jtreg utility class but left that out for now.

Thank you,

Thomas


On Fri, Apr 26, 2019 at 3:06 PM <coleen.phillimore at oracle.com> wrote:

>
> I think this looks very reasonable.   OutputAnalyzer now has a
> constructor that takes a file name as a parameter.  You should use this
> instead for your test.
>
> Thanks,
> Coleen
>
>
> On 4/7/19 3:17 AM, Thomas Stüfe wrote:
> > Hi all,
> >
> > May I please have reviews for this small fix:
> >
> > bug: https://bugs.openjdk.java.net/browse/JDK-8221738
> > cr:
> >
> http://cr.openjdk.java.net/~stuefe/webrevs/8221738-errorfile-option-does-not-handle-pre-existing-error-files-of-the-same-name/webrev.00/webrev/
> >
> > Fixes a long standing issue where -XX:ErrorFile=<somename> will only work
> > if <somename> does not exist yet. If it does, error file falls silently
> > back to "<curdir>/hs_err_pid...".
> >
> > For more detailed discussions, please see the bug and the associated CSR.
> >
> > The fix now causes the error file to be overwritten
> >
> > Thanks, Thomas
>
>