In the spirit of
what are common mistakes we should avoid for Java?
Example: use the == operator for comparing two strings come from external sources rather than .equals method.
Use the == operator for comparing two strings come from external sources rather than .equals method.
The == operator compares object references. It doesn't check if the content of the strings are equal, only if they point to the same objects.
The most common mistake I've noticed so far is that C++ programmers treat Java like C++ and write C++ like java code. They still do not forget about 'destructors' and 'template magic'. Can't realize that code can be small and self expressed. Instead they recreate some abstractions that they are familiar with.
Another mistake I've found is that thinking that you don't have to worry about memory management leads to hanged objects and thus to memory leaks. Nevertheless Java manage memory memory leaks are still there.
Overriding equals() but not hashCode().
There are a lot more that are highlighted in the Effective Java 2nd edition.
Using the array-based read() methods in java.io's Readers and InputStreams, and expecting them to read everything they were told to - most of these will return an int containing the number of bytes/characters actually read (an arbitrary number, for large arrays often less than what was asked), and you have to loop until you're done.
This can be quite puzzling since it usually works fine with small arrays, and fails seemingly at random only with larger ones.
Writing to a file and having the program end without closing the OutputStream or Writer - data still in internal stream buffers can end up not being actually written to the file and getting lost.
Rookies often forget to call close() method on objects with an underlying resource such as a file handle or a database connection, leaving this job to the finalize() method.
Java methods throws an expception are not placed inside the try..catch block.
java.net.URL objects as keys in a java.util.Map map or java.util.Setclose() in a finally blockjava.util.Vector which are only still part of the API for compatibility reasons (this doesn't actually cause any harm, I think, but it should be avoided) NullPointerExceptions by not being consistent about when a reference can be null and when not; this includes both the optimistic school of programming where nothing is checked for null equality as well as the over-compensating style where basically everything is checked for nullSingleton design pattern in an environment with (potentially) multiple class loaders like e.g. JEE applicationsAddendum:
java.net.URL objects is that the method URL#hashCode() performs DNS lookups, which is a) slow and b) simply not what you would expect. See this site and this site for more details. I think this is still the case in Java 6.Vector and Hashtable are all synchronized, which is not needed in most cases. They have been replaced by java.util.ArrayList and java.util.HashMap, where synchronization can be added if it is actually needed by using Collections.synchronizedXXX(). It is not really harmful to use the old classes but it has drawbacks and no advantages. The only excuse I can think of is that you use an API that uses these classes, but then you should create a facade or an adapter which converts to the new data types and send all calls to that API through this facade.flip() on a bufferBimap (from the google collections library) and maintaining two maps (inverses of each other) instead.Reader or Writer, relying on the host default instead.String in a loop using the overloaded + operator, instead of using a StringBuilder or StringBufferCharArrayWriter in place of StringBuilder, or using abstract classes where interfaces are more appropriate.Null pointers.
Compilers can't check this. It only occurs at runtime. Either you or user will discover it.
Seeing you have to deal with a checked exception you don't care about and writing:
try {
....
} catch (Exception e) { }
Handle your exceptions properly (and catch the correct type) or at least re-throw them.
Remember the difference between Thread.run() and Thread.start(). Thread.run() simply invokes the thread's run() method. Thread.start() is what actually causes a new thread to begin executing concurrently.
try block and not in the finally block.SwingWorker).myDouble == Double.NaNfinalize(). Relying on finalization to do cleanup is usually a big mistake.gc(). This almost always makes your program run slower.new String(str) or new String("hi"). This creates unnecessary copies of the String arguments.java.util.HashMap) instead of interfaces (e.g. java.util.Map) in an API. This makes your API less flexible / reusable, and with a modern JVM there is no speed advantage.final for (supposed) efficiency reasons. With a modern JVM it should make no difference.java.lang.Exception. Don't be lazy: declare the actual (checked) exceptions that are actually thrown.null or an error value instead of throwing an exception to indicate an exceptional condition.Suppressing Warnings from the compiler! The number of times that ended up biting me has made me learn that warnings should always be treated as errors!
Accessing a static variable from a non-static method. Or accessing a non-static variable from a static method.
Not knowing about Soft and Weak references. I don't know how many memory leaks would have been avoided in code I've seen by properly using these types of references.
Some resources:
http://www.ibm.com/developerworks/java/library/j-jtp11225/index.html
http://www.ibm.com/developerworks/java/library/j-jtp01246.html
Serializing a Swing object and sending it somewhere else. The API specifically warns against this, since Swing objects aren't guaranteed to be binary-compatible across different versions of the library, but I've seen people try to do it anyway (including a professor who really should have known better, in a coding problem on an exam).
String concatenation.
Anytime you see something like:
String s = "initial";
for (int i = 0; i < 100; i++)
s += "Something"
alarm bells should start ringing. Conversely, some people have gotten the idea that String concatenation is always bad, and always manually do it themselves. That is they will do:
final String s;
final StringBuffer sb = new StringBuffer();
sb.append("String 1");
sb.append(variable);
sb.append("String 2");
s = sb.toString();
instead of
final String s = "String 1" + variable + "String 2";
despite the fact that the compiler generates basically the same code underwater, in fact the compiler produces slightly smaller code, since it won't emit and save sb.
Method dispatching:
null matches every type.
If you have two overloaded methods and pass null, you need to be careful which method will be executed.
I tripped over this myself a while back: http://stackoverflow.com/questions/377203/java-method-dispatch-with-null-argument
To add to the above:
If you try to Serialize something that doesn't implement Serializable, the serialization will silently fail.
Some java specific, and coding in general issues:
Holding a synchronized lock while notifying others of a change, usually a message broadcast. This is a very easy way to introduce a deadlock.
Overusing protected variables. It's used with the optimistic opinion that someone may need to extend the class, but not extend the behavior, rather hijack the parent implementation; it's essentially an argument against encapsulation.
Starting a thread in a constructor that uses the calling object. This can lead to the thread using a partially constructed object.
A semi-colon (;) after the condition of an if or while
if (a == b) ; {
...
}
Using a KeyListener to detect changes in a text component like JTextField. It will not work correctly for example when pasting text into the component. You should use DocumentListener instead. I've seen surprisingly many bugs caused by this. In general you should avoid using "low-level" listeners like MouseListener if there are better, higher level alternatives available.