Solution 1:

Integer is a better option, as it can handle null; for int, null would become 0, silently, if resultSet.getInt(..) is used. Otherwise, it might throw some exception, something like, "Unable to set null to a primitive property".

Performance is of little concern here.

  • if you choose int, you will end-up adding extra handling code; and that wouldn't benefit you much. Your code will not be clean and straight-forward, lot of boiler-plate code, and you wouldn't even gain performance.
  • let me make it clear, for databases, null is not same as zero. Sometimes you end-up entering 0, where null was intended. Imagine the case where user submitted a form, and doesn't supply any value for int. You will end up getting 0 by default. It makes sense, or does that really, when that field is not null in the database.

Solution 2:

You should really make your decision based on- what you need your object to do, rather than the performance costs. Deciding based on performance should be done, once a speed issue has been identified with a profiler - the root of all evil and all that.

Look at some of the features of both and use that for your decision, e.g.

  • Integer can be null, int cannot. So is the int in the DB a Nullable field?
  • Do you need access to the Integer class methods?
  • Are you doing arithmetic?

Personally, I always opt for the primitive over the wrapper. But that's just a preference thing, rather than based on any technical merit.