jtreg cannot be run against a pre-built/downloaded JDK anymore?

[David Holmes]

On 15/11/2021 11:45 pm, Jaikiran Pai wrote:
> The way I used to use this previously was more for convenience than 
> anything more. Very specifically, I used to do something like this:
> 
> - Work on some bug fix with latest JDK master source repo.
> 
> - Add a jtreg test to verify the fix
> 
> - Send out a PR and wait for reviews
> 
> - On some occasions, the review suggestions include relatively big 
> changes to the jtreg test case. In such cases, I used to do those 
> changes in the test, verify that the test still continues to pass. 
> However, I would even want to make sure the test still reproduces the 
> original issue. So instead of git reverting only the source code 
> changes, building the current JDK again and then running the updated 
> test, I would just point the jtreg run to a differently older version of 
> a JDK (which wouldn't have the fix) by using the 
> -jdk:<path-to-downloaded-jdk>. I would then expect the test to fail with 
> the expected issue.
> 
> It was just a convenience than anything more.

Sure and most of the time that will work. But if the test relies on 
something that is only present in the later JDK binary then obviously 
the test will fail.

Cheers,
David

> -Jaikiran
> 
> On 13/11/21 1:26 pm, Thomas Stüfe wrote:
>> Maybe the easiest way for you would be to get the source drop matching 
>> the
>> binary JDK from the vendor of your JDK. Since you may also have
>> vendor-specific changes (albeit rare, its possible).
>>
>> Cheers, Thomas
>>
>>
>> On Sat, Nov 13, 2021 at 7:38 AM David Holmes <david.holmes at oracle.com>
>> wrote:
>>
>>> On 13/11/2021 3:37 pm, Jaikiran Pai wrote:
>>>> I got past this with an extensive workaround for now. I moved/copied
>>>> that test case java file outside of the JDK source tree, then created a
>>>> new/custom TEST.ROOT which is very minimal and has no reference to
>>>> whitebox for bootlibs, then made sure the jtwork directory is also
>>>> outside of the JDK source tree (so that the test is compiled afresh) 
>>>> and
>>>> then ran that test. That helped, but it's only for this test since its
>>>> requirements in the test are very minimal. I don't see a way to get 
>>>> past
>>>> this if I have to run the wider range of jtreg tests that reside in the
>>>> JDK source tree against a pre-built/downloaded Java 17 or any previous
>>>> versions.
>>> Basically you're not supposed to do that. You have to test a given
>>> binary with the tests that existed when that binary was built. Many
>>> things in the tests can change that will fail to run with an older JDK.
>>>
>>> In theory you can use the build number of the binary JDK to checkout the
>>> tests corresponding to that build using the appropriate build tag.
>>>
>>> Cheers,
>>> David
>>>
>>>> -Jaikiran
>>>>
>>>> On 13/11/21 10:26 am, Jaikiran Pai wrote:
>>>>> Hello Leonid,
>>>>>
>>>>> On 13/11/21 9:38 am, Leonid Mesnik wrote:
>>>>>> Hi
>>>>>>
>>>>>> It is a hotpost testing problem rather than a jtreg problem. So I’ve
>>>>>> added
>>>>>> hotspot-dev at openjdk.java.net<mailto:hotspot-dev at openjdk.java.net>
>>> alias.
>>>>> Thank you for adding the right list.
>>>>>> ...
>>>>>> Could you please check that you use exactly the same sources during
>>>>>> testing which have been used to build JDK.
>>>>> Do you mean the sources of the JDK against which the test is being
>>>>> run? I don't have those sources since this test runs against a
>>>>> pre-built binary downloaded from https://jdk.java.net/17/
>>>>>
>>>>> -Jaikiran
>>>>>