I agree, but i think it would be pretty hard to automate. Some things would be easy, like for loops and replacing deprecated API usage with the new one, (although no doubt some of the emitted code would be horrendous...). But I think things like enums and generics would be a lot harder to do, and there'd be a lot of edge cases where the tool wouldn't be able to recognise a pattern it could turn into the new code (thank God or we'd all be out of a job...).
2009/1/15 Reinier Zwitserloot <[email protected]> > > 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 -~----------~----~----~----~------~----~------~--~---
