Your Java programs should conform to some kind of uniform style. For example, you could use the style set forth in this Java Language Coding Guidelines. I will deduct points if you do not make a reasonable effort to follow some kind of uniform style. In particular, all of your code should be properly formatted and indented.
For each method in your programs, you should write a Javadoc specification for the method as described in Appendix B (PDF) of the textbook Think Java.
Your program must compile without error. If your program does not compile, you will lose 50% of the points. Even if your program is "essentially" correct, you will still lose 50% of the points; there is no reason to turn in a program with syntax errors.
To get full credit for an assignment your program must completely solve the stated problem. If you are not quite sure what a "complete" solution is for a particular assignment, ask me for more details. It is your responsibility to understand the assignment. It is perfectly OK for you to show me your program at any stage of its development to ask if you are on the right track or if you are completely done. Ask early and ask often because it is better to ask than to lose points.
To get full credit for an assignment your program should solve the given problem in an efficient way. You will lose points for writing inefficient or inelegant code. This criteria is a bit vague, but it is here to force you to work on writing good code. If you are in doubt about your code, show it to me and I'll tell you if it is overly inefficient or inelegant and I'll try to suggest how you could improve it.
Your program should contain a reasonable amount of comments. A complete lack of comments will lose you points, but remember that it is almost as bad to over comment a program as it is to under comment, so don't get carried away.
Do not turn in a program with large blocks of commented-out code. A few lines of commented-out code (with a brief explanation of why it is commented-out) is OK. Small blocks of commented-out code can be useful for trying out different ideas or help with debugging. But large blocks look sloppy and unprofessional, and can make your code hard to read.