RFR: 8341551: Revisit jdk.internal.loader.URLClassPath.JarLoader after JEP 486 [v2]

Eirik Bjørsnøs eirbjo at openjdk.org
Wed Dec 4 16:54:40 UTC 2024


On Wed, 4 Dec 2024 16:46:14 GMT, Eirik Bjørsnøs <eirbjo at openjdk.org> wrote:

>> We're stuck with the property name for compatibility, and the usage within the class is fairly limited.
>> Generally, it is easier to understand the behavior having a feature that is enabled not a disable that is disabled.
>> $0.02
>
> Good :-)
> 
> If you end up keeping the `JAR_CHECKING_ENABLED` name, then introducing a local variable for the evaluation of the property may be useful. It should also fit better with the comment you introduced: 
> 
> 
> String p = props.getProperty("sun.misc.URLClassPath.disableJarChecking");
> // JAR check is disabled by default and will be enabled only if the "disable JAR check"
> // system property has been set to "false".
>  boolean jarCheckingDisabled = "false".equals(p);
> JAR_CHECKING_ENABLED = !jarCheckingDisabled;
> 
> 
> But in my opinion the above just makes it explicit that we flip a boolean here just to flip it back again on the use site.

> We're stuck with the property name for compatibility, and the usage within the class is fairly limited. Generally, it is easier to understand the behavior having a feature that is enabled not a disable that is disabled. $0.02

Yes, agree that if we could start afresh, it would be better to disable checking using "enableJarChecking=false".  And yes, that ship has sailed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22545#discussion_r1869932859


More information about the core-libs-dev mailing list