RFR: Data plugin

[Leonid Kuskov]

On Wed, 27 Apr 2022 15:39:32 GMT, Alexandre Iline <shurailine at openjdk.org> wrote:

>> The way the plugin is designed, its behavior is controlled through the system properties. This is done this way to allow usage of jcov command line, such as Instr, JREInstr, etc, to specify how the code is instrumented, why code, where results are saved, etc. As such, it is _unavoidable_ to have the plugin code to _read_ the system properties. Here are a few examples of system properties which specifies the plugin behavior: Instrument.PLUGIN_CLASS, Instrument.JCOV_TEMPLATE, Collect.COVERAGE_OUT, Collect.COVERAGE_IN, Plugin.METHOD_FILTER, Collect.SERIALIZER
>> 
>> An additional level is added to the instrumentation to allow, during instrumentation time, to specify properties which will be needed during the  execution time. This is just a convenience which shortens command line needed to run the tests later. Instead of listing the properties on the command line when running the tests, the properties are stored within the instrumented code. This is, coincidently, a convenience which I would be handy for normal, non-plugin, Jcov functionality: to be able, during the instrumentation, specify a custom grabber port, to use an example. I thought, therefore, that the solution which I was suggesting was an elegant one, since the system properties which are set during the execution are exactly the same properties which the plugin is expected to be set as system properties to work.
>> 
>> I suppose it is possible to change the code of the plugin to try to load properties from a local storage rather than from the system properties. I will have to take a close and a hard look to see if it can be done nicely.
>
> As for reusing the system property by another application after the program shut down, I do not really know what you mean. The properties which are set are the ones which may be set anyway to control the plugin behavior.

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.

>> on line 115:
>> } else return defaultValue;
>
> on line 70 of Collect, I am defending against COVERAGE_IN property been set to an empty string as well as not been set at all. The code which you suggested is not equivalent to what I am having.

Well, I just appeal for the single way for processing all properties If option is missing then it is always NULL otherwise it has a value that should be processed in the place of using. In the program we have many options that are null by default and just one that is empty string.
For this option we have a special branch in the method From my point of view the program should be more restricted If we have m:1 branches of processing something the we should covert it to m+1:0 and remove program logic for this :1 branch.

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

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