Spring Boot 2.1.0 M2 and JSP "error source level"

[Maze-fr]

Hello,

I am currently upgrading from using Spring Platform Athens-SR6 to Spring Boot Starter Parent 2.1.0 M2 (preparing for Java 11).
I finished upgrading changing class names, libs, etc. and I proudly start my test application, and then...

org.apache.jasper.JasperException: Unable to compile class for JSP: 

An error occurred at line: [23] in the generated java file: [... not interesting path to the Java file generated for the JSP ...]
Syntax error, parameterized types are only available if source level is 1.5 or greater

An error occurred at line: [38] in the generated java file: [... not interesting path to the Java file generated for the JSP ...]
'<>' operator is not allowed for source level below 1.7

[... and many others ...]

I spent about a day to find the solution, after checking and changing Eclipse (Photon, in my case) compiler compliance level, trying to force compilerSourceVM property, loosing my sanity in StackOverflow, etc.
The solution is to force a dependency on org.eclipse.jdt.core.compiler:ecj with 4.6.1 version. I tried manually with 4.3.1 (see below), and I tried org.eclipse.jdt:ecj (see below) with version 3.14.0, but both didn't work.

I decided to compare my dependency hierarchies between the 2 configurations :

• Spring Platform Athens-SR6 :
  • tomcat-embed-jasper 8.5.15 gives me org.eclipse.jdt:ecj 3.12.3 ; in a Tomcat 8.5.15 installation zip, there is org.eclipse.jdt.core.compiler:ecj 4.6.3 version lib, from org.eclipse.jdt:ecj 3.12.3 bundle
  • spring-boot-dependencies:1.4.7.RELEASE gives me querydsl-collections:4.1.4 that gives me org.eclipse.jdt.core.compiler:ecj 4.3.1
• Spring Boot Starter Parent 2.1.0 M2 :
  • tomcat-embed-jasper 9.0.10 gives me org.eclipse.jdt:ecj 3.13.102 ; in a Tomcat 9.0.11 installation, there is org.eclipse.jdt.core.compiler:ecj 4.7.3a version lib, from org.eclipse.jdt:ecj 3.13.102 bundle
  • spring-boot-dependencies:2.1.0.M2 gives me querydsl-collections 4.2.1 gives me org.eclipse.jdt.core.compiler:ecj 4.3.1

So... nothing special...
According to that, the final solution I use, which seems cleaner to me, is to exclude org.eclipse.jdt.core.compiler:ecj 4.3.1 from querydsl-collections 4.2.1 so that I use effectively org.eclipse.jdt:ecj 3.13.102.

It brings me to ask 2 questions :

• Considering that Spring Boot 2.1 is supposed not to support Java version under 1.8, shouldn't it be relevant to force JSP source compilation level to a minimum of Java 1.8 if it isn't explicitly specified ?
• It really bothers me to have to force the "good" ecj version as I think it should be provided by spring-boot-something-starter dependency. Isn't there a conflict on ecj lib versions that has to be solved in ?

Regards ;-)

[wilkinsona]

Thanks for the analysis, but I think we need to take a step back and define the problem more precisely before we consider possible solutions.

By default, the JSP compiler will use 1.7 for both source and target. Given the errors that you are seeing it would appear that something has customised this to be 1.4 or even earlier. Perhaps you can provide a minimal sample that reproduces the behaviour that you have described? Without one, or at least without knowing what's customising the JSP's source level, I don't think we can proceed here.

[Maze-fr]

Unfortunately, I can't provide a minimal test, as I work on a company framework based on Spring, that includes a lot of things, and so any of them could influence the result (who knows...).
I can try any piece of code or configuration change you want, or provide you my dependencies, but I can't "open" the code I'm working on.

As you talked about "something has customised this to be 1.4", it reminded me that I removed those properties from my parent POM, as they are by default in 2.1 :

        <java.version>1.8</java.version>
        <maven.compiler.target>${java.version}</maven.compiler.target>
        <maven.compiler.source>${java.version}</maven.compiler.source>

So I tried with it (back)... still failing. Then I tried to force to querydsl-collections:4.1.4, just in case, but still failing. Then I removed it from dependencies, and it works.
Clearly, the problem is having querydsl-collections as a dependency.

Maybe a simple test would be to have a minimal web project with a JSP compiling only with Java 1.5+ and adding querydsl-collections as a dependency.
The (very simple) JSP tag file that failed first in the list is this one :

<%@ tag body-content="empty" pageEncoding="UTF8" %>
<%@ taglib prefix="spring" uri="http://www.springframework.org/tags" %>

<%@ attribute name="fileName" required="true" description="JS file name." %>

<spring:url value="/js/${fileName}" var="fileUrl"/>

<script type="text/javascript" src="${fileUrl}" ></script>

With that taglib definition header :

<taglib xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-jsptaglibrary_2_1.xsd" xmlns="http://java.sun.com/xml/ns/javaee"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="2.1">

[wilkinsona]

Ok, I see what's happening now.

Tomcat 9 uses 1.8 as the default source level for JSPs. By adding a dependency on querydsl-collections 4.2.1, you end up with both org.eclipse.jdt.core.compiler:ecj 4.3.1 and org.eclipse.jdt:ecj 3.13.102 on the classpath. The ordering of these two dependencies is crucial. If the former is on the classpath first, it'll failure. If the latter is on the classpath first, I'll work. This is because they both contain org.eclipse.jdt.internal.compiler.impl.CompilerOptions. The version in org.eclipse.jdt:ecj 3.13.102 knows about Java 8, whereas the version in org.eclipse.jdt.core.compiler:ecj 4.3.1 does not.

We could consider adding dependency management for org.eclipse.jdt.core.compiler:ecj but we generally try to avoid doing so for dependencies that Spring Boot does not use directly. A better solution would be for QueryDSL itself to be updated to use a more up-to-date dependency. I would recommend opening an issue with them about this and linking to it here. A secondary problem is that same class existing in multiple dependencies. I would recommend using something like the Duplicate Finder Maven Plugin to keep your classpath clean and avoid fragile scenarios where classpath ordering becomes crucial.

I'm going to close this one for now in favour of this being addressed at source in QueryDSL. If they can't update their ECJ dependency for some reason then we can re-open this issue and reconsider our options.

[Maze-fr]

It looks like the problem already appeared with Spring Data : querydsl/querydsl#2151 (still not closed after a year...)
So I added a reference to this issue.