aspose file tools*
The moose likes Java in General and the fly likes I need help regarding java.io.File vs sun.awt.shell. Win32ShellFolder2 Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of JavaScript Promises Essentials this week in the JavaScript forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "I need help regarding java.io.File vs sun.awt.shell. Win32ShellFolder2" Watch "I need help regarding java.io.File vs sun.awt.shell. Win32ShellFolder2" New topic
Author

I need help regarding java.io.File vs sun.awt.shell. Win32ShellFolder2

Clark Johnson
Greenhorn

Joined: Mar 08, 2007
Posts: 20
When I try to save a file in a directory containg a file of the same name, the type of the "f" File (the file to be written) changes from java.io.File to sun.awt.shell.Win32ShellFolder2. Notice that if a file of the same name does not exist, the type remains of the file remains java.io.File.

I have tried deleting the existing file via the File instance method delete(), but the problem remains.

I just want to know why the file type changes depending on this seemingly "external" event. Does anyone know?

Feel free to run the code below.

Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18879
    
    8

My guess: Sun's code uses different classes to represent files that exist versus files that don't exist. But that's just a guess. Why do you describe it as a "problem"?
Ernest Friedman-Hill
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24187
    
  34

The Sun class has to be a subclass of java.io.File, so any code you write should be able to stay ignorant of the difference. You'll find the same sort of thing happening in many libraries and APIs, from Sun and from other vendors. Don't worry about it.


[Jess in Action][AskingGoodQuestions]
Clark Johnson
Greenhorn

Joined: Mar 08, 2007
Posts: 20
This is problematic because I need to send that File over to a method that will not work if I send it a reference to a sun.awt.shell.Win32ShellFolder2 object. I'm not sure I am allowed to modify the "public void create(File f)" method to accomodate for this File subclass. A way to solve the problem is to call the create method this way: "create(new File(f.getAbsolutePath()));"

But that still leaves me clueless as to how this instance became an instance of a subclass of the File class. Does anyone know?


[ March 14, 2007: Message edited by: Clark Johnson ]
Alan Moore
Ranch Hand

Joined: May 06, 2004
Posts: 262
If your create() method took a File argument instead of an Object, you wouldn't have noticed this "problem". If you really have to declare it as an Object, you can verify its type this way: That's the standard idiom for checking the runtime type of an object; what you're doing is a hack.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Clark, you are wrong in one important aspect: casting a sun.awt.shell.Win32ShellFolder2 to a java.io.File should work without any problems.


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Clark Johnson
Greenhorn

Joined: Mar 08, 2007
Posts: 20
Originally posted by Alan Moore:
If your create() method took a File argument instead of an Object, you wouldn't have noticed this "problem". If you really have to declare it as an Object, you can verify its type this way: That's the standard idiom for checking the runtime type of an object; what you're doing is a hack.



You are right. (f instanceof File) works!

Thanks
[ March 16, 2007: Message edited by: Clark Johnson ]
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Clark, why does your create method take an Object instead of a File in the first place?
Clark Johnson
Greenhorn

Joined: Mar 08, 2007
Posts: 20
Originally posted by Ilja Preuss:
Clark, why does your create method take an Object instead of a File in the first place?


As I hinted in my first message, the sample code I posted just captures the essence of what the program I am working on does.

In my program, when you click on the Save button, a JFileChooser pops up on the screen and asks you to save your file (usually a txt or an html file). You choose the file where you want to save your work, but this file normally does not exist, so you have to create it. The program calls a method, named Print, which takes a String and an Object as parameter: . This method uses a BufferedWriter to write the String on the File. So far so good, if that's all the print method did (I know I called it "create" in the example, but that was for illustration purposes). In actuality, the print method does more than just "print" text to files. It also prints text to JTextAreas, JTextFields, and the console (specified by a PrintStream, the default being System.out). "Object" is then necessary, as I might be calling the print method using a File, JTextArea, JTextField or a PrintStream as a parameter. If I call the print method with a reference to a String and some unspecified Object , then the program will throw an exception.

Having a single print method that works with all these types makes my life easier. Don't you think?
[ March 16, 2007: Message edited by: Clark Johnson ]
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18879
    
    8

Originally posted by Clark Johnson:
Having a single print method that works with all these types makes my life easier. Don't you think?
If the method contains "if x instanceof File" and the like all over the place, then I would say no. I would provide a group of overloaded methodsThen the compiler can decide which one to call and (more important) it can tell at compile time that you are passing an object that can't be printed on.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: I need help regarding java.io.File vs sun.awt.shell. Win32ShellFolder2