Roedy gave the best answer you're going to get, which is that there's no
good way to do that.  If you don't like the answer, too bad.  It's still
true.

If you desperately need this, then perhaps you could accomplish your
task with JVMTI, which would allow you to intercept all calls to methods
of java.util.Timer or javax.swing.Timer and keep a list of the tasks.  
You may (or may not -- I really don't know) be able to do the same by
rigging an AOP implementation to do runtime instrumentation of the
bootclasspath and do the same thing that way.  Or, if you're willing to
depend on implementation details of the standard API, then do as Roedy
said and look at the source code to these two classes... and then use
reflection with setAccessible(true) to examine the private members and
get the list of tasks.

None of those are good things to do, though.  They might work for a
development tool (though the latter two are poor even for that purpose),
but won't be very good choices at all in production code.  To solve that
problem, you'd need to be willing to step back and consider other
solutions besides getting a list of all timer tasks in the system.  WHY
do you think that you need to do that, and what other mechanisms might
be available to reach the same goal?