Am 10.02.2022 um 14:41 schrieb Rémy Maucherat:
On Thu, Feb 10, 2022 at 2:11 PM Mark Thomas <ma...@apache.org> wrote:
On 09/02/2022 14:04, Rainer Jung wrote:
Hi all,
I wonder how important it is to be able to run the unit tests for TC
8.5-10.0 with JVM versions 8 or even 7 (TC 8.5).
The unconditional addition of unit test jvmargs "--add-opens=..." in
2b6e19e971a980e38bcd30f05c554d9b798666c0 (TC 10, backported) means, we
can no longer run the tests with Java 8 or even 7.
If I remove those jvmargs from build.xml, I run into a second problem
when testing TC 8.5 with Java 7. In
014f4746176c7f27cda7c04b2c6036a539c385ff EasyMock was updated from 3.x
to 4.x, which needs Java 8 to run. Several tests fail with
UnsupportedClassVersionError in a few EasyMock classes.
I can work around all of these myself for running the tests here, but I
wonder, what kind of setup for testing we want to support out-of-the box.
Note that by reintroducing the previous compatibility trick for jvmargs
(TC 8.5, 9 and 10) and using the old EasyMock branch for TC 8.5 we could
still build and test with Java 11, but would also allow testing on the
other target Java versions we support.
WDYT?
I've been thinking about this since I read this yesterday.
I like that the move to Java 11 allowed us to reduce the differences
between the build scripts.
+1
So the decision is: Is the benefit of being able to test with older Java
versions worth the differences this would re-introduce?
We don't test the JreCompat code so there aren't any Java version
specific tests. So what do we gain by testing on Java 7 / Java 8? I can
think of a few things:
- that we really have coded to the correct Java version
- that the code runs as expected on that Java version
For example TLS behavior. There are functionalities that have the same
API in different Java versions, but implementations provide different
behavior.
Both of those things are more testing Java than testing Tomcat but I can
see that there is some benefit - especially if one is concerned about
the possibility of the code behaving differently on Java 7/8 compared to
Java 11.
It is a good point that this is about testing Java (the bytecode
produced should target Java 8 exclusively - talking about Tomcat 9,
for example -, and the behavior of the API should be the same; if
either becomes false, then this is actually a Java bug).
Concerning the same API behavior, wouldn't changes in TLS support
qualify as such a change which is not a bug? Of course, most of the time
Tomcat would be agnostic in itself to such changes, but I wouldn't be so
sure that we would not every now and then find a relevant difference via
the unit tests.
To be honest, I only partially trust that "release" feature right now.
Although it seems to work, it might simply need time to get used to
the concept ! I did point out the testsuite problem when this was
initially discussed. And I understand the lack of trust if Tomcat is
simply not tested on Java 8 (or 7, cough; let's pretend it is really
tested ;) ) before release.
Instead of completely reverting to the previous properties hack and
reintroducing differences between branches, I would simply advocate
moving the offending values to hardcoded property values in build.xml
(which can then be replaced by Java 8 compatible placeholder values in
your own build.properties - same idea than for the dependencies which
can be replaced by Java 8 compatible ones).
Sounds like a reasonable compromise. If we would find over time more
reasons to actually run the tests, would it be easy to define JVM
version specific build.properties lines on CI nodes? No idea, whether we
already overwrite build properties on CI.
I'm not concerned about that but neither am I too concerned about the
re-introduction of a few differences. I guess I am -0 overall provided
that any change does not impact the existing CI systems.
Rémy
Thanks and regards!
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
