RFR: 8147462: URI.toURL could be more efficient for most non-opaque URIs

[Alan Bateman]

On 18/01/2016 19:26, Chris Hegarty wrote:
>
>> On 18 Jan 2016, at 16:20, Claes Redestad <claes.redestad at oracle.com 
>> <mailto:claes.redestad at oracle.com>> wrote:
>>
>> On 2016-01-18 15:34, Chris Hegarty wrote:
>>> On 18/01/16 14:09, Alan Bateman wrote:
>>>>
>>>> On 17/01/2016 15:30, Claes Redestad wrote:
>>>>> Hi,
>>>>>
>>>>> please review this patch which might make URI.toURL more efficient
>>>>>
>>>>> Webrev: http://cr.openjdk.java.net/~redestad/8147462 
>>>>> <http://cr.openjdk.java.net/%7Eredestad/8147462>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8147462
>>>>>
>>>>> This patch exploits the fact that URI will apply the same validation
>>>>> to the URI/URL specification for any valid non-opaque URL, thus it's
>>>>> safe to use the component-based URL constructor. Also, URIs
>>>>> representing malformed URLs will throw an exception as specified both
>>>>> before and after. A number of simple test cases to capture and
>>>>> document this was added to the existing java/net/URI/URItoURL 
>>>>> jtreg test.
>>>> I think the change to URI looks okay but it would be good to include a
>>>> brief comment as otherwise it will be difficult for future maintainers
>>>> to understand.
>>>
>>> +1.  For a long time we have been suggesting that anyone requiring
>>> a URL should retrieve it from URI::toURL, so it is good to have a
>>> fast(er) common path.
>>>
>>> The handling of a null/empty host is a little esoteric, so a comment
>>> would be good.
>>
>> How about this?
>>
>> http://cr.openjdk.java.net/~redestad/8147462/webrev.02 
>> <http://cr.openjdk.java.net/%7Eredestad/8147462/webrev.02>
>
> Looks good Claes.
>
This looks okay to me too.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20160118/35da53ce/attachment.html>