|
Let's see:
1. Garbage collection: I think the JVM spec is sufficient, and any problems with GC timing are minimal compared to manual disposing references as in C++. Would be nice though if finalize were guaranteed to be called. As it is, a program that exits doesn't free all the references, but rather just terminates the program and deallocates the heap in mass. This makes the finalize hook fairly useless. Means that when you are managing devices, you are back to managing your resources manually.
2. Pass by Reference: Although the authors point about being confusing to C++ people, I think that Java's parameter passing is the correct way to do things. Of course, having a distinction between objects & primitives is a pain, that's a different issue.
3. Atomic operations: Any programmer that relies on atomic operations usually has problems that extend beyond a single instruction. Synchronization (and possibly volatile) need to be thoroughly examined for any code that has threads that can step on shared references.
4. Synchronized code: I don't think there's anything inherently wrong with Java's Mutex scheme. I wish, though, that they provided more and better methods to go along with the object locking. Which leads to the last question:
5. Waiting threads: Java's thread priority is essentially useless if you run across enuf platforms. Because they made the priorities generic across a multitude of OS platforms, there's no real way to guarantee that thread priorities have the intended effect.
| 
Dispelling Java programming language myths