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 <d...@ubuntu.com
<mailto: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 <mailto:igor.ignat...@oracle.com>>:
On Apr 23, 2020, at 6:12 AM, Erik Joelsson
<erik.joels...@oracle.com <mailto: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
