RFR: 7902847: Class directory of a test case should be always used to compile a library [v9]

Roger Riggs rriggs at openjdk.org
Thu Apr 17 21:41:11 UTC 2025


On Wed, 16 Apr 2025 20:42:54 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> src/share/doc/javatest/regtest/tag-spec.html line 256:
>> 
>>> 254: 
>>> 255: <p>In general, classes in library directories are not automatically compiled
>>> 256: as part of a compilation command explicitly naming the source files containing
>> 
>> Where is the "shareLibraries" property defined? I'm expecting to see it defined in the TEST.ROOT or TEST.properties table like "enablePreview", etc.
>> 
>> Also, I think it should not be plural. It applies to this particular library.
>> 
>> Maybe I misunderstand.
>
> The flags should  be located in TEST.ROOT or TEST.properties for all libraries that are used by tests. It is not specific for any particular library. 
> 
> This flag is requested by @sormuras  to restore original behavior if something goes wrong with new mode.
> 
> I would like to keep temporary for a couple of releases and remove if it is not needed.  I don't like to maintain different execution modes if it is not needed.

I was expecting this text in the tag-spec to describe both behavior(s) controlled by `shareLibraries`.
And mention the property and clearly define the behavior of each case. 

That does not seem to be intended.  Instead only the changed behavior is documented and the property will not be documented. I understood the feature to control the destination directory for compiled classes but from this description it controls the source path, not the destination.

Since the behavior is being changed somewhat incompatibly, the text should clearly describe the new behavior and call out the differences and how to get the previous behavior if needed.

It would be clearer the property and its behaviors were documented in `Locations.getLibLcn` .
The name of the property should more clearly indicate it is for compatibility and the behavior when it is set.

The words "might" and "may" are red flags in any specification.

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

PR Review Comment: https://git.openjdk.org/jtreg/pull/256#discussion_r2049683639


More information about the jtreg-dev mailing list