On Fri, 19 Apr 2024 13:19:44 GMT, Weijun Wang <wei...@openjdk.org> wrote:
> > > > Is it worth breaking such invalid URLs? > > I'm just not sure about the compatibility impact. The example > "file:///C:\some\path\extra.properties" you gave looks quite innocent and > could be generated by a casual script. > > Can this be separated from this PR? Yes, we can separate it from this PR and postpone it. We thought that this could have been an opportunity for enforcing a correct value for the property, clean the code and anticipate the removal of the URL constructor —something that will be inevitable at some point. It's true that some cases could have been affected —and that's why we listed the risk in the CSR and suggested a release note—, but the work to fix it wouldn't have been different than other compatibility-breaking changes that require a System property to be set for the previous behavior: add, or change in this case, an argument in the Java launcher. Anyways, are you okay with using the deprecated URL constructor to accept malformed URLs in the `java.security.properties` case? In these backward-compatibility scenarios, relative _includes_ won't be allowed: they will be handled as an include from an URL (like an http URL): we are not going to dig into the URL to find if there is a supporting local file as per discussed with @AlanBateman . ------------- PR Comment: https://git.openjdk.org/jdk/pull/16483#issuecomment-2066984182
