Interesting. Is this RFR a done deal?
While I like the concept and and understand the reasoning of URL not
having a public constructor, I think this may have been thought of in
isolation, I'm not sure how a custom URI, that strictly complies with
RFC 3986 will behave, if it must also be parse
On 27/10/2022 4:26 pm, Alan Bateman wrote:
On 26/10/2022 23:53, Peter Firmstone wrote:
The change will have some performance impact, by requiring redundant
parsing.
Just thought I'd mention it, in case it hasn't been thought of. If
you do an internet search there are other imple
I'm considering using one of the non parsing constructors, as Alan
points out we're currently double parsing. By the time the constructor
is removed, I'm guessing there will be a RFC3986 URI implementation in
the JDK, so we'll change to that when it happens. Or if you decide to
not deprecate
On 1/11/2022 5:52 pm, Alan Bateman wrote:
On Mon, 31 Oct 2022 22:00:01 GMT, Phil Race wrote:
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
e for
all implementations? Serialized form is a simple string, parsed during
deserialization, but how to distinguish, or does the provider order choose?
Regards,
Peter.
Sent from my iPhone
> On 12 Nov 2024, at 12:59 AM, Alan Bateman wrote:
> On 10/11/2024 12:04, Peter Firmstone wrote:
We've been using an RFC3986 URI implementation for over a decade, there
were issues we had to work around regarding formatting, so we provided
static methods to address them. Significant performance benefits can be
derived from strict normalization relating to identity.
Java doesn't implement
pening a file or making
a url connection.
--
Regards,
Peter
On 13/11/2024 7:13 am, Peter Firmstone wrote:
They are incompatible.
The existing URI implementation is backward compatible, but its use should be
discouraged in new applications, so use diminishes over time. It's unique
