* JavaPassesByValue.
* Strings are a lot more complicated than they seem (when you take into account interning, the garbage collection overhead and the consequences of their immutability).
* Serialization and the ''transient'' keyword.
* Synchronization model and the ''volatile'' keyword.
* Garbage collection can not be forced. System.gc() only ''suggests'' that you'd like the GarbageCollector to do something. (''But why would you want to force garbage collection?'' One possibility is if you're writing some code that is trying to measure the amount of memory a particular object graph uses.)
* The mess that is the current Java threading/memory model. How can one class, Thread, have so many deprecated methods?
* Finalizers are not destructors.

Certain parts of the language such as access modifiers like transient and volatile are used so rarely that one may never actually see a working example of their usage outside of the certification exam. (''Uh. If you ever serialize objects you should definitely think of getting familiar with the transient keyword.'' Absolutely, but writing serialization code isn't an especially common activity.)

----
(Discussion about Java's call semantics moved to JavaPassesByValue.)

----

''How can one class, Thread, have so many deprecated methods?''

Hard to answer without impugning the abilities of the people that produced the original Java.  A better question is how any self-respecting software outfit would dare release any edition of Java prior than 1.2.  (Some slightly less charitable people might say 1.4.)

----
All right, but where are the subtleties? 

Strings are hardly subtle. Thread.stop() and the likes were bad design to begin with, no subtlety there. Volatile is well known since the good old days of C. My contention is that while Java may still have traces of less than optimal design (to put it nicely), it hardly has any subtleties.

And this is one of its rare qualities. It is a language that if one cannot get it in a couple of days or so, maybe one shouldn't be programming at all.

----
I think I see the difference. When I defined this page I used the word "subtleties" to refer to obscure bits of the language/platform/API that can and often do bite people. The point being, in IsJavaCertificationWorthIt, that certification forces people to learn these arcana in advance rather than waiting for the time you come across them in a mission-critical project.

You seem to have a different understanding of the word. Could you or someone else give examples/definitions of true subtleties in other languages so that we may then assess if Java has anything equivalent?--AdewaleOshineye

''See LispSubtleties.''

Perhaps you're thinking of the kind of issues listed on PeterNorvig's "Java Infrequently Answered Questions" list, then? (http://www.norvig.com/java-iaq.html)

----
See JoshuaBloch's EffectiveJava book for yet more examples. -- ''His new book JavaPuzzlers (co-authored with NealGafter) is even more focussed on these issues.''

----
I think it's common to take a new Java programmer several months until he/she figures out that 'protected' scope is actually ''less'' strict than 'package' (default) scope, since 'protected' members aren't just accessible from subclasses (which is what you're taught protected scope is good for), but actually from the whole rest of the package as well.
----
I expected somethig different here. One of Java's subtleties is that return doesn't have the final say.
For instance
  try {
    return 0;
  } finally {
    return 1;
  }
...returns 1, not 0. --AalbertTorsius

----

This page and the JavaLanguage section of LanguageGotchas seem to overlap.

----
CategoryJava