After digging around, googling and receiving tons of help; I've built two workarounds for some of the problems with Swings Drag and Drop (DnD) problems. The first problem with the DnD is the lack of the ability to dynamically create files dynamically when exporting files from a Java program. The second problem with the DnD is that you have to redo already implemented data handling.
These problems comes from design decisions in Swing, and cannot be fixed without tampering with the APIs of the DnD in Swing. Actually the first problem is the one that will have the largest impact on the handling of DnD to the native system. The second can be changed within the current API.
The problem was that all files that are to be DnD from a Java application to the native system, must exist before the action. And there are several areas where this isn't possible. Example the Columba email client, it was not wanted to extract attachments from an email until the user has selected so. FTP applications could just have one file list for the remote server, and then the user could DnD files from the file list to the desktop to start a transfer.
My solution was to create the files during the DnD action, before the actual drop of the file has been initiated. Therefore I came up with the class DynamicFileTransferHandler. This class could be used for any JComponent that wants to export files from Java dynamically. All it needs is a File factory that creates the files during the DnD process. The files can either be created at the start of the DnD or at the very end of it. Well not really the very end, it is actually when the DnD moves over a native application, that is the last known place for the DnD of files.. Check out the webstart demo of the frappucino package. Unfortunately this feature will not be a part of the Swing's DND API for a very long time, and I doubt that it will even go into the SDK 1.6 release. Please note that this solution is good enough but Sun should get their act together and make better support for this type of DnD. I solved the problem for the email application, but for FTP applications this is still unsolvable.
The second problem was that often the developer only wants to add one DnD data flavor to a JComponent. This was not possible with the current API. Some of the methods in the API has protected access, and the DnD API "cheated" by being in the same package. I've now developed a solution that enables a JComponent to have multiple TransferHandlers for importing data. Now you can easily add DnD support of files into a Textarea, and not lose the default DnD implementation. I wonder why nobody has done anything about this problem, because it makes it even more tedious to add DnD import for Swing components. Anyhow my solution is to have a set of transfer handlers that uses the Chain of responsibility design pattern. The class MultipleTransferHandler can have one or more transfer handlers, and will go through the set until it can find one handler that accepts a certain data flavor. Due to the fact that the export methods for TransferHandler are protected and it is impossible to call those without extending the handler or being in the same package, I had to use the reflection API to access those two methods. Due to this "cheat" there are some security issues when using this class, but as long as it is used in one trusted application, this wont be any problem. Now the class will work with one or more transfer handler for importing data flavor, and it still can export flavors from ONE of the transfer handler. Restricting it to one export transfer handler, solved the problem when you have several handlers that export the same data flavor. This may change in the future.. With this bug, I have little faith in that they are going to fix this. The bug/feature request has been around for over one year, with no real answers. Check out the Frappucino demo, it has a demo for this component as well.
BTW, thanks for all the replies from the Java desktop forum and bug lists, I hope that I can help somebody with these Swing objects.