Java code upgrade

[IgorBabalich]

Description

Currently, the Netbeans code declared as Java17 based, but the source code has many previous java version's code on the place.

Use case/motivation

To keep Netbeans project in the modern development line edge, it would be great to refactor the code by replacing the old java version code to the new one. By doing that, the project code will be more safe and less verbose.

Related issues

No response

Are you willing to submit a pull request?

Yes

[mbien]

Code quality improvements are welcome to some extend. They do have to be balanced with code review workloads. Automatic refactoring of 450 modules is quickly done, validation for correctness and/or possible side effects is not - someone will have to look through the patch which usually is significantly more time intensive than the actual refactoring.

So don't be surprised if a PR might not find a reviewer. But it will very much depend on what you are actually planning to do.

converting this issue to a discussion

[mbien]

new Integer(int) -> int would be something worth doing I agree since those constructors will be removed at some point. This effort was already started e.g #3890, #7864. (but even this change is not as trivial as it may appear)

[matthiasblaesing]

I can offer only my personal POV, so others might more enthusiastic: I would not review PR that just beautify code. The balance between potential damages and gains almost always tips into the damages range.

Problems can be subtle. The change new Integer(int) -> int looks trivial, but potentially introduces an issue if identity of the object becomes relevant (Locking, IdentityMap).

Another problem is polution of history. NB still suffers from the reorganisation of the source tree into the clusters, just because the github UI does not cope with last change.

And of course: each change risks introducing random issues, just because typos or similar things are introduced.

[IgorBabalich]

Agree, if there would be just such one change then the upgrade would be questionable.
Though expecting the many small steps with systematic code cleaning will improve the quality of the code and the project as a whole,
keeping the project on the modern development edge.

[IgorBabalich]

As the related work for Float was already performed, then would be great to complete the work for other types.
Definitely I am not going to just formally find/replace, but accurately review all changes. So, the risk is minimal.
If there will be related issue then I will take care of it.

[mbien]

sounds good to me. All primitive wrapper constructor calls have to go since they are deprecated for removal. We don't have to wait till last minute there ;)