[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-2d-dev
Subject:    Re: RFR: 8294241: Deprecate URL public constructors [v2]
From:       Phil Race <prr () openjdk ! org>
Date:       2022-10-31 21:56:13
Message-ID: 0rHERDXBBHvhqRnD-dUoCIUlF7VXmcsY4MYdqjNHIWk=.8b00964e-0dc1-470f-8745-3fcf844d4684 () github ! com
[Download RAW message or body]

On Fri, 28 Oct 2022 14:54:26 GMT, Daniel Fuchs <dfuchs@openjdk.org> wrote:

> > Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to \
> > parse or construct any URL. 
> > The `java.net.URL` class does not itself encode or decode any URL components \
> > according to the escaping mechanism defined in RFC2396. It is the responsibility \
> > of the caller to encode any fields, which need to be escaped prior to calling \
> > URL, and also to decode any escaped fields, that are returned from URL.  
> > This has lead to many issues in the past.  Indeed, if used improperly, there is \
> > no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL \
> > string that can be parsed back into the same URL. This can lead to constructing \
> > misleading URLs. Another issue is with `equals()` and `hashCode()` which may have \
> > to perform a lookup, and do not take encoding/escaping into account. 
> > In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of \
> > the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI \
> > were also added. However, it was left up to the developers to use `java.net.URI`, \
> > or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, \
> > in order to provide a stronger warning about their potential misuses. To \
> > construct a URL, using `URI::toURL` should be preferred. 
> > In order to provide an alternative to the constructors that take a stream handler \
> > as parameter, a new factory method `URL::fromURI(java.net.URI, \
> > java.net.URLStreamHandler)` is provided as  part of this change. 
> > Places in the JDK code base that were constructing `java.net.URL` have been \
> > temporarily annotated with `@SuppressWarnings("deprecation")`.  Some related \
> > issues will be logged to revisit the calling code. 
> > The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949
> 
> Daniel Fuchs has updated the pull request with a new target base due to a merge or \
> a rebase. The incremental webrev excludes the unrelated changes brought in by the \
> merge/rebase. The pull request contains four additional commits since the last \
> revision: 
> - Updated after review comments. In particular var tmp => var => _unused - and \
>                 avoid var in java.xml
> - Merge branch 'master' into deprecate-url-ctor-8294241
> - Fix whitespace issues
> - 8294241

Deprecate URL constructors.
Developers are encouraged to use java.net.URI to parse or construct any URL.
...
To construct a URL, using URI::toURL should be preferred.

You have jumped through some refactoring hoops to be able to apply the deprecation \
suppression to as little code as possible .. having made such changes, then why \
didn't you just make the recommended change instead ?

Should I presume that the recommended route will have some nasty little \
incompatibilities we will need to be careful of first ?

And what about Peter Firmstone's comment
"We stopped using java.net.URI some years ago as it's obsolete.?"

I can't reconcile that with the recommendation to use it ..

-------------

PR: https://git.openjdk.org/jdk/pull/10874


[prev in list] [next in list] [prev in thread] [next in thread]