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 -~----------~----~----~----~------~----~------~--~---
