On 2/3/2010 21:52, Damjan Jovanovic wrote:
On Wed, Feb 3, 2010 at 5:52 PM, Denis S. Fokin<[email protected]> 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
