Fix compile errors for records with custom constructors, update JDT

[zbynek]

Updating JDT by itself is enough to fix the issue described in #10045 .

There is also a similar issue with

record RecordWithDefaultConstructor(String foo) {
  public RecordWithDefaultConstructor {
    Objects.requireNonNull(foo);
  }
}

where JDT provides two canonical constructors:

// this one has no binding
RecordWithDefaultConstructor(String foo) {
  super();
  .foo = foo;
}

// this one has a binding
public RecordWithDefaultConstructor(String foo) {
  super();
  Objects.requireNonNull(foo);
  this.foo = foo;
}

Skipping the one without a binding prevents a NPE.

Unit tests added for both, minor tweaks needed to make tests pass with new JDT.

Fixes #10045

Relies on gwtproject/tools#41

[zbynek]

@niloc132 the JSP test fails with

Compiling for Java version '1.7' is no longer supported. Minimal supported version is '1.8'

Stacktrace:
	at org.apache.jasper.compiler.DefaultErrorHandler.javacError(DefaultErrorHandler.java:102)
	at org.apache.jasper.compiler.ErrorDispatcher.javacError(ErrorDispatcher.java:214)
	at org.apache.jasper.compiler.JDTCompiler.generateClass(JDTCompiler.java:611)
	at org.apache.jasper.compiler.Compiler.compile(Compiler.java:381)

Given JettyLauncher's deprecated status, is this something worth spending time on, or can we just remove the test?

EDIT: I think I found a solution, but I'm not sure if it's too hacky.

[niloc132]

I think you can avoid the repetition here

Suggested change

	<param-value>%s</param-value>
	</init-param>
	<init-param>
	<param-name>compilerTargetVM</param-name>
	<param-value>%s</param-value>
	</init-param>
	<load-on-startup>3</load-on-startup>
	</servlet>""", jspLevel, jspLevel));
	<param-value>%1$s</param-value>
	</init-param>
	<init-param>
	<param-name>compilerTargetVM</param-name>
	<param-value>%1$s</param-value>
	</init-param>
	<load-on-startup>3</load-on-startup>
	</servlet>""", jspLevel));

That said, it would be nice to explicitly escape this string just in case it is truly an arbitrary string

[zbynek]

Simple validation added instead of escaping.

[niloc132]

Does this mean that JSPs don't work any more in dev mode? Did they before this patch?

[zbynek]

Did they before this patch?

Yes, if you either stick with Java 1.7 syntax or provide your own web.xml.

JSPs don't work any more in dev mode

If you provide your own web.xml (setting Java level to 1.8 or higher), they should still work. Without it, they will fail.

I wasn't sure what we want (could we break something by creating web.xml for projects that don't need it?)

[niloc132]

Okay, so need a release note entry on this, that 1.7 won't work any more, and newer formats require an explicit web.xml entry.

[niloc132]

Going over the rest of GWT, I don't see actual emulation for these provided, so how does a normal compile have these (or not need them) while a test must get them from here?

I do see com.google.gwt.dev.javac.JdtCompiler.INameEnvironmentImpl#getLambdaMetafactoryBytes and friends, but nothing that provides MethodHandle or MethodHandles itself, nor StringConcatFactory. Does the newer JDT require these so we'll want general emulation for these, or maybe these were needed for an earlier iteration but no longer (e.g. to try to deal with emulating Record method before Objects was added)?