RFR(S) : CODETOOLS-7902810 : allow test/driver to examine problem lists

[Igor Ignatyev]

Hi Jon,

indeed, we might use an external file for non test-specific properties / env. variables, and that might even improve overall performance (as we won't set all these properties for each and every tests including ones which don't care about any of these properties). since the tests would have to load property from external file, I can foresee two (related) drawbacks:
1. it will somewhat complicate code of the tests which read these properties directly (as opposed to using test library classes) and there are currently ~2k such tests in jdk/jdk
2. tests which depend on these properties and use custom security manager/policy might require some extra love. we will need to grant j.i.FilePermission read to that property file, the easiest way to do that would be to have a system property which points to that file, so we could use property expansion to refer to it.

although performance improvement would depend on I/O (as the tests which need properties would have to read a file now at least once per JVM under test), I still think that in general it would give us some advantage.

in any case, to get measurable benefits from it, we would need to remove as many of existing properties as possible, hence we will need some kind of transition period and/or TEST.properties-level switch so we can have both set system properties and properties in an external file while updating our tests.

-- Igor


> On Dec 9, 2020, at 11:35 AM, Jonathan Gibbons <jonathan.gibbons at oracle.com> wrote:
> 
> For discussion ...
> 
> The set of env variables and system properties does seem to be growing without bound.
> 
> Should we be looking at alternative mechanisms, such as an external file, for some of these values, especially those which are not test-specific?
> 
> -- Jon
> 
> On 12/9/20 11:11 AM, Igor Ignatyev wrote:
>> http://cr.openjdk.java.net/~iignatyev/CODETOOLS-7902810/webrev.00/
>>> 28 lines changed: 27 ins; 0 del; 1 mod;
>> Hi all,
>> 
>> could you please review this small patch which adds `test.exclude.files` /   `TESTEXCLUDEFILES and `test.match.files` / `TESTMATCHFILES` java properties / env. variables which contain list of paths to files specified via `-exclude:` and `-match:` respectively?
>> 
>> from JBS:
>>> some of our jtreg tests are actually wrappers around 3rd party tests. and sometimes one wrapper runs more than one test (due to performance or other restrictions). as with any other tests, we might need to temporarily exclude some of these tests from execution, and using regular jtreg ProblemList files (specified by -exclude: option) is the most natural way to do that. unfortunately, jtreg doesn't provide a way for tests to know which files were specified by -exclude: option, let alone a way to determine if certain tests should be excluded (based on names and current OS/arch).
>> 
>> JBS: https://bugs.openjdk.java.net/browse/CODETOOLS-7902810
>> webrev: http://cr.openjdk.java.net/~iignatyev/CODETOOLS-7902810/webrev.00/
>> 
>> Thanks,
>> -- Igor
>>