I have a game that I've made using a java.util.Timer to deal with animations, performing the work of each frame in an actionPerformed method and just updating it about 30 times a second. The result is pretty clean, but obviously all movements are based per frame as opposed to per timeslice. I was wondering if there's anything especially wrong with this approach or if anyone had comments on tradeoffs between this and other approaches?
All depends on your needs. If the result looks ok, the approach is ok. It won't use more CPU than effectivly needed, is multithreading-friendly, lets the GC live - in this sense it even can be called 'advanced' compared to 'render-as-fast-as-you-can' things.
itself is an important term in you program (as it would be for a true simulation), you could measure the current time when called back by the Timer. There, again depending on your needs, the lowres clock System.currentTimeMillis() or the hires one com.sun.j3d.utils.timer.J3DTimer may be used.
At the bottom line I feel that's basically the Java way to design a gameloop.
Also has sun fixed the high resolution timer yet?
Fixed? It never has been broken (except for a short period in one beta).