Newsletter sign-up
View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

JavaWorld.com

Practice makes perfect

Experience is often your best defense against Java pitfalls

By Michael C. Daconta, JavaWorld.com, 11/16/01

  • Print
  • Feedback
.

Page 7 of 9

E:\classes\com\javaworld\jpitfalls\article5>java com.javaworld.jpitfalls.article5.BadFileRename
dummy.txt exists.
Rename to existing File Failed.
path: E:\classes\com\javaworld\jpitfalls\article5
new name: E:\classes\com\javaworld\jpitfalls\article5\dummy.tst
Rename to new extension Successful.
Delete Failed.
Rename to new Drive Successful.


Listing 11.1 raises three specific issues, which are called out in the code comments. At least one is accurately characterized as a pitfall; the others should be considered poor design:

  1. First, returning a boolean error result does not provide enough information about the failure's cause. That proves inconsistent with exception use in other classes and should be considered poor design. For example, the failure above could have been caused by either attempting to renameTo() a file that already exists or attempting to renameTo() an invalid file name. Currently, we have no way of knowing.
  2. The second issue is the pitfall: attempting to use the initial File object after a successful rename. What struck me as odd in this API is the use of a File object in the renameTo() method. At first glance, you assume that you only want to change the filename. So why not just pass in a String? In that intuition lies the pitfall's source.

    The pitfall is the assumption that a File object represents a physical file and not a file's name. In the least, that should be considered poor class naming. For example, if the object merely represents a filename, then the object should be called Filename instead of File. Thus, poor naming directly causes this pitfall, which we stumble over when trying to use the initial File object in a delete() operation after a successful rename.

  3. The third issue is File.renameTo()'s different behavior on different operating systems. The renameTo() works on Windows even across filesystems (as shown here) and fails on Solaris (reported in Sun's bug parade and not shown here). The debate revolves around the meaning of Write Once, Run Anywhere (WORA). The Sun programmers verifying reported bugs contend that WORA simply means a consistent API. That is a cop-out. A consistent API does not deliver WORA; there are numerous examples in existing APIs where Sun went beyond a consistent API to deliver consistent behavior. The best-known example of this is Sun's movement beyond the Abstract Windowing Toolkit's consistent API to Swing's consistent behavior. If you claim to have a platform above the operating system, then a thin veneer of an API over existing OS functionality will not suffice. A WORA platform requires consistent behavior, otherwise "run anywhere" means "maybe run anywhere." To avoid this pitfall, check the os.name System property and code renameTo() differently for each platform.


Out of these three issues, we can currently fix only the proper way to delete a file after a successful rename, as Listing 11.2 demonstrates. Because the other two issues result from Java's design, only the Java Community Process (JCP) can initiate fixes for them.

  • Print
  • Feedback

Resources