Release: merlin

Problem: (BugID 4405674)
  Specification of DropTargetListener.drop() is too difficult to implement

The current specification of
DropTargetListener.drop(DropTargetDropEvent) permits an application to
initiate a data transfer operation between the DragSource and the
DropTarget without completing that operation before returning from the
method. This capability has never been properly implemented in any Sun
implementation of the Java 2 SDK. Currently, delayed drop data
transfer works correctly only when the DragSource and DropTarget are
located in the same VM. If an application attempts delayed data
transfer with a DragSource in a different process,
Transferable.getTransferData(DataFlavor) will throw an
InvalidDnDOperationException.

We have developed two different approaches for implementing this
capability. Both of these approaches suffer from serious drawbacks.


(1)

We can pre-fetch all of the data available from the DragSource as soon
as the application declares that the drop is successful. This data
would be stored in the local VM and would be available for the life of
the Transferable which encapsulates it. Instead of fetching data in a
particular flavor when the application calls
getTransferData(DataFlavor), the Transferable would simply return a
copy of the data it has already gathered.

Unfortunately, this would defeat one of the nice features of the Drag
& Drop implementation. Currently, we only request data on-demand, when
the application itself wants it. Depending on the amount of data
available from the drag source, and, on X11, the speed of the X
connection, this can be a huge performance savings. For example, say a
DragSource contains a 100 K text document, and also a 2 MB Pixmap
picture which accompanies the document. If the DropTarget can only
handle text data, there is no reason to transfer more than 100 K of
data. Indeed, on a slow X connection, this could be a real problem.


(2)

We can keep the native data transfer pipe open after drop()
returns. This is certainly possible, and indeed, with a better AWT
architecture, we would agree to it.

Without a rearchitecture, however, we would face the following
problems:

(a)

The change would severely impact the robustness of the Drag & Drop
code (and it's not very robust now). With this change, it would be
very easy to write an application that would deadlock or crash the
VM. For example, client code could save off a reference to the
DropTargetDropEvent and then use that reference later to attempt to
transfer data on a different thread. The current implementation
assumes that data will be transferred on the event dispatching
thread. Accommodating this use case would make the Drag & Drop
synchronization scheme overly complicated and probably unstable.

(b)

At the end of a Drag & Drop operation, further operation of the AWT is
suspended until the application calls dropComplete(). We do not
believe it is possible under the current AWT architecture to avoid
this restriction. Since the API requires that the application complete
data transfer before calling dropComplete(), the entire AWT (that is,
the application's entire GUI) would be unusable until the end of the
data transfer.


Given that neither (1) nor (2) is tenable, we propose to remove this
documented, but unimplemented, capability from the specification.


Requesters:

Drag & Drop (Danila Sinopalnikov)


Proposed API change:

New specification of DropTargetListener.drop(DropTargetDropEvent)
(relevant section is noted with '>>'):

    /**
     * The drag operation has terminated
     * with a drop on this <code>DropTarget</code>.
     * This method is responsible for undertaking
     * the transfer of the data associated with the
     * gesture. The <code>DropTargetDropEvent</code>
     * provides a means to obtain a <code>Transferable</code>
     * object that represents the data object(s) to
     * be transfered.<P>
     * From this method, the <code>DropTargetListener</code>
     * shall accept or reject the drop via the
     * acceptDrop(int dropAction) or rejectDrop() methods of the
     * <code>DropTargetDropEvent</code> parameter.
     * <P>
     * Subsequent to acceptDrop(), but not before,
     * <code>DropTargetDropEvent</code>'s getTransferable()
     * method may be invoked, and data transfer may be
     * performed via the returned <code>Transferable</code>'s
     * getTransferData() method.
     * <P>
     * At the completion of a drop, an implementation
     * of this method is required to signal the success/failure
     * of the drop by passing an appropriate
     * <code>boolean</code> to the <code>DropTargetDropEvent</code>'s
     * dropComplete(boolean success) method.
     * <P>
>> * Note: The data transfer should be completed before the call to the
>> * <code>DropTargetDropEvent</code>'s dropComplete(boolean success) method.
>> * After that, a call to the getTransferData() method of the
>> * <code>Transferable</code> returned by
>> * <code>DropTargetDropEvent.getTransferable()</code> is guaranteed to
>> * succeed only if the data transfer is local; that is, only if
>> * <code>DropTargetDropEvent.isLocalTransfer()</code> returns
>> * <code>true</code>. Otherwise, the behavior of the call is
>> * implementation-dependent.
     * <P>
     * @param dtde the <code>DropTargetDropEvent</code>
     */


API reviewed and approved by:

David Mendenhall


Implementation:
   - Engineer who made (or will make) the changes: Danila Sinopalnikov
   - Date at which changes will be complete: Immediately
   - Number of lines of new or modified code:
        None. We are changing the specification to conform to the existing
        implementation.
   - Code reviewed (or will be reviewed) by: N/A


Risk assessment:

Very low.

No risk for developers working from Sun's implementations. The delayed
data transfer capability never worked, so no developers could be relying
on the current specification.

However, developers using clean-room implementations, or
implementations from licensees, which have implemented delayed data
transfer may be affected. They may have assumed that Sun was going to
implement this missing capability in a future release. However, we
suspect the number of such implementations is zero, and even if such
an implementation exists, it is unlikely any developers would have
relied upon such an assumption.


SQE (product testing) impact:

TBD


JCK (compatibility testing) impact:

TBD


Doc impact:

javadoc changes only.


Localization impact:

None.


Internationalization impact:

None.


Security impact:

None.


Legal impact:

None.


For feature changes, Product Marketing approval:

N/A