RFR: 8319332: Security properties files inclusion [v7]

[Martin Balao]

On Fri, 19 Apr 2024 13:02:03 GMT, Francisco Ferrari Bihurriet <fferrari at openjdk.org> wrote:

>>> In the compatibility risk description of the CSR:
>>> 
>>> > In line with the efforts to check invalid URLs (see [JDK-8294241](https://bugs.openjdk.org/browse/JDK-8294241): Deprecate URL public constructors), "java.security.properties" file-URL values such as "file:///C:\some\path\extra.properties" or "file:///some/path/extra .properties" need to be converted into their valid counterparts: "file:///C:/some/path/extra.properties" and "file:///some/path/extra%20.properties" respectively.
>>> 
>>> Is it worth breaking such invalid URLs?
>> 
>> I think that it is worth introducing this breaking change now, under a release note. Adjustments may be required to some Java launchers but the fix in itself should be straightforward. Those malformed URLs should have never been allowed and, with the deprecation and possible removal of the constructor that allowed them, it will be something to do at some point anyways. If we continue to support them, we would need to introduce code to handle includes different than `java.security.properties` or accept that the malformed URLs will spread to newly included files —and breaking changes will be worse in the future—.
>
> In reply to @martinuy's [response](https://github.com/openjdk/jdk/pull/16483#issuecomment-2066069129) to @wangweij:
>> [...]
>> > 
>> > Is it worth breaking such invalid URLs?
>> 
>> I think that it is worth introducing this breaking change now, under a release note. Adjustments may be required to some Java launchers but the fix in itself should be straightforward. Those malformed URLs should have never been allowed and, with the deprecation and possible removal of the constructor that allowed them, it will be something to do at some point anyways. If we continue to support them, we would need to introduce code to handle includes different than `java.security.properties` or accept that the malformed URLs will spread to newly included files —and breaking changes will be worse in the future—.
> 
> Let me also note that this has been already discussed in @AlanBateman's [initial review](https://github.com/openjdk/jdk/pull/16483#pullrequestreview-1711145372), where we decided to go with this breaking change to remove the dependency on `FileURLConnection` (which we had introduced for a fully backwards-compatible parsing).

If the platform's encoding does not support to create files with some special characters (e.g. '•'), we will need to skip the test. In any case, there shouldn't be a regression for these platforms and characters because they were never supported. I'll ask @franferrax to review and push this change tomorrow, along with the `java.security` documentation adjustment.

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

PR Comment: https://git.openjdk.org/jdk/pull/16483#issuecomment-2089148771