On Mon, 26 Jan 2026 16:12:35 GMT, Jaikiran Pai <[email protected]> wrote:

>> This change ensures that the class "jtreg/SkippedException" can be found and 
>> used by the test while running with versions of jtreg that are under 7.5.1+1.
>> 
>> 
>> This has been tested elsewhere and seems to work well.
>> Test configs:
>> - JDK17 - jtreg 7.3.1+1
>> - JDK25 - jtreg 7.5.1+1 
>> 
>> https://bugs.openjdk.org/browse/JDK-8376188
>
> Thank you for the update, this looks OK to me from a jtreg test point of view.
> 
> Given the area, I will let someone from jpackage area to Review and approve 
> this. Plus, 
> `test/jdk/tools/jpackage/helpers/jdk/jpackage/test/TKit.throwSkippedException(...)`
>  seems to dynamically define the `jtreg.SkippedException` 
> https://github.com/openjdk/jdk/blob/master/test/jdk/tools/jpackage/helpers/jdk/jpackage/test/TKit.java#L1310,
>  so I'm not sure what kind of impact (if any) this change would have on this 
> or other tests in this area.

Almost any jpackage test can throw `jtreg.SkippedException`. Instead of pulling 
in this tiny dependency from the JDK test lib, jpackage tests define a copy of 
this exception type, as @jaikiran correctly pointed out.

You either need to add

 * @library /test/lib
 * @build jtreg.SkippedException

to almost every jpackage test declaration and remove the internal copy of the  
`jtreg.SkippedException` if this effort justifies the benefit, or find a better 
solution to the problem.

I guess the problem applies to JDK17 where the jpackage test lib doesn't have a 
copy of the `jtreg.SkippedException`, doesn't reference the one from the JDK 
test lib, but still supports throwing this exception via reflection: 
https://github.com/openjdk/jdk17u/blob/20a272cada273ceeec432dc027ddb62a93304143/test/jdk/tools/jpackage/helpers/jdk/jpackage/test/TKit.java#L503

The copy of the  `jtreg.SkippedException` exception was added to the jpackage 
test lib in [JDK-8352419](https://bugs.openjdk.org/browse/JDK-8352419).

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

PR Comment: https://git.openjdk.org/jdk/pull/29416#issuecomment-3800848878

Reply via email to