The core is no longer checking the value of requiredJavaVersion that's stored in skin.properties, so it's not serving any purpose. Stale values that are still there are just misleading - what really matters is the version of jAlbum that's required, which implies the Java version that's available in the bundle. A skin developer shouldn't be compiling things like the UI to any higher version of Java (and at present, should probably be sticking to Java 14 as the source/binary).
The field also needs to be removed from the skin properties editor (ALT-S). Invoking the editor and saving the file results in a saved value of 1.5.
The skin properties editor could use some refreshing (missing fields), but since a user should never be tinkering with those settings, further refinement is a very low priority. I use it only to bump the last modified date. For anything else, I just open it in a text editor.
The skin properties editor should sort the file entries automatically (just as .jap file entries are now sorted). If I open one of those files in a text editor, I have to go hunting for things. If I sort the entries, but then later use the editor to bump the modified date, for example, the entries are once again unsorted, which is irritating.
Ideally, the skin properties editor should include all of the available fields, listed here:
But in addition to REQUIRED_JAVA_VERSION, which is no longer used, it's also time to retire TRUE_ORIGINAL_PATH, also obsolete. And is there any current skin that's using the COMPATIBILITY_MODE flag? Maybe leave it in the core to accommodate ancient skins, but no need for it in the skin properties editor.
Sorting the lines is high on my list. The rest of it is much less important, since I'm often just modifying the properties files in a text editor anyway.
Did a quick check, and no current skin is using compatibility mode. Given how old it is (jAlbum 10.3 was released in January, 2012, and that's the version that triggered the need for it), that could probably be stripped out of the core entirely. It probably falls into the category of "unreachable code."