java.util.Date.setTime(long):void isn't deprecated and mutates the object On Wed, Dec 2, 2009 at 5:50 PM, Alexey <[email protected]> wrote: > On Dec 2, 6:06 am, Fabrizio Giudici <[email protected]> > wrote: >> Reinier Zwitserloot wrote: >> > You know, I stopped caring about JSR-310. Provisionally. >> >> > Here's the problem of jodatime: It sufferes from -just-this-once- >> > syndrome. >> >> > If I need to format a date, I know jodatime is easier, but, for just >> > this once, It's not worth it. I'll just stick with SimpleDateFormat. >> > Same applies for parsing dates, and even for limited arithmetic >> > (though the horrors of java.util.Calendar means I'll go for jodatime >> > real fast when arithmetic gets involved). Of course, the next time, >> > it's still just-this-once. Adding jodatime to a project adds a >> > dependency, requires me to do some setup work on the project and >> > across various build tools, etc, etc. Often, it's one of the first >> > things you run into when building a prototype, often before you've >> > got your dependency system all sorted, and you just couldn't be >> > bothered. Then, later, when you've got everything set up nicely to >> > handle dependencies (you've got maven rolling or some such), you still >> > feel it isn't worth switching as you then feel that for consistency's >> > sake you would have to go through all existing uses of Date, SDF, and >> > Calendar, and fix them too. >> >> > Thus: just-this-once syndrome. >> >> Hmm... I see things in a different way (Reiner, I think it will take >> another ten topics before we find again something on which we agree ;-) >> ;-) ;-) >> >> The mere fact that Date is mutable is enough for making me want to >> switch to JodaTime / JSR-310. I'm sick of all those return (date != >> null) ? new Date(date.getTime()) : null; >> >> For me, I've been using JodaTime in a custom project 2+ years ago and >> it's ok for me. Then I decided to adopt it for all my stuff, but at the >> time I decided to wait for JSR-310, so I won't have to do another big >> replacement (and API change) within (what was supposed to be) a short >> time. Then there was the JRS-310 and JDK 7 delays, and from today's >> perspective I probably should have already moved to JodaTime. This >> uncertainty has prevented me from making a decision, which I have to >> reconsider with a fresh mind. Having advice about JSR-310 being >> accelerated would push me definitely. > > Hm... this is interesting. Is java.util.Date mutable? If one avoids > deprecated method calls, it is not and I've been treating it as such > for a couple years now. The fact that Sun has not yanked those horrid > deprecated API is another matter. But we do know that using static > analysis, the compiler can tell us if we're making any deprecated > calls and we should also be able to tell if a third-party library is > doing the same, even sans source. So, what the harm in pretending > java.util.Date is immutable as it should be? > > -- > > You received this message because you are subscribed to the Google Groups > "The Java Posse" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > > >
-- Alex Snaps <[email protected]> Software Engineer - Terracotta http://twitter.com/alexsnaps http://www.linkedin.com/in/alexsnaps -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
