Touche. On Dec 2, 12:19 pm, Alex Snaps <[email protected]> wrote: > 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 > > athttp://groups.google.com/group/javaposse?hl=en. > > -- > Alex Snaps <[email protected]> > Software Engineer - > Terracottahttp://twitter.com/alexsnapshttp://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.
