On Thu, Feb 10, 2022 at 4:25 PM Rainer Jung <rainer.j...@kippdata.de> wrote:
>
> 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 added the workaround, in build.properties, you can add:
opens.javalang=-Dtest10=1
opens.javaio=-Dtest11=1
opens.sunrmi=-Dtest12=1
opens.javautil=-Dtest13=1
opens.javautilconcurrent=-Dtest14=1
I would build everything first with Java 11 (although the release flag
is ignored if you try on Java 8) with "ant test". Then using "ant
test" again with Java 8 and the properties worked for me.
Rémy
>
> >> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
