account.changePassword(oldPassword, newPassword);Date lastModified = getLastModified();lastModified.setTime(System.currentTimeMillis());The above code updates the last modified date of the password and wants to avoid creating a new Object, but uses instead the setTime method to modify the existing Date instance. There is nothing wrong with that, however, it is not recommended to follow this practice because the Date objects are usually passed carelessly. The same Date instance could be passed to numerous objects, that don’t make a copy in their setters.
Dates are often like primitives. If you modify a Date instance, other objects that use this instance might behave unexpectedly. However, the general everyday Java practice is to copy Date references and not clone the object in the setters, so every programmer should treat Date as immutable and should not modify existing instances, this should be done only for performance reasons in special situations.
account.changepaasword(oldPassword, newPassword);account.setLastModified(new Date());Using one class or interface that contains all kinds of constants used during the application may not be the best solution, because these constants are unrelated with each other. The only thing that they have in common is the interface or the class and the reference to this class will contaminate many other unrelated components of the application. What if you want to share some classes between a server and a remote client? Or later extract a component and use it in another application? This class has created a dependency between unrelated components and this limits both reuse and loose coupling. You should never place constants across components boundaries, this is an exception only if the component is a library, and an explicit dependency is wanted.
