[FEATURE]: #2140: Add ArenaInfoPanel

[sgcr]

1. changes proposed in this pull request:

   • fixes issue [FEATURE] Arena sizer: Add the general information about the current stadium #2140

2. src/main/resources/release_notes.md ...

• has been updated

3. [Optional] suggested person to review this PR @___

[tychobrailleur]

Probably a bit late to the party, but I am not super keen on adding a dependency to lombok in HO. Could this be turned into Java records, or better still use Kotlin? We have been trying to move to Kotlin in recent times, and the language would naturally offer those facilities.

Generally speaking we are trying to keep new dependencies to a minimum, to keep HO size in check, but also because it's proved difficult to maintain over the years.

[sgcr]

Hi :-)

I see. ;-)

I am not familiar with Kotlin but with Java and Lombok.

The question is how to make to code better maintainable and understandable in general.

One thing is that whenever I see a getter and setter that is the standard implementation it may be annotated with the annotations @Getter and @Setter from Lombok.
This makes the code easy to read and prevents superfluous code.

I see the use of Lombok in that case as a step in between to the shift to Kotlin.
It makes it clear that the getter and setter can be moved to Kotlin easily and in the time between and it reduces superfluous code to read and maintain while making it not necessary to move everything to Kotlin in one step.

Beside that there are 42 files in Kotlin and 888 in Java.
So Kotlin is only 4,5% of the files (not lines).
When do you think is the move to Kotlin finished? Is that a long term goal?

Does the size of the library really matters?

I have to think about it...

[tychobrailleur]

This is probably a very subjective matter, I do not think getters and setters are that much of a readability issue vs annotations. It is a tradeoff, and between adding a new dependency and living with boilerplate code, my preference goes to the latter. This is mostly due to issues we've previously had with third-party dependencies maintenance. In any case Java records are a good Java alternative for the same problem, I think. And they come with yummy immutability. ;-)

On the Kotlin question, we have tried to implement new features using Kotlin to make that transition more progressive. I had started the big bang approach of converting the code to Kotlin, but @wsbrenk suggested that we should add unit tests as part of the migration, which obviously made things more difficult: as you probably noticed, testability is a major pain point in HO, due to these massive singletons that are everywhere. This is something I had started to look into, but never really had the time to address further...

[tychobrailleur]

(BTW, I meant to say, IntelliJ is your friend for both Lombok -- converting back and forth between annotations and accessors -- and Kotlin from and to Java)

[wsbrenk]

I don't dare to decide this here because I'm neither our biggest java nor kotlin expert. However, I like Sébastien's suggestion to port to kotlin, because I can imagine that it could be possible to support androids in the medium term.

[wsbrenk]

Hi @sgcr, very good job.

[wsbrenk]

For me it is fine now - I don't want to decide about lombok or not...

[sgcr]

For me it is fine now - I don't want to decide about lombok or not...

Good :)

See also my comment regarding Java records with the last commit.

The pull requests: #2145 and #2143 should be reviewed and merged first because they are partly included here but separate general things.

I would like to rebase this PR here then.
#2145 is clearly a bug.
#2143 seems to be good idea due to testing.

[tychobrailleur]

I would like to rebase this PR here then. #2145 is clearly a bug. #2143 seems to be good idea due to testing.

Makes sense!

I had a quick glance at it this morning, at a high level, this looks like a good change, I just need to do the full code review this weekend.

[sgcr]

Can be merged.