Ported LFValidator.xtend to Java

[housengw]

see #838

[lhstrh]

The validator is a very important class, and it will be difficult to assure the ported code is functionally correct. I would suggest that before merging this in, we improve code coverage of LFValidator with unit tests.

[lhstrh]

@housengw could you incorporate the following changes in your port please?
https://github.com/lf-lang/lingua-franca/pull/804/files
In your commit message, please reference PR #804 so that is shows up in the conversation of that PR.
Once this has been done, I will close #804.

[lhstrh]

The dummy Xtend file shouldn't be needed if you set generateXtendStub = true to generateXtendStub = false in org.lflang/src/org/lflang/GenerateLinguaFranca.mwe2

[cmnrd]

This looks great! Due to the size of the Validator, it's not possible to check every line, but I made a quick read through. One issue that I noticed, is that the checkWidthSpec method disappeared in the Java version.

Also, when opening the java file in IDEA, there is a ton of warnings reported. Many of which suggest code improvements. This is not to say that your code is bad, but more to say that we need to think about our developer setups and what are the recommended tools for working with our code base should be. Luckily, when we don't rely on xtend anymore, we have more options then eclipse :)

[Soroosh129]

Looks great!

I wonder if we should delay the task of porting Xtend files that can heavily benefit from Java 17's multi-line strings until after we make the jump (which might happen soon). It seems like leaving separate (untested) Java 17 code blocks as comment will just lead to a lot of duplicate work down the line.

Edit: As @lhstrh mentioned here, we might not get to use Java 17 anytime soon. Looking at Xtext's past release cycles, the next next release could be at least 4 months away. So I see the reasoning behind doing this now.

[cmnrd]

I think eventually we will anyway need to do another pass over the core classes. There are lots of opportunities for designing the validator in a cleaner and more modular way. In such a go we could also modernize the Java code or, if we don't need to rely on Eclipse for development anymore (which should be the case once we have thrown out all xtend), we could also port the class entirely to Kotlin. With IntelliJ's tools for auto-conversion and code linting, this should be a walk in the park compared to the transition from xtend to java ;)

[lhstrh]

Adding a link to my comment in #873.

[lhstrh]

I think we should merge this after tagging 0.1.0-beta.