RFR: Data plugin

[Alexandre Iline]

On Wed, 27 Apr 2022 19:18:04 GMT, Alexandre Iline <shurailine at openjdk.org> wrote:

>> It's a minor comment. Just to say that here, I mean there are 2 kinds of properties -  Environment > export JCOV_OPTION=path && System.getenv("JCOV_OPTION") and java -DJCOV_OPTION=path && System.getProperty("JCOV_OPTION") First and second ways to get external properties don't have in mind their update/clean. If System properties are used as global mutable variables of the program then it would be much better to use a special singleton container like a hash table for this need. If these options are read-only then all updating/cleaning methods are superfluous.
>
> In fact, in the current state of the code, system properties are changed only from tests. Tests simply do what a user is suggested to do: set some system properties, run a JCov empty point class, either from command line or from some other java code. I think this is acceptable. There can be an additional interface which does not require setting system properties, but system properties will always work anyway.
> There is one exception when a system property is set not from a test: "jcov.data-saver" is set to be the same as "jcov.data.saver. I am looking if this is justified.

Upon further review, no, this is necessary. If I want to be able to implant a name of the saver SPI class into the instrumented code (into a property file), I will later have to retrieve it from the storage (the property file) and set system property, because this is where JCov is obtaining it from - from the system property. The only way to go around that would be to add some SPI to JCov itself, which would allow setting JCov up. This may be a valuable enhancement, but it will have to be done separately.

-------------

PR: https://git.openjdk.java.net/jcov/pull/19