This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
No it isn't. All method-local primitive types and and references are put on the stack, all objects are put in the heap. No ifs and buts about it.
One reason I can think why they did is that it removes one commonly made error: you pass the stack-based object to a method that stores a reference to that object. Then the object goes out of scope, is removed from the stack, and the reference points to something undefined. Next when you want to access the "object" through the reference, you're in a world of hurt since the object is no longer there - and nobody knows what is.
Hate to complicate matters, but believe it or not, Java objects can exist on the stack !! Java 6 added "escape analysis" as an optimization tool.
If an object (referenced by a local variable) can be determined to not escape the method (which is really not that easy to determine), the object will be created on the stack. It will be finalized right before the method exits -- which reclaims the memory.