FULL PRODUCT VERSION :
java version "9.0.1" 
Java(TM) SE Runtime Environment (build 9.0.1+11) 
Java HotSpot(TM) 64-Bit Server VM (build 9.0.1+11, mixed mode) 

ADDITIONAL OS VERSION INFORMATION :
Any Windows version

A DESCRIPTION OF THE PROBLEM :
WDataTransferer.translateBytesOrStream puts relative paths on deleteOnExit list which has caused my files (of the same name) to be deleted unexpectedly.

I have worked around this issue by modifying the "files" field in java.io.DeleteOnExitHook using reflection.  The problem is that JDK 9 is starting the process of deprecating reflection.  Therefore my workaround will become an error soon.

This is basically the same problem as:
http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8074212

The above bug was closed without being fixed, so I am still experiencing the underlying problem.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Create a new directory called "Test" with the following files:
    testJavaBug.java
    foo.txt

2. open Command Prompt within this directory

3. Execute the following command in the Command Prompt 
    javac testJavaBug.java

4. Create a compressed directory with "foo.txt" within this directory by selecting "foo.txt", right-clicking, selecting "Send to", and then "Compressed (zipped) folder"

5. Double-click (or right-click > Open) the new .zip folder

6. Right-click on "foo.txt" and select "Copy"

7. Navigate Windows Explorer back to the "Test" directory (this will allow you to see the file disappear on JVM shutdown)

8. Return to the Command Prompt and execute the following line:
    java testJavaBug

9. Notice that the Delete On Exit list (printed to the command line) was populated with a bunch of garbage, including the entry "foo.txt"

10. Notice that the file "foo.txt" was deleted from the "Test" directory

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
1. WDataTransferer.translateBytesOrStream SHOULD NOT add garbage or relative paths to java.io.DeleteOnExitHooks "files" field.

2. Local files should not be deleted even if relative paths do make it into the "files" field of java.io.DeleteOnExitHook.
ACTUAL -
1. Garbage data is added to the "files" field of java.io.DeleteOnExitHook.

2. Local files which share the same name as the garbage in the the "files" field of java.io.DeleteOnExitHook are deleted on JVM shutdown.

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import java.awt.Toolkit;
import java.awt.datatransfer.DataFlavor;
import java.awt.datatransfer.Transferable;
import java.io.File;
import java.util.List;
import java.awt.datatransfer.Clipboard;
import java.lang.reflect.Field;
import java.util.Set;

public class testJavaBug {
    public static void main(String[] args) {
        try {
            // garbage data is added to "files" field in DeleteOnExitHook whether using getTransferData or Clipboard.getData
		
            Transferable transferable = Toolkit.getDefaultToolkit().getSystemClipboard().getContents(null);
            Object data = transferable.getTransferData( DataFlavor.javaFileListFlavor );
         
            // The following will print out the list of files to be deleted on JVM shutdown
            Class c = Class.forName("java.io.DeleteOnExitHook");
            Field f = c.getDeclaredField("files");
            f.setAccessible(true);
            System.out.println((Set<String>)f.get(null));
        
        } catch (Exception exception) {
            exception.printStackTrace();
        }
    }
}
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Currently, I am working around this issue by modifying the "files" field of java.io.DeleteOnExitHook using reflection.