You may want to keep in mindpitfalls described in this page. They may cause problems at run-time You may want to keep in mindthat weren't present in previous Java releases.Remember that the new language features are implemented at the compiler level.Internally, the compiler generates code that's similar to Java 1.4 code.This may result in non-obvious performance or run-time issues.AutoboxingAutoboxing conversion is the mechanism for wrapping/unwrapping primitives into/out of their box types (i.e. int --> Integer).Pitfalls: Don't abuse the auto-boxing features by letting the compiler insert alot of conversions in your code automagically. By doing that you maycreate an out of memory exception or force more frequent or lengthygarbage collection cycles. Don't test equality of boxed objects through the = or operators.Remember that they will work fine only for scalars in range -127 <= n<= 128. Use instead: if (x.equals(y)) {
}
if (x.intValue() == y.intValue()) {
}
if (42 == x.intValue()) {
}
Arrays of primitives or ArrayList? objects of boxed types are notautomatically auto-boxed. You must convert back and forth between themby traversing the array. Overloaded methods will resolve using Java 1.4 instead of Java 5rules for argument resolution. You will need to cast the correct type toresolve this correctly. Null pointer exceptions may result if your code tries to unbox areference to a boxed object that points to null. Add as mucherror-checking code as possible in suspect code! public Integer f(int nX) {
Integer retVal = null;
if (nX >= 42)
retVal = 2*nX;
return retVal;
}
// examples:
Integer y = f(33); // works fine; y can be null
int nY = f(33); // NullPointerException if f(33) returns null ! Compiler won't notice or care.
Be careful when writing to an ObjectOutputStream (or reading from anObjectInputStream), especially when implementing readObject() andwriteObject() for Serializable classes. The following lines are notequivalent, because ints and Integers are represented differently in thebinary data being written: int i=
;
objectOutputStream.writeInt(i);
// writes an int
objectOutputStream.writeObject(i);
// writes an Integer
Generics (parameterized types) A subclass of a generic class must match the superclass' definition exactly or the code won't work. If you want to extend class SomeClass<T>
, the subclass must include the same generic parameter (i.e. class NewSubClass<T> extends SomeClass<T>
).
Generic parameters don't follow the same inheritance rules asclasses. Use bounded types or wildcards instead. In other words, in Java1.4 you'd use void f(Number n)
and the argument could be any subclass of Number. In Java 5, void f(T t) { }
will only work with T arguments, so if you defined T as Number inthe class declaration, it won't work with Integer, Double, etc. If youwant something to work with the parameter type and with its subclasses,you'll have to extend the type parameter explicitly. Generic classes don't operate on primitives. Object declarationsusing generics rely on auto-boxing to convert int to Integer; this istransparent to the programmer but it may result in run-time resourceabuse. Legacy code may not compile without warnings; use Xlint or @SuppressWarnings to avoid the warning messages. Don't feel like you have to update every collection class to usegenerics! The code we have in production is tried-and-tested. Only movethe code to generics if it makes sense when you have lots of time totest or when you're actually fixing a bug. Otherwise, suppress thewarnings and move on.Static imports In general, if you feel like you want to use static imports, letyour IDE resolve the correct name and scoping. Don't import using thewildcard (i.e. import static java.lang.*;) because it may result inshadowing or collision issues.Enumerated types Enumerated types are first-class objects and allow you to definemethods, constructors, variables, etc. just like any other class. Ifyour enumeration gets lots of methods and instance variables, though,that may be a sign that you need helper objects instead. Revise yourimplementation. Don't rely on the values returned by compareTo() for scalar operations. The values may change in subsequent implementations/revisions of your enum. Double-check any code that relies on enums that you maintain/modify.The compiler will not generate any errors if a symbolic constant isremoved, so the compiler won't detect that you removed it. Code usingthe enum and relying on the enum and that isn't compiled with the newversion will throw an invalid reference exception when executed with thenew version of the enum.Enhanced 'for' statement Convenience may result in performance penalties if you have totraverse a big collection or array. In the case of ArrayList? , forexample, using a basic 'for' statement with an index to the element thatyou want to fetch will run faster than en enhanced 'for' statement. Enhanced 'for' loops have no way of keeping track of counters for each iteration. You cannot iterate backwards with a for -----------------------------------------------------
Silence, the way to avoid many problems;
Smile, the way to solve many problems;