What are the pitfalls of a Java noob? [closed]

Answer 1

Bookmark javadocs: http://java.sun.com/javase/6/docs/api/index.html

Better yet, install them locally and bookmark the page on your local machine for faster lookup and offline browsing.

Answer 2

I would have to say.

One of most common noob pitfalls phrases like "parameters on methods are always passed as reference, because Object variables are references, right?"

so when you see something like:

public void foo(String str){
      str="yeah, this should work!";
}

String str = "";
foo (str);

System.out.println(str);

You can hear a "Wait, WTF !" coming from a noob.

In my experience, java noobs don't know about StringBuffer / StringBuilder. Neither on inmutable objects.

Answer 3

This may be a bit too basic of advice, so forgive me if I'm offending you for bringing it up, but I've seen way too much beginning Java code that throws the static keyword around freely, seemingly without regard for what it's for. So if you see a warning complaining about "static reference to non-static value" or some such thing, don't try to solve it by randomly placing static on an otherwise non-static thing, unless it makes sense to do so.

Here's a minor tip that you might have trouble searching for until you know the term for it: "package-private". In Java, there is the same public, protected, and private scopes that exist in other places like C++. You can read up on what they're for, if you don't already know. Note, however, that if you don't specify whether something is public, protected, or private, it's none of those things. It's package-private, and there's no keyword that specifies it except lack of a keyword. Package-private things act as private values to anything in another package and public to things that are in the same package.

One more random tip: Use packages. It's possible to not begin your .java files with a package com.whatever.foo; line, and if you're using command-line javac you'll find that it's nice that files lacking that line show up in your working directory, but it'll almost always end up being a pain later. And stop using command-line javac anyway. Use Eclipse.

Answer 4

Combining equals() with autoboxing can get really crazy:

Integer X = 9000;
Integer Z = 9000;
short y = 9000;
boolean b1 = (X == Z);  
boolean b2 = (X == y);    
boolean b3 = (X.equals(Z));
boolean b4 = (X.equals(y));
System.out.println(b1 + " " + b2 + " " + b3 + " " + b4);

outputs:

false true true false

Answer 5

Think about running FindBugs on your code (available as an Eclipse plugin). It can flag many common errors. As inspection tools go, I think it is a good one for beginners because it doesn't nitpick over inconsequential details.

Answer 6

I think that the best "cheatcode" is "Don't be smart, write dumb code".

The terms are somewhat loaded but basically you want things to be simple when you write them, because then they will be simple to read when you come back to it later. Also these days the JVM is a LOT smarter than you are, and non-dumb code usually try to do something "more efficiently" which may prohibit the JVM from doing something even smarter.

Have a look at http://java.sun.com/developer/technicalArticles/Interviews/devinsight_1/

Please note: It is ok to write smart code, you just need to prove first it is necessary :)

---

EDIT: A few more things.

• Write a lot of code. Practice makes perfect - always strive to do this in the best way possible. If you come back to your code later, you might have learned a thing or two since which allow you to perspective your earlier choices allowing you to make a better descision next time you have to make a choice. THIS INCLUDES DOCUMENTATION! Documentation is what allow others to use your code without understanding it in detail.

• Read a lot of code. Set up your IDE so it allows you to see as much source as possible for what you work with. By using a JDK as the JVM in Eclipse the sources are automatically attached so you can SEE the source for whatever you happen to hit in a breakpoint. When including a jar from e.g. Apache in your code, include the sources so you can see what it does. It will help you some day that you can figure out WHY a certain thing happens and how to avoid it.

• Work with peers. Other programmers on a similar level may provide input to a situiation - perhaps even just their listening to your explanation clarifies things in your mind - and you may also help them. By working together and evaluating together you can leverage each other.

• The Java Tutorial from Sun covers a LOT of the Java libraries, and learning those covering the essential part of the runtime (java.lang, java.io) by heart and having read the rest (just to know what exists) will make you a more skilled programmer. You will know what is in your toolbox!

• Participate in Stack Overflow. Writing good answers to questions (even if they have been answered but badly) will allow you to put your experiences into words, which is practice for writing documentation :)