I agree with most of what you say, there is a cost involved, but I disagree that there is no benefit. Java 1.6 is not alone. There are lots of other things that come with it.
In the example I used above, we upgraded weblogic 8.1/java 1.4 to Tomcat 6/Java 1.6. This is an application to which there are changes made regularly (at least two times a year). We didn't change any of the plumbing: we're still using hibernate with XML config, etc. We didn't change any of the code to use generics. The end users will not notice a big difference, only a slight speed up: for instance better GC with 1.6. The client doesn't have to pay a license fee for weblogic any more. Their policy is to move towards open source where possible, so Tomcat was a good move for them. There are fewer types of machines/VMs to maintain. The developers can *start* to code using generics, annotations etc. They can run Tomcat from within standard Eclipse (we were using an old version of MyEclipse for the weblogic support, again requiring a license). We can use Helios! There is risk involved in any change, we did find changes in behaviour: We used the old typesafe enum pattern (http://java.sun.com/developer/Books/effectivejava/Chapter5.pdf item 21), which didn't work correctly on 1.6, at least the way we were using it. This is illustrated by the following java: package uk.co.farwell.jvmtest; public class JvmTest { private static class Foobar { static int fred = 1; static { System.out.println("static init"); fred = 2; } } public static void main(String[] args) { System.out.println(Foobar.class.getName()); System.out.println("fred=" + Foobar.fred); } } On java 1.4, you get: static init uk.co.farwell.jvmtest.JvmTest$Foobar fred=2 on 1.6, you get: uk.co.farwell.jvmtest.JvmTest$Foobar static init fred=2 So if you use the Foobar.class in 1.4, the static fields get initialised and the initialisers get called, but in 1.6 you need to directly access a member of the class for them to get called. This was a problem for use because we were handing a class to a generic method to collect a list of all possible enums, so this returned an empty list in 1.6. Upgrading to a newer version is never without risk, but it's not without benefits either. Matthew. 2011/5/31 Steven Herod <[email protected]>: > The opposition to moving beyond 1.4.x would be mainly the cost. > > You have a working application which is stable, you are expending > minimal effort maintaining, and suddenly someone is proposing you > spend effort/cash to give developers a warm fuzzy feeling and the end > user no actual visible benefit. > > Hard to justify. Easier to wait until the app is retired. > > On May 30, 9:57 pm, Ricky Clarkson <[email protected]> wrote: >> The semantics are pretty clear, as you get compile errors when you get >> things wrong. >> >> Java developers *were* used to unsafe casts. I'm regularly in ##java >> on freenode IRC and see fewer and fewer people trying to use untyped >> collections. It still happens, though mainly by accident. >> >> I've seen some new Java code using untyped Vectors and Hashtables >> recently, but a) the [ir]responsible developers just left b) that >> would have happened no matter what Java had done short of removing >> Vector and Hashtable. >> >> -- >> Skype: ricky_clarkson >> UK phone (forwards to Skype): 0161 408 5260 >> >> >> >> >> >> >> >> On Mon, May 30, 2011 at 1:13 AM, Casper Bang <[email protected]> wrote: >> >> It's quite elegant that in general if I update a dependency and that >> >> dependency has switched from raw types to generics, I generally have >> >> nothing to do. With the .NET approach I would have to marshal between >> >> old and new collection types constantly. >> >> > Yes but at least the semantics would be clear up front right there in >> > the type-system and you'd avoid various pitfalls (Java developers are >> > used to unsafe casts and unsafe array variance) as well as pave the >> > way for a deprecation/migration strategy. Sometimes something must die >> > in order to leave the way for something new, or all we get are zombies. >> >> > -- >> > 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. > > -- > 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. > > -- 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.
