mistriggered "error: warnings found and -Werror specified" for java warnings

[Magnus Ihse Bursie]

On 2020-04-23 17:17, Igor Ignatyev wrote:
> 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].
 From my point of view, I think we should have a very narrow range of 
supported jtreg versions. It's not like when building with the system 
zlib; this is a framework solely used for testing the JDK, and I think 
we can (and should) be quite strict as to which versions the current 
code base is designed to work with.

Things get a little bit muddier if the version of jtreg matches, but not 
an upstream dependency for jtreg. I still tend to lean towards Igor's 
suggestion here, that a properly setup jtreg environment is the one 
officially built by jtreg.

/Magnus


>
> 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
>
>> On Apr 23, 2020, at 7:48 AM, Matthias Klose <doko at ubuntu.com 
>> <mailto:doko at ubuntu.com>> wrote:
>>
>> On 4/23/20 4:05 PM, Magnus Ihse Bursie wrote:
>>>
>>>> 23 apr. 2020 kl. 15:50 skrev Igor Ignatyev 
>>>> <igor.ignatyev at oracle.com <mailto:igor.ignatyev at oracle.com>>:
>>>>
>>>>
>>>>
>>>>> On Apr 23, 2020, at 6:12 AM, Erik Joelsson 
>>>>> <erik.joelsson at oracle.com <mailto:erik.joelsson at 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
>