Many toString methods in the jME code base report the class name along with the instance data. This is unconventional, but more importantly it is (a) never useful for end-user messages; and (b) is a real distraction for developers trying to debug difficult problems. WRT (a), Java class names should not be presented to an end user. WRT (b), if a developer wants a String denoting an instance's class name, they should use .getClass().getName(); if they want to see the distinctive properties of an instance, they should use .toString(). jME API users should have the freedom to intermix and combine String property representations and String class name representations how they want to.
To justify my assertion that class names are traditionally not included in toString, try out some toStrings with Java API classes, such as File, InetAddress, Float. There are some exceptions, but the standard behavior is clear.
Case in point. I often have to dump lots of Vector3fs, or Vector3f.toString() embedded in a longer string of state details. Compare a dump of 10 Sun Java3D javax.vecmath.Vecotr3f.toString()s vs. 10 jME com.jme.math.Vector3f.toString()s. One concisely displays what the developer needs to know and the other assaults the reader with useless and redundant data. It becomes a real frustration when comparing dumps of lots of data or when included in a longer String, but comparing just a single Vector3f instance:
(30.000002, 362.68192, 30.000002)
vs.
com.jme.math.Vector3f [X=30.000002, Y=362.68192, Z=30.000002]
I would have used .toClass().toString() if I wanted to see the class name. And any developer qualified to read developer-level jME messages had better know that the sequence of Vector3f coords is x/y/z.