Replace Guava's ImmutableMap in XtextAntlrGeneratorFragment2

[HannesWell]

All the changes are internal respectively just affects the internals of generated code.

Part of #2975

[LorenzoBettini]

I'd call the parameter map now

[HannesWell]

I left it as it is since the passed map is still some kind of a 'builder' since it is just used to build the final immutable copy. And it required less charges.
But if you prefer just map, I'll change that.

[LorenzoBettini]

@HannesWell I see your point, but builder sounds strange to me; let's wait for @szarnekow 's review anyway.

[HannesWell]

Understand. What about naming it according to its content? So just mappings?
In general repeating the type in the variable name is often superfluous from a Clean-Code point of view.

[LorenzoBettini]

mappings sounds fine to me

[HannesWell]

@szarnekow are you fine as well with mappings?

[szarnekow]

Yes, that’s a good fit

[LorenzoBettini]

To be sure it doesn't break anything, shouldn't we regenerate all the languages with this change?

[cdietrich]

yes but this is tedious work as many workflows dont work and we need to fiddle a lot with mwe deps to get them running

[LorenzoBettini]

Actually, I fixed the workflows when I regenerated the test languages.

In any case, what I meant is that we must make sure this PR doesn't break the semantics

[cdietrich]

@LorenzoBettini the workflows work but won’t start cause mwe launch and maybe others missing
Last time I regenerated I added it. Regenerated and removed agin

[LorenzoBettini]

@cdietrich which ones? The one of test languages works because I'm using it for other branches. Also the one of common types works IIRC. In that case it's a java launch, not a mwe2 launch. Same for xbase and xtend, they're java applications.

[cdietrich]

@LorenzoBettini at least the following are not working

org.eclipse.xtext.builder.standalone.tests/src/org/eclipse/xtext/builder/tests/GenerateBuilderTestLanguages.mwe2
org.eclipse.xtext.extras.tests/src/org/eclipse/xtext/GenerateAllTestLanguages.mwe2
org.eclipse.xtext.web.example.entities/src/org/eclipse/xtext/web/example/entities/GenerateEntities.mwe2
org.eclipse.xtext.web.example.statemachine/src/org/eclipse/xtext/web/example/statemachine/GenerateStatemachine.mwe2

(Am not sure if i managed to run all)

[LorenzoBettini]

@HannesWell now that #2998 is fixed, you should be able to re-generate the languages and see if the build is still green. Maybe, however, it's better to wait for @szarnekow 's review before doing the re-generation of the languages.

[HannesWell]

@HannesWell now that #2998 is fixed, you should be able to re-generate the languages and see if the build is still green. Maybe, however, it's better to wait for @szarnekow 's review before doing the re-generation of the languages.

Thanks for fixing that. So should I simply import all languages into a secondard Eclipse that already contains this change and just re-run all workflows once we are fine with the change itself?

[LorenzoBettini]

Thanks for fixing that. So should I simply import all languages into a secondard Eclipse that already contains this change and just re-run all workflows once we are fine with the change itself?

@HannesWell, there's no need to do that in a secondary Eclipse: the mwe2 workflow uses the classes from the current workspace's classpath, where you already have the new fragments.

[HannesWell]

@HannesWell now that #2998 is fixed, you should be able to re-generate the languages and see if the build is still green. Maybe, however, it's better to wait for @szarnekow 's review before doing the re-generation of the languages.

Since we all agreed on the new variable name above and there where no other objectsion I rerun all worksflows and added the re-generated Parser implementations in a second commit to this PR.

Please let me know if there is anything that should be changed.

[HannesWell]

In the failing test dummyParser.getRuleName(null); is called for which the implementation returned by Map.copyOf() throws an NPE. Is this a relevant use-case? If yes the generated code has to be adapted to guard null arguments.

[HannesWell]

Alternatively the HashMap could only be wrapped into a Collections.unmodifiableMap() instead of using Map.copyOf().

[szarnekow]

Alternatively the HashMap could only be wrapped into a Collections.unmodifiableMap() instead of using Map.copyOf().

That would be my preference