r
logic implemented before? What are the performance/code/semantic
changes you observed during migration? Did you encounter any problems?
Did you find the API intuitive? etc.
Kind regards.
On Wed, Jan 22, 2025 at 4:11 AM Peter Firmstone
wrote:
Just wanted to say, I've been exper
Just wanted to say, I've been experimenting with replacing ThreadLocal
with ScopedValue, this is a great new API, I love the way ScopedValue
uses recursion, we can have multiple immutable instances representing a
scoped value for a short period and we're not worried about managing
state as it g
If you don't wish to use version numbers, why not generate a SHA256 hash
of each module instead?
--
Regards,
Peter
On 17/12/2024 1:34 pm, Ethan McCue wrote:
That might be useful, but it is not closer to what I am looking for.
I am treating it as a constraint that the repository be able to
path = path.replace(File.separatorChar, '/');
}
path = fixWindowsURI("file:" + path);
return Uri.escapeAndCreate(path); //$NON-NLS-1$
}
--
Regards,
Peter
On 10/11/2024 5:05 pm, Peter Firmstone wrote:
So we have an RFC3986 compliant URI implemen
So we have an RFC3986 compliant URI implementation, that's not
compatible with Java's RFC2396 URI and now we use deprecated URL public
constructors...
But I guess they're only deprecated, not going to be removed, we can't
change our code to use RFC2396 URI without unintended consequences...
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
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 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
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
