Codecov Report

Merging #22 into master will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master      #22   +/-   ##
=========================================
  Coverage     79.24%   79.24%           
  Complexity      756      756           
=========================================
  Files            10       10           
  Lines          1609     1609           
  Branches         40       40           
=========================================
  Hits           1275     1275           
  Misses          307      307           
  Partials         27       27

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 6598d5c...1724377. Read the comment docs.

Hi! Thanks for the contribution!

When I run mvn --version in the Gitpod workspace, I get this:

gitpod /workspace/procrastination $ mvn --version
Picked up JAVA_TOOL_OPTIONS: -Xmx3543m
Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555; 2019-04-04T19:00:29Z)
Maven home: /home/gitpod/.sdkman/candidates/maven/current
Java version: 1.8.0_202, vendor: Azul Systems, Inc., runtime: /home/gitpod/.sdkman/candidates/java/8.0.202-zulufx/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "4.15.0-1028-gcp", arch: "amd64", family: "unix"

So it looks like it's trying to use Java 8 when you run mvn verify, which would explain why that fails.

I'm not sure what to do about the type inference problem. I'm using IntelliJ, which handles it fine. But I do see issues when I try to open the project in VS Code. Is it possible that Gitpod won't be usable for this project until the Java Language Server is more advanced?

Oh, interesting that mvn runs the wrong version. We'll investigate.

Is it possible that Gitpod won't be usable for this project until the Java Language Server is more advanced?

If this really is a shortcoming of the Java LS. I saw the same issue when testing in Eclipse.

If this really is a shortcoming of the Java LS. I saw the same issue when testing in Eclipse.

The Red Hat Java language support VS Code extension uses the same language server that Eclipse uses, right? And that's the VS Code extension that Gitpod uses for Java?

Yes, Eclipse, VS Code and Gitpod are all running JDT-LS. I have asked on the JDT forum:
https://www.eclipse.org/forums/index.php/m/1808350/#msg_1808350

Oh, interesting that mvn runs the wrong version. We'll investigate.

Any update on this part?

Sorry, for the delay. I just tried again and the output looks good:

gitpod /workspace/procrastination $ mvn --version
Picked up JAVA_TOOL_OPTIONS: -Xmx3543m
Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555; 2019-04-04T19:00:29Z)
Maven home: /home/gitpod/.sdkman/candidates/maven/current
Java version: 11.0.2, vendor: Azul Systems, Inc., runtime: /home/gitpod/.sdkman/candidates/java/11.0.2-zulufx
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "4.15.0-1028-gcp", arch: "amd64", family: "unix"

But the type checking issues remain :-(

But the type checking issues remain :-(

I'm not very happy that Stephan expects us to become experts on JLS type inference before he'll investigate a possible defect on his end. That sounds a bit too daunting for me at the moment, so I'm gonna close this pull request for now. But I appreciate your efforts, and I do still want people to be able to use Gitpod with this project eventually. So I will periodically revisit this to see if the JDT language server has improved in this regard. If and when that happens, I'll reopen this.