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

[Chris Hegarty]

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
>> 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.

I do have a little discomfort about this change, since the toURL spec
specifically says it is "equivalent to evaluating the expression new 
URL(this.toString())". I wonder if your tests should cover this too,
i.e. the resulting URLs from toURL and URL(this.toString()) are equal?

-Chris.