tomcat7 package not compliant with tomcat specification

Status changed to 'Confirmed' because the bug affects multiple users.

Hi Thomas, I might be totally misjudging that now so please help me if I do.
And the error of the missing method you report sounds reasonable without knowing the details.

But the page you linked shows the versions you referenced "... and later" as IIRC Java bytecod holds the target VM Version and the JVMs are backward compatible usually.
One has to set stuff like "-source 1.7 -target 1.7" to so so IIRC.
And the Manifest file holds:
...
X-Compile-Source-JDK: 1.6
X-Compile-Target-JDK: 1.6

I agree that the function is something that changed from java 7 to 8:
Notably the Java 1.7 ConcurrentHashMap#keySet() returns a Set<K> while the 1.8 ConcurrentHashMap#keySet() returns a ConcurrentHashMap.KeySetView<K,V>`.

The build of Tomcat depends on "default-jdk" which maps to openjdk-8-jdk in Xenial.
That is how the build gets version 8.
But that just matches the "6 or 7 and later".

So TL;DR for now it is an issue but it should not be one :-/
The Java version switch should be compatible but it is now.

For now a workaround for you might be to set up your tomcat7 to run with the jdk-8 that should get it working if you have no other version incompatibilities.

I'm not enough of a "tomcat man" but I think I found the related upstream bug.
For Zesty a new sync of Debian should fix it, as Emanuel reported it to be fixed in latest Debian.

For Xenial (&Yakkety) I don't know what would have to be done atm.

Hi Christian,

The issue would be that even though X-Compile-Source-JDK is set to 1.6, the compiler is still using the standard library from Java 8. The ConcurrentHashMap method `java.util.concurrent.ConcurrentHashMap.keySet()Ljava/util/concurrent/ConcurrentHashMap$KeySetView` has had its return type narrowed to a new class that is not present in earlier Java versions, so anything compiled with the Java 8 standard library will expect a ConcurrentHashMap$KeySetView as the type. To compile with Java 8 but make it cross compatible with Java 6, you need to use the bootstrap classpath option to javac and point it at a JDK 6/7 rt.jar, see here for an explanation https://blogs.oracle.com/darcy/entry/bootclasspath_older_source.

FWIW I am being bitten by this issue as well.

Also reported at #1669093

In the current state, tomcat7 and tomcat8 in Xenial and newer are both built with Java 8, since it is the default JRE. However, as this bug and others point out Java 7 support does not always work because of this. The example in this bug is that the ConcurrentHashMap KeySetView method is available in Java 8, but is not available in Java 7.

The solution used by the Debian maintainers [1] was to drop support for Java versions less than the version compiled with [2]. This would be mean that both tomcat7 and tomcat8 would use Java 8 or newer. On one hand this makes sense that the default Java version should be used, however as pointed out the Java documents claim that support should be possible with older versions. If this approach were to be adopted it would require an SRU for Tomcat 7 and Tomcat 8 to xenial, yakkety, and zesty.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=848612
[2] https://anonscm.debian.org/cgit/pkg-java/tomcat8.git/commit/?id=aecf5a6

After discussing this with nacc in #ubuntu-server he asked if I could verify whether this behavior was present in an upgrade from the precise LTS to trusty LTS. Similar to the trusty LTS to xenial LTS upgrade where the default java changed from 1.7 to 1.8, the precise LTS to trusty LTS default java version changed from 1.6 to 1.7.

The tomcat7 package has used the default-jdk and default-jre-headless as build-depends since version 6.0.20-8 released in Dec of 2009. Meaning for all the LTS listed above, tomcat7 is built using whatever the release has made the default Java version (i.e. 6 in precise, 7 in trusty, 8 in xenial).