Java doesn't compile down to assembly language, but that doesn't mean it is a slow pig. Modern JVMs use just-in-time compilers and other sophisticated techniques to bring the performance up to that of C++. But because Java also supports a much richer set of abstractions than C++ it is possible to write inefficient code if you're careless. The secret is to design your application for performance right from the start, and to profile and optimise it once it's working correctly.
This tutorial covered 15 ways to improve the efficiency of you code, but it is hardly the last word on optimisation. Look online; there are numerous sources of further information available. Glen McCluskey recently produced an excellent paper on techniques to improve Java performance. Sun also have a great Java3D Performance Guide with lots of useful suggestions and advice. Over the years JavaWorld has run plenty of articles on the same subject. There are also some great interest groups that can help you if you get stuck. Algorithmic improvements often yield the biggest gains and they are not specific to any one language or API - hit the proceedings of SIGGRAPH and check out what the game development community have done.
So what are you waiting for? Time to move up a gear. Soup up that application of yours: drop the suspension, fit a growly exhaust, a rear spoiler and some fat tires. Try life in the fast lane.
 Actually the answer can be worse than that. Different Java compilers treat strings in different ways but you would be fortunate indeed to get away with less than 12 objects. You could be stung for as many as 18 objects by some compilers.
 Take a look at one of the Matrix classes and you'll see things are worse than they first seem. Each matrix is stored in an array of primitive types. For example Matrix3f is stored in a float array. So when you create a matrix you're actually creating two objects: the Matrix object and the array. Ow!
 On all but the most recent releases of Java3D (1.2.1) compiling branches doesn't actually do anything!