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 {
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 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?
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
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()
This test has been failing intermittently since I updated it recently to cover
another similar issue. The test shares a ServerSocket instance across two
threads, and as such it should be a volatile field. The test should also ensure
that any thread that it starts completes before it continues it
Hi Chris,
These changes look reasonable to me.
best regards,
-- daniel
On 25/11/14 16:45, Chris Hegarty wrote:
This test has been failing intermittently since I updated it recently to cover
another similar issue. The test shares a ServerSocket instance across two
threads, and as such it sho
