Hacker News Reader

Comment by kpil | Hacker News Reader

Or just use a long...

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.

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.

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.

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.

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.

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.

Yeah. Have fun working out date arithmetic, leap seconds and time zones on your own. What could possibly go wrong.

No, that would be stupid - but you can't use a Date for that either.

You can; there are getters and setters for the different components. And because Date is lenient by default, you can do eg.

    date.setMonth(date.getMonth() + 1);

and it will do the Right Thing even if the month is December.

The `get` and `set` methods on `Date` have been deprecated since 1.1... In favor of `Calendar`, which is all `Date` is using under the hood to perform such calculations anyway.

True that, somehow totally slipped from my mind. To my defense, the last few times I've used java.util.Date it has been with GWT which doesn't provide anything better at least out of the box.

No worries. The whole thing was a tire-fire from the get-go, and I certainly don't blame you.

It should be encouraged to use long. Not only it performs better, but it is also simpler to understand and use compared to obscurity of java.util.Date.

I've written all of date arithmetic using only long values and I can share the code if anyone is interested

It would usually be better to use an Instant ( https://docs.oracle.com/javase/8/docs/api/java/time/Instant.... ), which helps make your code self-documenting and provides a whole set of methods to deal with the fact that your long actually represents a point in time along a timeline.

Reply on news.ycombinator.com