Yeah, there it would be more of a heuristic 'huh, maybe this could be enum-ized?' kind of deal. Yet... if you can automate only a few things, still worth it.
On Jan 14, 11:21 pm, Matthew Kerle <[email protected]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
