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?
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.
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 ]
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.
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
Joined: Mar 08, 2007
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 ]
Joined: Jul 11, 2001
Clark, why does your create method take an Object instead of a File in the first place?
Joined: Mar 08, 2007
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 ]
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.