4 ms·

Before Java 8 and Jodatime, it was better to use java.util.Date than a long, for type-checking and self-documentation. If a function accepts a java.util.Date a

Before Java 8 and Jodatime, it was better to use java.util.Date than a long, for type-checking and self-documentation. If a function accepts a java.util.Date and you pass an id of some database object by mistake, you'll get a compile error. If the function accepts a long you won't. If a function accepts a java.util.Date and the parameter is called "start" you know it accepts an instant in time, if it accepts a long you might think it could be something else. Yes, the class is terribly named, but before there was Java 8 and Jodatime, it was better to use it than a long.

phyzome 9y ago
And rather importantly, with a dedicated type you're a bit less likely to encounter and off-by-a-thousand error when there's confusion about millis vs. seconds since Unix epoch.
bluestreak 10y ago
It is not always a good idea to box primitives so that you can have compiler point out mistakes. Yes, it is good for developer once or twice, but end user will suffer performance hog forever.
- nradov 10y ago
  Modern JVMs are pretty good at optimizing away the overhead of boxing primitives. So don't throw away the advantages of type checking unless you have hard evidence of an actual performance problem.
- adrianmsmith 10y ago
  This is a trade-off between "should the program work" or "should the program be fast". The users would prefer a slow program that works, over a program that crashes or corrupts data.
nrinaudo 10y ago
But java.util.Date is mutable where a long isn't, and that's a problem. People can mutate a Date from under your feet if they manage to get a reference to it. This has a lot of far reaching implications, but essentially, unless you protectively copy all values of type Date you get or give, you can't trust your own internal state. You can't write a legal equals or hashCode implementation that uses a date field. The list goes on. Don't do java.util.Date.

phyzome 9y ago

And rather importantly, with a dedicated type you're a bit less likely to encounter and off-by-a-thousand error when there's confusion about millis vs. seconds since Unix epoch.

bluestreak 10y ago

It is not always a good idea to box primitives so that you can have compiler point out mistakes. Yes, it is good for developer once or twice, but end user will suffer performance hog forever.

nradov 10y ago
Modern JVMs are pretty good at optimizing away the overhead of boxing primitives. So don't throw away the advantages of type checking unless you have hard evidence of an actual performance problem.
adrianmsmith 10y ago
This is a trade-off between "should the program work" or "should the program be fast". The users would prefer a slow program that works, over a program that crashes or corrupts data.

nrinaudo 10y ago

But java.util.Date is mutable where a long isn't, and that's a problem. People can mutate a Date from under your feet if they manage to get a reference to it. This has a lot of far reaching implications, but essentially, unless you protectively copy all values of type Date you get or give, you can't trust your own internal state. You can't write a legal equals or hashCode implementation that uses a date field. The list goes on. Don't do java.util.Date.