RFR: 8373885: Compilation failure due to a warning when compiling with Java 25

[Kevin Rushforth]

On Wed, 17 Dec 2025 20:36:23 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> When compiling JavaFX with Java 25, a new warning appears. This warning will result in a compilation failure because warnings are treated as error (`-Werror`).
>> 
>> The following warning appears:
>> 
>> 
>>> Task :controls:compileJava
>> C:..\jfx\modules\javafx.controls\src\main\java\javafx\scene\control\SplitPane.java:320: warning: [identity] use of a value-based class with an operation that expects reliable identity
>>     private final WeakHashMap<Integer, Double> dividerCache = new WeakHashMap<>();
>>                                                                              ^
>> C:..\jfx\modules\javafx.controls\src\main\java\javafx\scene\control\SplitPane.java:320: warning: [identity] use of a value-based class with an operation that expects reliable identity
>>     private final WeakHashMap<Integer, Double> dividerCache = new WeakHashMap<>();
>>                              ^
>> error: warnings found and -Werror specified
>> 1 error
>> 2 warnings
>> 
>>> Task :controls:compileJava FAILED
>> 
>> 
>> The warning makes sense: We use a `WeakHashMap` with the `Integer` class. So the `Integer` values are saved as `WeakRef` inside the `Map`. This makes no sense and is rightfully a warning.
>
> $.02, From the Valhalla point of view.
> As above, there is no reason for the WeakHashMap.  The object being cached is small so memory reclamation is not the goal.  The keys are small integers, currently cached so always exist, so never freed and nothing is reclaimed.
> Its not clear why a map is used either but maybe thought to be an easier APIs to manage the set.
> The simple switch to another Map implementation should be very low risk.
> Regards, Roger

@RogerRiggs Thanks for the confirmation.

Let's continue with this PR then. We can explore removing the divider cache in a follow-up.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/2010#issuecomment-3667140995