Could you explain why? Although I admittedly don't know how Java implements timers, doing so in any other way than using the timer functionality built into the operating system would be quite dumb, to be honest.
Blocking on a timer and blocking on sleep should be exactly the same in respect of CPU cycles and power consumption. Except that on at least one major operating system (Windows), blocking on a timer has a much better precision and reliability than sleeping. Sleeping will give away the remainder of the time slice and not schedule the thread again before some time, rounded up to the next 16 or so milliseconds. Blocking on a timer puts the thread on the ready list the moment the timer expires and dynamically boosts the thread priority, scheduling it before other and possibly interrupting running threads with the same (original) priority. That's a difference between "yeah, some time, eventually" and "as soon as we can handle it".
Sleep just wraps the OS sleep function, which means your 1ms sleep could end up taking 10+ ms on Windows (it works for some games but for 60fps it will reduce the players experience, which is why i only recommend it as an option, on Android OTOH sleep can be used to control runspeed(in foreground activities) without much problems (It seems to wake up the exact millisecond you asked for each time)).
Timers (as in the Timer class) in Java work reasonably well (on some platforms, i havn't actually tried them on Windows in a very long time), their problem is that they spawn a new thread, they don't touch the currently running thread. There are two classes named Timer in Java (big wtf imo), one in Swing which uses ActionListeners (These are the ones the OP are using) , these create a new thread per timer object and the execution frequency is set per Timer, They have some synchronization overhead since the actual execution is done in the gui thread, not the Timer objects thread). (The actionListener is called by the swing event loop when it encounters the event sent by the Timer object, so even if the event is sent on time it will never be executed on time(Allthough the eventloop runs fast enough i guess)). (Swing imo is a piece of shit API, GUI apps in Java are better off using for example wxWidgets or QT, Games benefit more by using for example LWJGL or Slick.
The second Timer class is in util and uses TimerTasks , these also create a background thread per Timer but can have multiple scheduled tasks(With different frequencies or delays) per Timer, these tasks are executed sequentially. (the util Timer has lower overhead and is more flexible but executes in its own Thread which means you will have to be a bit careful, These are solid enough imo to be used in a game, but the multithreading issues doesn't make them all that suitable for a beginner and they're far better for triggering infrequent events.
Neither Timer class give any realtime guarantees, the spec makes it entierly valid for a compliant VM to implement the Timer classes with far worse accuracy than sleep aswell.
The Timer classes also only have millisecond precision at best, (in practice it is worse than that), System.nanoTime is required to always use the most precise timer available on the underlying platform and normally has very high accuracy. (IIRC it uses QPC on Windows)