We Keep Coding

JavaFX Transition Equivalent

I have a non-gui application where I want to asynchronously interpolate some data over time.
I had a look at the JavaFX Transition API and it looked ideal. However, for the transitions API to work it has to be run as part of a JavaFX application context - which I don't really want to add the overhead unnecessarily for.
I was wondering if anyone could suggest something equivalent? Or is this something I'm going to have to write myself?

I'd use java.util.Timer for that. You can give it a TimerTask (basically a Runnable) that it will execute every x ms (its period). It also runs on a background thread, which I assume is what you meant with asynchronously?
API: http://docs.oracle.com/javase/8/docs/api/java/util/Timer.html

What's the right way to go from one form to another?

I am doing a school java project using the NetBeans IDE. It includes some basic database manipulations. We were taught at school to use the following for linking one form to another:
new <form_name>().setVisible(true)
But this seem to slow down the whole application and there is a small lag for going from one form to another. I heard that using JDialog boxes is a solution to this problem.
So what's the right way to do it?

Better to not swap in and out of different JFrames. How many professional applications such as word processors do you use that do this that throw different windows at the user? Better to use one main JFrame and swap views (usually JPanels) in it via a CardLayout and occasionally show a dependent Window as a dialog when needed, especially when you need to get information in a modal way.

some basic database manipulations. .. But this seem to slow down the whole application
Don't block the EDT (Event Dispatch Thread) - the GUI will 'freeze' when that happens. Instead of calling Thread.sleep(n) implement a Swing Timer for repeating tasks or a SwingWorker for long running tasks. See Concurrency in Swing for more details.
(But also see #Hovercraft's advice re. CardLayout..)

Using Eclipses Progress Monitor Window in a standalone Application

I'm writing an SWT/JFace application and was wondering if it is possible to use the Progress Monitor Window from Eclipse in my standalone application. For clarification: I'm speaking of this:
and not the ProgressMonitorDialog.
If this is not easily achievable, what would be an easy way to implement this for my own?

You can try using this:
Dialog.getBlockedHandler().showBlocked(IProgressMonitor, IStatus, String)
I have used it in the past to show that a job of mine needs to wait for another job to complete.

I think this dialog is org.eclipse.ui.internal.progress.ProgressMonitorJobsDialog
Although you won't be able to use it directly, you could download the source from Eclipse.org or via the Source link on this page:
http://javasourcecode.org/html/open-source/eclipse/eclipse-3.5.2/org/eclipse/ui/internal/progress/ProgressMonitorJobsDialog.html

Refreshing Swing application with Eclipse/MyEclipse

Say that we are writing a Java Swing application and we use Eclipse or MyEclipse to develop it. In web applications, you make code changes, you save and your ant deployment file takes care of the deployment of the changed files. Then you just refresh or hard refresh the web page and the changes appear there. Can we do the same thing for a Swing applications so that we don't have to close and open the program from the beginning every time we make a change?

I don't think so because you need hot code replacement ! Maybee using another framework.

You can't simply do that because once JVM is started, it loads the class files once and will not reload it untill next loading request. But you can use ClassLoader to load modified class files dynamically.
The following two articles may help:
IBM article on "hot class swap"
"Who Said Runtime Class Reloading Is Hard in Java?"
The first one is in Chinese, but you can look at the code and the result. I think the second article is more helpful for a GUI application.

In MyEclipse you can start your application in debug mode instead of run mode and changes you make will be pushed to the target VM; if changes you make cannot be replaced you'll see a dialog informing you the replace failed and you will need to restart your application. You don't need to place any breakpoints in the application, just starting in debug mode is sufficient.
As Guillaume states above, changes to the class structure will typically not be hot-synched, but changes within existing methods should be fine.
Obviously, how successfully hot-synched changes affect your running application would depend on your application design.

Multiple Swing event-dispatch threads

I would like to create a new event-dispatch thread in Swing, and I'm having trouble finding any references online for how to do this. I have done this in .NET by creating a new thread and calling Application.run(...). Has anyone done this? Is it possible in Swing?
FYI the reason I am trying to do this is because I am writing an Eclipse plug-in, and I would like to pop up dialogs that are not modal to the IDE but that are modal (blocking) to my UI logic. I could accomplish this using non-modal dialogs and callbacks, but that requires the overhead of making my code multi-threaded. I'll revert to that if the former is not possible.

Yes, it's possible. I've have done such multiple EDT dispatch threads logic in Swing. However, net result was that it didn't work reliably.
(a) All JVMs don't work nicely with multiple EDT threads (synchronization problems in graphics rendering logic in native code and such, IBM JVM failed with multiple EDT threads, Sun JVM & Apple JVM did work)
(b) Swing rendering logic has few bugs causing that random rendering errors will occur (for example, http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6727829).
Anyway, doing this requires basically establishing two AppContexts, which each have their own EDT thread.

I'm a little confused by your question, because you mention Swing but then say you are writing an Eclipse plugin. Since the question is tagged Swing, I'll give a Swing answer (but posted as CW).
There is one event dispatch thread. There is always one event dispatch thread, unless there is none at all. You cannot create another one.
You can, however, change the ModalityType of your dialogs, or change the ModalExclusionType of a window. In this case, if you were writing this all yourself, you would set your top-level window's ModalExclusionType to APPLICATION_EXCLUDE.
But again, I don't see how this could help you, since Eclipse uses SWT instead of Swing.

I'm going to junk my last answer and start anew.
In SWT, you can create Shells (windows) or custom Dialogs that are modal just to the parent by passing the SWT.PRIMARY_MODAL style flag during creation.
Note that Dialog is an abstract class, so you'd have to create your own. It's probably just easier to use Shell.
Edit:
Why SWT? Because that's what Eclipse uses. See: Eclipse Platform Plug-in Developer Guide (zipped PDF) for more details. The most recent version is available in Eclipse's Help system (Help > Help Contents > Plug-in Development Environment Guide.)