Hi Matthias,

> jtharness 6.0-b10 and jtreg 5.0-b1.

jtreg 5.0-b1 "officially" depends on jt6.0-b08, and the bundle which we use 
internally has jt6.0-b08 within it, and AFAICT jt6.0-b08 hasn't deprecated 
c.s.j.H.Observer::finishedTesting yet. so as a temp. solution to allow 
configurations like yours, we need to suppress deprecation warning in failure 
handler, that's if we decide that such configurations are "supported", which 
isn't that obvious as you might encounter some deviations in jtreg behavior   
b/c another version of its dependency is used, so I'd encourage you to use the 
exact same version as used by jtreg build script[1].

a proper solution would include switching jtreg to newer version of jt-harness 
(which implies adjustment of jtreg and subsequently testing), promotion/tagging 
of newer jtreg build, switching to newer jtreg in jdk and updating in 
failurehandler.

Thanks,
-- Igor 

[1] 
http://hg.openjdk.java.net/code-tools/jtreg/file/fc37a1d7f0ea/make/build-all.sh#l129
 
<http://hg.openjdk.java.net/code-tools/jtreg/file/fc37a1d7f0ea/make/build-all.sh#l129>

> On Apr 23, 2020, at 7:48 AM, Matthias Klose <d...@ubuntu.com> wrote:
> 
> On 4/23/20 4:05 PM, Magnus Ihse Bursie wrote:
>> 
>>> 23 apr. 2020 kl. 15:50 skrev Igor Ignatyev <igor.ignat...@oracle.com>:
>>> 
>>> 
>>> 
>>>> On Apr 23, 2020, at 6:12 AM, Erik Joelsson <erik.joels...@oracle.com> 
>>>> wrote:
>>>> 
>>>> Hello Matthias,
>>>> 
>>>>> On 2020-04-23 05:51, Matthias Klose wrote:
>>>>> jdk-15+20 fails to build with
>>>>> 
>>>>> * For target 
>>>>> support_test_failure_handler_classes__the.BUILD_FAILURE_HANDLER_batch:
>>>>> /packages/openjdk/15/openjdk-15-15~20/test/failure_handler/src/share/classes/jdk/test/failurehandler/jtreg/GatherDiagnosticInfoObserver.java:136:
>>>>> warning: [deprecation] finishedTesting() in Observer has been deprecated
>>>>>   public void finishedTesting() {
>>>>>               ^
>>>>> error: warnings found and -Werror specified
>>>>> 1 error
>>>>> 1 warning
>>>> That's strange. I assume this tool is built with the boot JDK, so that 
>>>> makes me wonder what boot JDK you are using as we have not seen this 
>>>> warning/error?
> 
> that's with 14.0.1+7.
> 
>>> I guess version of jtreg/jt-harness is more relevant here as deprecated 
>>> finishedTesting is from com.sun.javatest.Harness.Observer.
>> 
>> Aha, that’s probably the explanation. I recently removed deprecation as a 
>> disabled warning for the failure handler. If it depends on jtreg, and it has 
>> changed deprecation status, that might trigger a compilation warning.
>> 
>> I’m on mobile now and can’t check how this should be resolved. 
>> 
>> If a newer version of jtreg introduced the depreciation, we should fix our 
>> sources. If this is something only present in older sources (?) we might 
>> need to raise the minimum jtreg version. 
> 
> jtharness 6.0-b10 and jtreg 5.0-b1.
> 
>> 
>> /Magnus 
>> 
>>> 
>>> --Igor
>>> 
>>>>> 
>>>>> Apparently --disable-warnings-as-errors only has an effect on C/C++ files,
>>>>> however the build diagnostics trigger on java warnings as well, and 
>>>>> apparently
>>>>> -Werror is hard-coded in various places for java options. Should the
>>>>> documentation for this configure option be clarified, or should it 
>>>>> trigger for
>>>>> java warnings as well?
>>>> 
>>>> Correct. The reasoning is that OpenJDK is built on a wide variety of 
>>>> environments with different compiler versions, so keeping the build 
>>>> warning free on all of them isn't feasible. This option makes it possible 
>>>> to build with all those different compiler versions while still 
>>>> maintaining a warning free source for a core set of compiler versions. In 
>>>> contrast, the Java code should only be compiled with a very small set of 
>>>> javac versions, which should be easily controlled. The majority of the 
>>>> code is even compiled with the Javac we are building. We have contemplated 
>>>> a similar option for Java code, but concluded that it doesn't serve any 
>>>> purpose. The Java source should just always be warning free.
>>>> 
>>>> /Erik

Reply via email to