I think the more accurate answer is the amount of rewrite that would have to be done. You can turn off the warnings but that is risky. You can go through the code and put types in everywhere but that is a fair amount of work. I think the developers were able to handle the new syntax fairly easily. It was all the rewriting that would ensue and thus all the testing and extra effort that management would not sign off on. Back to ROI on changing the code. Very little benefit modifying tons of code to work with generics. And all for what? So you can add some new feature using generics instead of having to do it the old 1.4 way? Some of these code bases are huge and cannot be modified all at once. I'm working on a project that uses 1.6 thankfully which started 4 years ago. I doubt it will ever move to 1.7 or 1.8. There are over 100 people writing code every day adding to what would have to be reviewed and tested should a change to a new Java version ever happen.
On Tue, May 31, 2011 at 8:52 AM, Ricky Clarkson <[email protected]>wrote: > What was magical about 1.4.2 over 1.3 or 1.2 that made lots of people > stop there? (I know some stopped at 1.3 for a while, but not very > many in comparison) > > I think it was simply the 3000 generics warnings their existing code > gave when compiled with javac 1.5, as mentioned earlier. > > One of my old friends moved up to Java 6 only a year ago, from 1.4, > because it took that long for their developers to become familiar with > generics. Not because generics are hard, just because they didn't > make any conscious effort to learn, and the warnings put them off. > > Regarding not moving up because the application is no longer being > maintained, sure, but there are a lot of questions in IRC, etc., from > people who are working on such systems, i.e., are actually maintaining > them. > > -- > Skype: ricky_clarkson > UK phone (forwards to Skype): 0161 408 5260 > > > > On Tue, May 31, 2011 at 9:25 AM, Robert Casto <[email protected]> > wrote: > > Because the platform is changed you end up having to test everything. If > you > > run into problems you now have developers trying to figure them out and > get > > them fixed. This is a lot of wasted time and effort. The only benefit is > for > > the developers. If the application is stable and in maintenance mode, > there > > is NO reason to upgrade to a new version of Java. > > > > If the application is evolving, changing, and being added to, then there > > would be reason to change to a newer version of Java. The developers > would > > get a lot of benefits as would those maintaining the application. Doing > new > > development on 1.4 is ludicrous but I know companies that do it because > they > > just keep adding features and don't want to spend any time on retesting > what > > already works. > > > > Remember, it is management that makes these decisions, not the > developers. > > We would be happy to use 1.7 in production right now if we had our way. > If > > 1.8 is on the table and we can get the code, we would even push it into > > production. But the reality is the developer rarely has any say in what > > language and which version is going to be used. And steering it one way > or > > another is normally an effort in futility. > > > > > > On Tue, May 31, 2011 at 7:30 AM, Joseph Ottinger <[email protected] > > > > wrote: > >> > >> People don't care about performance. They want safety. Unless we're > >> talking automobiles, because people are idiots. > >> > >> On Tue, May 31, 2011 at 7:21 AM, Jess Holle <[email protected]> wrote: > >> > Hmm... > >> > > >> > No user benefits like greatly improved JVM performance between 1.4.2 > and > >> > 1.6? > >> > > >> > On 5/30/2011 10:24 PM, Steven Herod wrote: > >> >> > >> >> 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. > >> > > >> > > >> > >> > >> > >> -- > >> Joseph B. Ottinger > >> http://enigmastation.com > >> > >> -- > >> 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. > >> > > > > > > > > -- > > Robert Casto > > www.robertcasto.com > > www.sellerstoolbox.com > > > > > > > > -- > > 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. > > -- Robert Casto www.robertcasto.com www.sellerstoolbox.com -- 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.
