On Fri, 20 Jun 2025 11:13:12 GMT, David Beaumont <d...@openjdk.org> wrote:
>> Simplifying JavaRuntimeURLConnection to avoid accidentally returning >> non-resource data to users. >> >> This change has the following distinct parts: >> 1. Refactor code to use Node instead of directly accessing low level >> ImageLocation type. >> 2. Remove unnecessary use of "Resource" interface and related URL generation >> code (completely unreachable). >> 3. Adding comments explaining why there's a non-obvious distinction in how >> module and resource names are treated with respect to URL percent encoding. >> 4. Small constructor logic simplification (module name cannot be null >> anymore) >> 5. Small simplification around 'READER' use, since it is impossible for that >> to ever be null (other users of ImageReaderFactory already assume it could >> never be null, and code path analysis agrees). >> 6. Adding tests for the non-resource cases. >> 7. Adding extra test data to check the behaviour with respect to things like >> percent escaping (previously untested). >> 8. Adding TODO comments for things I could do in this PR or later (reviewer >> opinions welcome). > > David Beaumont has updated the pull request incrementally with one additional > commit since the last revision: > > Feedback changes and renaming field to match nomenclature of JEP 220. Updated wrt to comments, but still a couple of outstanding questions: 1. InternalError vs MalformedURLException for "junk" input (raised by Roger) ? 2. Not 100% sure about Alan's comment (now outdated) "If the URL scheme from JEP 220 goes into the first comment then it will be clear that the resource is optionally." 3. Should I revert the explicit fast-path test until some non-default percent encoding logic is decided upon (raised by Roger) ? Other than that, I think I've covered everything. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25871#issuecomment-2996019859
