Matthew: True, but, that's why I said "optimally". I did actually go through most of my old code and java 1.5ed it. It wasn't really that hard, and I lamented a lack of an automatic tool at the time (I'm still somewhat amazed that eclipse, netbeans, and IDEA don't have a '1.5 this code for me please' refactor tool, AFAIK).
If you'll allow me a foray into a make believe world where everything worked better: Imagine all future java updates did ship with an 'update my code' refactor tool that got swiftly integrated by all major IDEs: One big change is always easier to do than a number of smaller ones (the big change could, at the very least, order its language features in a set order and update the entire code base, one feature update at a time, which is the same thing the 'many small changes' trajectory would do. However, the big change can be smarter than this baseline). Is that a good enough reason to pile language changes into an every-4- years schedule? Probably not. Just food for thought. On Jan 14, 5:29 am, Matthew Kerle <[email protected]> wrote: > my 2 cents... > > just because a new language feature is added, you don't instantly go back > and refactor old code to use it, unless you have a *very* good reason. > > to use your example, you need to "FriendFace" to the array, so you leave the > loop in the old syntax and convert the array to a List, run unit tests > commit and done. then later you need to perform another action on each > service, so you have to modify the loop. While there you make it into a > foreach(:) to make life easier. > > Unless the code is your baby or you have lots of time to spare, I rarely see > the point in modifying *old* *functional* code and running the risk of > introducing bugs just to use new language features. If you have to update > the code then you're already paying the modification price so go for it. > > So really the language change price isn't related as much to the incremental > vs big change issue, as it is to the frequency of maintenance to the code. > Using new language features should result in a global decrease in > maintenance effort, or else don't use them! eg - converting to generics and > foreach loops should reduce effort, not increase it. > > I think it's a shame that Java evolves as slowly as it does. The "don't > break backwards compatibilty" mantra sounds good, but in reality there are > breaking changes between 1.3->1.4 & 1.4->1.5 that keep some of us in the > enterprise legacy space stuck on those older versions. This isn't as much > Suns fault as poor architecture (using static initialisers to run SQL is a > cardinal sin), but we're still stuck all the same... :-( major architecture > refactoring is our only hope, not a small job. > > 2009/1/13 Reinier Zwitserloot <[email protected]> > > > > > Dick, my gut instinct agrees that many small incremental changes is a > > better idea than a gaggle all at once, but in practice I wonder if > > this is really such a good idea. Imagine the following java 1.4 code: > > > private final String[] KEY_SERVICES = new String[] { "FACEBOOK", > > "MYSPACE", "TWITTER" }; > > > public void initialize() { > > for ( int i = 0 ; i < KEY_SERVICES.length ; i++ ) { > > registerForService(KEY_SERVICES[i]); > > } > > } > > > Let's say that the JVM evolves incrementally as you suggested, and > > adds these features, one at a time. Every feature update would > > optimally warrant changing the above source code. > > > - introducing generics: Probably better to turn KEY_SERVICES into an > > immutable Arrays.asList() concoction. > > - introducing enums: Even better, make this an enum. > > - introducing foreach loop: Fix the forloop to loop through the > > array / list / enum (whatever it ended up being). > > - introducing closures: Turn the forloop into a list/enum.each > > (closure). > > - introducing the SPI system: Get rid of this entire thing and move > > the initialization code into the responsible manager classes. > > > clearly, revisiting the source code to process every little thing is > > going to get annoying fast. For example, fixing your old source code > > so you add generics AND fix your for loops to use the new (in java > > 1.5) foreach syntax works best when you do both of them at the same > > time. > > > Small incremental is great for keeping developers up to date - they > > can focus on learning one new thing every 6 months instead of dealing > > with generics, foreach loops, annotations, a bunch of new API, and > > autoboxing/unboxing at the same time, which is a daunting task, but > > for the purposes of fixing up old code, I'm not sure. > > > It would DEFINITELY help if a new java version also shipped with code > > migration tools that basically gave you a wizard prompting you for > > every instance in existing code where you should probably rewrite > > parts of it, preferably with a suggestion of how to do so. A few > > changes (such as foreach) can probably run completely automatically > > without even needing you to verify most of the changes it would make. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
