working around the deprecation of public URL constructors (JDK-8294241)

[Daniel Fuchs]

Hi Rick,

new URL("extinout/mybackup") throws a MalformedURLException too, so
I wouldn't expect new URI("extinout/mybackup").toURL() to work.

In that case I would recommend resolving the relative URI against
its absolute base before translating to URL.

My recommendation would be to use URL only at the point where
you call openConnection().


best regards,

-- daniel


On 15/12/2022 23:53, Rick Hillegas wrote:
> Thanks for the quick response, Alan. One comment inline...
> 
> On 12/15/22 12:24 PM, Alan Bateman wrote:
>> On 15/12/2022 19:14, Rick Hillegas wrote:
>>>
>>> I see many warnings when I build Apache Derby's code and javadoc with 
>>> Open JDK build 20-ea+27-2213. In particular, I see a number of 
>>> warnings introduced by the following change:
>>>
>>> - JDK-8294241: Deprecate URL public constructors
>>>
>>> I naively tried to fix these warnings by changing instances of
>>>
>>>    new URL(urlString)
>>>
>>>
>>> to
>>>
>>>    (new URI(urlString)).toURL() >>>
>>>
>>> Unfortunately, this breaks the Derby code. When I test Derby, I see 
>>> errors like the following:
>>>
>>> java.lang.IllegalArgumentException: URI is not absolute
>>>     at java.base/java.net.URL.of(URL.java:854)
>>>     at java.base/java.net.URI.toURL(URI.java:1144)
>>>     at 
>>> org.apache.derby.impl.store.raw.RawStore.backup(RawStore.java:641)
>>>
>>> Can you give me advice about the best way to workaround the 
>>> deprecation of the public URL constructors? I am looking for a 
>>> solution which handles relative URL strings.
>>>
>> URL::toURL is specified to throw if the URI is not absolute although 
>> the IAE may be a bit surprising as there isn't any arguments.
>>
>> Can you give an example of the "relative URL strings" so we can at 
>> least see which URI scheme this is.
> 
> This happens when urlString is a directory spec relative to the working 
> directory of the JVM. E.g.,
> 
>     extinout/mybackup