<AWT Dev> Patch feedback?
Alexey.Utkin at Sun.COM
Tue Feb 9 10:20:43 PST 2010
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
> 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
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
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
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
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
There is no way to implement asynchronous data provider for the system,
I am agree that it is a good idea to extend Data Flavors list by
standard URL list,
but it is another hard question.
-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:
More information about the awt-dev