When to use Long vs long in java?

Question

Below is my Interface -

public interface IDBClient {     public String read(ClientInput input); } 

This is my Implementation of the Interface -

public class DatabaseClient implements IDBClient {      @Override     public String read(ClientInput input) {      } } 

Now I have a factory which gets the instance of DatabaseClient like this -

IDBClient client = DatabaseClientFactory.getInstance(); .... 

Now I need to make a call to read method of my DatabaseClient which accepts the ClientInput parameter and below is the class for the same. This class was not written by me so that is the reason I am having a question on this and I am pretty much sure this is the wrong way of doing it.

public final class ClientInput {      private Long userid;     private Long clientid;     private Long timeout_ms = 20L;     private boolean debug;     private Map<String, String> parameterMap;      public ClientInput(Long userid, Long clientid, Map<String, String> parameterMap, Long timeout_ms, boolean debug) {         this.userid = userid;         this.clientid = clientid;         this.parameterMap = parameterMap;         this.timeout_ms = timeout_ms;         this.debug = debug;     } }     

So when customer make a call to read method of DatabaseClient, they will create the ClientInput parameter like this and then use the factory to get the Instance of DatabaseClient and then call the read method accordingly.

Map<String, String> paramMap = new HashMap<String, String>(); paramMap.put("attribute", "segmentation");  ClientInput input = new ClientInput(109739281L, 20L, paramMap, 1000L, true);  IDBClient client = DatabaseClientFactory.getInstance(); client.read(input); 

Problem Statement:-

1. So my first question is does the userid, clientid, timeout_ms should be Long object or just simply long in ClientInput class?
2. Second question I have is, it might be possible that customer can pass wrong information such as negative user ids, negative client id, negative timeout value etc etc.. Then where I should do this validation? Should I do this validation check in the constructor of ClientInput class or at some other place? What's the better way of doing this and how should I do the validation?

Answer 1

long is a primitive, which must have a value. Simple.

Long is an object, so:

• it can be null (meaning whatever you like, but "unknown" is a common interpretation)
• it can be passed to a method that accepts an Object, Number, Long or long parameter (the last one thanks to auto-unboxing)
• it can be used an a generic parameter type, ie List<Long> is OK, but List<long> is not OK
• it can be serialized/deserialized via the java serialization mechanism

Always use the simplest thing that works, so if you need any of the features of Long, use Long otherwise use long. The overhead of a Long is surprisingly small, but it is there.

Answer 2

I don't think there's a single correct answer. A few suggestions:

• The biggest difference I see between long and Long in this context is that Long may be null. If there's a possibility you might have missing values, the Long object will be helpful as null can indicate missing values. If you're using primitives, you'll have to use some special value to indicate missing, which is probably going to be a mess. Speed or size is not likely to be an issue unless you're planning on making an array of a million of these things and then serializing.

• My preference for validation logic is to throw some sort of custom ValidationException at the point at which the thing could fail. If you're just creating these things with a constructor, the simplest thing would be just to validate there, e.g.

   public ClientInput(Long userid, Long clientid, Map<String, String> parameterMap, Long timeout_ms, boolean debug) throws ValidationException {                  if (userid == null) throw new ValidationException("UserId is required");              ...etc, etc... } 

Ultimately, the ValidationException is only useful if you can catch it at a point where you can do something useful with it - echo it back to a user or whatever.