Can't find the design / programming idiom behind a intuitively good practice : give your object construction a deterministic period

Question

Here is my problem. I want to document a piece of program and want to express something, I believed quite common among the programming community, but can't hack the idea into a word. Take a look at this class :

public class RemoteClient {
    private InetSocketAddress remoteAddress;
    /*+ some other fields not in the scope of this topic*/

    public RemoteClient(String hostName, int port
    /*+ some other arguments not in the scope of this topic*/){
       this.remoteAddress=new InetSocketAddress(hostName, port);
    }

    public InetSocketAddress getRemoteAddress() {
        return this.remoteAddress;
    } 

}

The obvious problem in a multithreaded environment is that the caller of the constructor has no guaranty that hostName will be resolved, and therefore build time is not deterministic. It would be, I believe, much better if the construction of InetSocketAddress was lazy, such as follow :

public class RemoteClient {
    private volatile InetSocketAddress remoteAddress; 
    private final String hostName;
    private final int port; 
    /*+ some other fields not in the scope of this topic*/

    public RemoteClient(String hostName, int port
    /*+ some other arguments not in the scope of this topic*/){
       this.hostName=hostName;
       this.port=port;
    }

    /** lazy instanciation **/
    public InetSocketAddress getRemoteAddress() {
        if(remoteAddress==null){
            synchronized(hostName){
                if(remoteAddress==null){
                    this.remoteAddress=new InetSocketAddress(hostName, port);
                }
            } 
        }
        return this.remoteAddress;
    } 

}

So in this case, the Thread calling the constructor operator, which might at some time build from a list of host names, has no more network-related indetermination. It is now delegated to the Thread in charge of communication with the remote client.

My questions are :

• can you give reasons why the second proposition is/isn't better designed?
• could you put a word on the idiom behind this practice ?

I believe this is not a opinion-based topic, as I'm asking for a design.

Answer 1

The obvious problem in a multithreaded environment is that the caller of the constructor has no guaranty that hostName will be resolved, and therefore build time is not deterministic.

I don't see that. I don't see why this is an 'obvious problem in a multi-threaded environment', and I don't see why 'non-deterministic construction time' is a problem in any particular environment at all. If construction time is a problem, it is a problem in any environment. If what you're looking for is a shorter DNS timeout, there are ways to enforce that: see the Networking Properties page in the Javadoc.

It would be, I believe, much better if the construction of InetSocketAddress was lazy.

In that case all you need is InetSocketAddress.createUnresolved().

Answer 2

The simple, "do it at constructor time method" that you dislike has a couple of big advantages:

1. remoteAddress can be final and more thread-safe, e.g. leaky constructors. And it avoids all the double locking crap for simplicity. (BTW, unless you are calling getRemoteAddress() a gazillion times, just synchronize your lazy call.)
2. If caller gives an invalid port, it will fail fast (throw an IllegalArgumentException) in the constructor which is likely a better place to handle the error. The lazy version of getRemoteAddress() will fail much later with an IllegalArgumentExceptionin a method that has no arguments, which is very confusing. Plus by then it is probably too late to take any corrective action (like popping back up to the UI level to ask again in a dialog).

For the record, I agree with EJP that a non-deterministic speed constructor is unlikely to be a problem anyway.

Answer 3

You don't need to use synchronized in this case with a volatile. The volatile does all the work for you. C.f. the Java Language Spec:

A write to a volatile variable v (§8.3.1.4) synchronizes-with all subsequent reads of v by any thread (where "subsequent" is defined according to the synchronization order).

And this StackOverflow answer on Safe Publication.

public class RemoteClient {
    private volatile InetSocketAddress remoteAddress; 
    private final String hostName;
    private final int port; 
    /*+ some other fields not in the scope of this topic*/

    public RemoteClient(String hostName, int port
    /*+ some other arguments not in the scope of this topic*/){
       this.hostName=hostName;
       this.port=port;
    }

    /** lazy instanciation **/
    public InetSocketAddress getRemoteAddress() {
       if(remoteAddress==null){
          this.remoteAddress=new InetSocketAddress(hostName, port);
       }
       return this.remoteAddress;
    } 

}