Link Details

Sigh - Not another date implementation in Java. The class is not immutable and copies the bad design decisions of the Calendar.

Do you buy a new watch every time when you want to change the time? Jodd utilities are about performance and usability. I do not make classes immutable without special reason and I never ever had a problem with that. In my humble opinion, this is not a bad design, just different. I just like to use like 80% better performances using int (or MutableInteger) instead of Integer. At the end, it is easy to make immutable from mutable class, while oposite doesn't work.

Another example is java sort method that takes an array to sort. JDK implementation takes array and then duplicates it, and then sort a copy (immutable way). This requires double amount of memory and is slower. Jodd search, for example, uses absolutly the same algorithm, but on provided array (mutable way). Therefore, it does the sort in less memory and less time. For me, that is real life requirement, not a theory.

I must have different JDK... My Arrays.sort is sorting provided array in place (for Objects it does create a copy, but it is implementation detail, not a contract)., so it is very 'mutable' way. And they have decided to make a copy internally, because it was easier to make sorting stable this way (is Jodd sort stable?). Anyway, there are plans to replace the algorithm with something which is not allocating temporary garbage and is stable at the same time (one from python I think)

I suppose that we come from different areas. I do not make classes mutable without a special reason ;) Trick is, that with multithreaded code, you pay considerable penalty with mutable classes - you need a lot of defensive memory barriers (in form of synchronization/lock/volatiles) to make sure that you don't end up with inconsistent view of objects. With immutable classes, you get half of it for free and you can get another half with lock-free collections.

I was thinking about Arrays.sort(Object[]). It first clones passed array and the performs the merge sort. The same results you can get without the cloning, like jdk does for sort(int[]) for example. Jodd sort is stable ("...equal elements will not be reordered as a result of the sort...") as much as original jdk sort is (since algorithm is unchanged). I must admit, i do not see (or understand) the reason for this cloning - if I need it, i will simply do cloning before the search, if I do not need it, I will sort the array as it is. Just to vizualize the difference: sorting 1 million objs (in some my previous microtest) with jdk takes 5s, and with jodd 3.5s (and you have 2x more memory availible). This sounds like a confession of performance freak, something not so popular these days anyway :))

I completly do understand the reason behind the immutable classes and your point of view (and not only yours, of course, this is not a new story anyway). I just feel I need smaller 'units' or 'bricks' so I can decide if I would go for mutable or immutable design. And often it happens I need to make some 'higher' class immutable.... I like to have more smaller chunks where I can control more, even if that asks for more work sometimes.

I think that Joda Time got it right, even if it is a bit overkill at some points.
,

I agree. Joda Time is the way to go. Now hopefully Joda will make it into Java 7 so we can finally put this nonsense to rest.

JDateTime is old almost like Joda Time, if not older (I just do not have the right skill to present it to the world;))) Do not worry, it is not an attempt to say this is the *ultimate* way how we should handle time - I just see it as an alternative. Someone likes it more than other solutions, someone preferes to stick with the defaults (calendar or joda, whatever it will be). Everyone chooses its own poison;)