In order to add custom data transfer support to a JComponent, a developer must write a custom TransferHandler and call setTransferHandler on the component. Swing's UI classes provide a default TransferHandler that does the most common thing for some of the components (import/export of text in text components for example).

One of the problems that we're seeing is that it is too difficult for developers to *add* handling of additional data flavors on top of the defaults provided by Swing. For example, if a developer wanted to customize a JTextField to accept drops of colors they would write a custom TransferHandler and set it using setTransferHandler. The problem is that this then wipes out the default support (import/export of text). In order to overcome this, the developer would need to *copy* a whole bunch of TransferHandler code from BasicTextUI.

Another approach that I've considered suggesting is to write a TransferHandler that can wrap an existing TransferHandler and delegate where necessary. This would allow the new TransferHandler to handle flavors that it recognizes and delegate the rest. The problem with this approach is that two methods that we'd need to delegate to (createTransferable and importDone) are protected.

We should find a way to allow developers to provide additional support without clobbering the default. Possibilities include:

- making createTransferable and importDone public to allow delegation
- moving the default TransferHandler implementations somewhere where they can be subclassed
- allowing multiple TransferHandlers