> On 25 Nov 2014, at 14:03, Mark Sheppard wrote:
>
> I think this raises a more fundamental question, as to why the URL
> hashCode() and equals() methods delegates to URLStreamHandler
> in the first place? rather than performing the processing within the URL
> class itself, and synchroniz
Peter, thanks a lot for the link and such a detailed explanation. I've been
working with URL/URLStreamHandler recently to make them "modularization ready"
and have noticed some of the problems you were talking about as well. I do
think we should make our best effort to fix it. Give me some time
Hi,
Some time ago I dived into the sinchronization pitfalls of URL /
URLStreamHandler and came up with a possible solution. Here's the thread
(mostly just my comments) and a patch:
http://mail.openjdk.java.net/pipermail/net-dev/2014-July/008592.html
Regards, Peter
On 11/25/2014 03:03 PM, Ma
Max, this change dates back to 99/06/11. And there's not much info left on it.
I suggest changing and running the full test suit.
P.S. I assume the whole synchronization burden in the URL comes from lazy
initialization of hostAddress and lazy computation of the hashCode (...and
access to shared
Hi Max,
I don't see any particular reason for this. Maybe it's just a "precaution". It
seems to me it's the only field
of the URL class set directly (without setter) from an outside.
Does it hurt performance a lot? In what cases?
-Pavel
> On 25 Nov 2014, at 12:02, Wang Weijun wrote:
>
> I am
On 25/11/2014 14:13, Wang Weijun wrote:
So, I would suggest a lock/compare-and-set for just the write to the previously
null URL.hostAddress, and locking based on the value of URL.getHost (don't
synchronise on String (that'd be a little like synchronising on URL!)!).
There's probably several
Hello,
well first of all, why is it doing a lookup at all? It the URL was
specified with a hostname I guess that one is used. If the InetAddress
object in the URL had no hostname, you probably do not want to reverse
resolve one for Security Manager purpose.
However, back to the synchronized: I do
> On Nov 25, 2014, at 20:55, Tom Hawtin wrote:
>
>
>
> On 25/11/2014 12:02, Wang Weijun wrote:
>> I am benchmarking security manager and notice this
>>
>> protected synchronized InetAddress getHostAddress(URL u) {
>> [...]
>>
>> Is there any reason why the method is synchronized? Why not sim
I think this raises a more fundamental question, as to why the URL
hashCode() and equals() methods delegates to URLStreamHandler
in the first place? rather than performing the processing within the URL
class itself, and synchronizing appropriately within.
If you call equals() and hasCode()
> On Nov 25, 2014, at 20:25, Pavel Rappo wrote:
>
> Hi Max,
>
> I don't see any particular reason for this. Maybe it's just a "precaution".
> It seems to me it's the only field
> of the URL class set directly (without setter) from an outside.
>
> Does it hurt performance a lot? In what cases?
On 25/11/2014 12:02, Wang Weijun wrote:
I am benchmarking security manager and notice this
protected synchronized InetAddress getHostAddress(URL u) {
[...]
Is there any reason why the method is synchronized? Why not simply "synchronized
(u)"?
Synchronizing on a public object is usually a b
I am benchmarking security manager and notice this
protected synchronized InetAddress getHostAddress(URL u) {
if (u.hostAddress != null)
return u.hostAddress;
String host = u.getHost();
if (host == null || host.equals("")) {
return null;
} else {
try {
12 matches
Mail list logo
