<AWT Dev> Patch feedback?

[Alexey Utkin]

On 2/3/2010 21:52, Damjan Jovanovic wrote:
> On Wed, Feb 3, 2010 at 5:52 PM, Denis S. Fokin<Denis.Fokin at sun.com>  wrote:
>    
>> Hi Damjan,
>>      
> Hi Denis
>
>    
>> as for the Windows-specific part, as I know, the similar functionality has
>> been implemented in the next changeset
>>
>> http://hg.openjdk.java.net/jdk7/awt/jdk/rev/fd5bf5955e37
>>      
> IMO it's quite dangerous to implicitly convert FILEDESCRIPTOR +
> FILECONTENTS to temporary files and present them to the caller. If
> someone drags a 100MB file from an FTP server or a directory with
> hundreds of files into Java, you will block the EDT for a long time
> while the files copy. Also AWT allows you to request file contents
> many times before the drop, and you could end up writing many copies
> out, taking time and wasting disk space.
>    
1. The file names are unique. We cannot "writing many copies" of file 
content.
2. If application is written in content-observing mode that means that
author is *really* interested in context that *could* be changed by DnD 
source. And content
update is defensible.
3. Applied approach get the chance for former-designed applications to 
be a drop targets for
attachments (the main use-case that was clearly mentioned in bug 
description). For example,
DnD protocol with temp files are used in a cross platform Thunderbird 
mail client.
4. Temp file approach is in consistence with existent security model.
5. AWT message pumping could be blocked in predictable(limited) time manner.

> The different API used in my patch can be asynchronous relative to the
> EDT, and only allows 1 transfer attempt, thus avoiding all those
> problems where possible. It also happens to be usable on *nix's X
> Direct Save and (I suspect) MacOS's promise data flavors, where the
> drop target doesn't get the file contents at all, it just tells the
> drag source where to write out the file(s) and the drag source writes
> them whenever, however, and whatever it likes - something that cannot
> possibly work with javaFileListFlavor.
>
>    

Ovwr the MS Windows your call stack looks like this:

OLE-DnD callback from OS system
------------------
C++ AwtDragSource::GetData
C++ AwtDataTransferer::ConvertData
C++ AwtDataTransferer::ConvertData
------------------
native-to-Java
------------------
DataTransferer::convertData
DataTransferer::translateTransferable
WDataTransferer::transferAbstractFiles
AbstractFile::open() && abstractFile.getPath()

If  the AbstractFile is an interface, here the user code have a 
privileged access to the system.
The fist and the last that you can do here as a hacker - just block AWT 
thread.
Game over.

The key stone of Java Security: never make a sync-call from AWT thread 
to user code.
This rule was broken in your implementation.
That's why the transferred data have to be prepared in Java *before* DnD 
session.
There is no way to implement asynchronous data provider for the system, 
sorry.
I am agree that it is a good idea to extend Data Flavors list by 
standard URL list,
but it is another hard question.

Regards,
-Alexey Utkin aka uta

>> The implementation has not been promoted yet.
>>      
> That patch for dragging with an image looks impressive, nice work!
>
> You might also want to look at a short patch I made to support
> changing the drag cursor:
> https://bugs.openjdk.java.net/show_bug.cgi?id=100121
>