There seems to be some debate over refactoring to utilize java generics within my current team. The question I have is what are the current industry standards in terms of refactoring older Java code to take advantage of some of these features? Of course by industry standards I am referring to best practices. A link to a book or a site with these listed will be awarded the answer vote as that is the least subjective way to handle this question.
+3
A:
Utilizing java generics is definitely a good idea. It is backward compatible. So the codebase you cannot convert will continue to work with the new code.
EDIT : I should have mentioned type erasure as the reason which makes backward compatible.
fastcodejava
2010-02-27 00:48:31
thanks for the helpful information, however is there any set of standards as to what should be refactored to generics and not just do it for the sake of doing it.
Woot4Moo
2010-02-27 00:49:57
@Woot4Moo - there are no such standards. It is a decision that needs to be made on a case-by-case basis.
Stephen C
2010-02-27 02:31:51
+1
A:
Best practices for adopting generics? The first best practice is "do". Try to eliminate as many casts as you can from your code. If you want to make your life easier, use IntelliJ's "Generify" refactoring -- just point it at your entire codebase, let it do its thing, and then do a little post-cleanup.
Kevin Bourrillion
2010-02-27 00:53:19
the question now becomes is it do for the sake of doing or do because its proper?
Woot4Moo
2010-02-27 00:57:46
Do it if you can pull it off. Sometimes, writing generic non-container classes can be difficult (learning to use upper, lower bounds and multi-bounds). The best rule of a thumb is that if you are casting a value that comes *from* generic call, then most likely your generification is not good enough or you've hit one of these few corner cases that the type system can not express. Having false sense of security provided by generics and seeing your system fail at runtime with ClassCastException can be a very frustrating experience.
ddimitrov
2010-02-27 02:24:21
@Woot4Moo - well obviously, you should NOT do it just for the sake of doing it!
Stephen C
2010-02-27 02:34:17
+4
A:
The papers from this MIT research group might provide you with some useful guidelines:
- Refactoring Java Applications to Use Generic Libraries
- Efficiently refactoring Java applications to use generic libraries
Robert Fuhrer, Frank Tip, Julian Dolby, Adam Kiezun and Markus Keller
ECOOP 2005 --- Object-Oriented Programming, 19th European Conference, (Glasgow, Scotland), July 25-29, 2005. - Refactoring techniques for migrating applications to generic Java container classes
Frank Tip, Robert Fuhrer, Julian Dolby, and Adam Kiezun
IBM T.J. Watson Research Center IBM Research Report RC 23238, (Yorktown Heights, NY, USA), June 2, 2004.
- Efficiently refactoring Java applications to use generic libraries
polygenelubricants
2010-02-27 00:59:00
+7
A:
I don't think that blindly following what somebody else declares to be "best practice" or "industry standard" is ever a good idea. You're in the best position to decide whether changing your code is worthwhile or not.
The questions you need to answer are what benefits will you get from upgrading the old code, what will it cost, and what are the risks?
The main benefit is that you will have improved compile-time type checking, which should help to detect bugs in new code that uses the updated code. It may even highlight bugs in existing code. Code that uses generics, while sometimes quite verbose, is typically more readable as it is explicit about which types are valid in which contexts. You'll also no longer have to suppress/ignore compiler warnings.
The cost is the amount of time it will take to make and test the necessary changes to introduce generics. Any time you make code changes there is a chance that you might introduce bugs, so that's a risk. Do the benefits outweigh the costs? That depends on how much code you have, how it's being used and what other demands you have on your time.
Dan Dyer
2010-02-27 00:59:06
Indeed, I have been refactoring package by package only when it makes sense for each one.
Software Monkey
2010-02-27 02:56:28
+1 for "improved checking for new code". I'd use generics only for new code and update the old code class for class only when I need to touch that class anyway.
Thilo
2010-02-27 05:55:22
+1
A:
Your team should be balancing the benefits of a large-scale refactoring against the cost and the technical and business risks of doing this ... and the other priorities that your team has.
"Best practice" arguments and opinions from people who don't understand your project and the business context are simply not relevant here.
Stephen C
2010-02-27 01:28:14
+1
A:
Best Practices don't exist. That's a weird term that suggests that the door closes on the 'bestness' of a particular solution... Use generics? Yes. Immediately. It's an awkward journey, since so many of the big libraries (Hibernate, Spring) still fail to embrace them completely.. but in my experience, dealing with a mix of generics and brave-casts still makes for a better code base than not using them at all.
I'd also make it policy to convert-as-you-touch instead of some sort of giant refactoring mission.
royal
2010-02-27 03:41:30