gwt-plugins / gwt-eclipse-plugin

GWT Eclipse Plugin Documentation
http://gwt-plugins.github.io/documentation/
Eclipse Public License 1.0
114 stars 47 forks source link

Compatibility with m2e 1.x - 2.x #451

Open protoism opened 1 year ago

protoism commented 1 year ago

Added M2e 1.x support, required for Eclipse 2022-06

Fixes #450

niloc132 commented 1 year ago

Build failed - if I'm reading this right, your pre-built jar was built with --release 17, and while this plugin is built with java 17, it is built with --release 11 so that it can be used with java 11.

protoism commented 1 year ago

Yes, I've seen the build failure. The problem is tricky, and I really don't know how to fix it. The point is that m2e is using records, and this is probably the reason why we need jdk 17 to build.

Technically speaking;

We have a class WtpMavenProjectConfigurator, derived from WTPProjectConfigurator, which overrides this method:

  public void configure(ProjectConfigurationRequest request, IProgressMonitor monitor) throws CoreException

but ProjectConfigurationRequest is a record in m2e

As long as we use methods of this record, such as mavenProject(), everything is fine, but as soon as we try to use reflection, or even invoke getClass() the compiler complains because it says that we're referring java.lang.Record

There is no real reason why the compilation must fail: WtpMavenProjectConfigurator does not need to know anything about records, and working bytecode could be generated. Proof is that the main branch is happily consuming this record and the generated bytecode does not containing anything record-related.

So, I'd say that this compilation failure is more of a (very reasonable) sanity check: the compiler tells that this thing won't work on JDK11, because java.lang.Record won't be there. Why this sanity check is not performed when we simply invoke a record method is beyond me.

I can't think of a clean and simple way to handle this problem... I did not find any workaround. The only solution seems to be the one proposed by @keinhaar

protoism commented 1 year ago

Not that I really understand why, but using generics fixed the compilation issue.

Tested on 2022-06 and 2022-12

Does anyone want to do more testing?