>
> I suspect some refactoring is needed as some of this code in ParseUtil
> is not general purpose and should probably move to the jar URL handler.
> A discussion for net-dev when there is a patch to discuss.
>
https://github.com/openjdk/jdk/pull/2167
This moves the utility methods into Handler
On 2021-01-20 13:02, Alan Bateman wrote:
On 20/01/2021 11:57, Claes Redestad wrote:
Hi,
looks reasonable. I'll file an RFE.
- canonize -> canonicalize seem like an appropriate change of terms :-)
- the bangSlash parameter could perhaps be better named from, since
bangSlash is not a concept
On 20/01/2021 11:57, Claes Redestad wrote:
Hi,
looks reasonable. I'll file an RFE.
- canonize -> canonicalize seem like an appropriate change of terms :-)
- the bangSlash parameter could perhaps be better named from, since
bangSlash is not a concept known to ParseUtil. Or move the util
metho
Hi,
looks reasonable. I'll file an RFE.
- canonize -> canonicalize seem like an appropriate change of terms :-)
- the bangSlash parameter could perhaps be better named from, since
bangSlash is not a concept known to ParseUtil. Or move the util methods
to the Handler, since it's the only calle
>
>
> By letting canonizeString do the substring calls, but only when it
> determines that it is needed, we can remove some unnecessary String and
> byte[] allocations.
>
While English is not my mother tongue, I'm thinking we could maybe let the
Vatican deal with canonizations and rename this to t
Hello,
sun.net.www.protocol.jar.Handler.parseURL unconditionally calls
String.substring twice on the spec string, even when
ParseUtil.canonizeString later determines that no canonization was required.
By letting canonizeString do the substring calls, but only when it
determines that it is needed,
