• Post Reply Bookmark Topic Watch Topic
  • New Topic

Why setReadOnly() but no way to make it writeable again? What's the work-around?

 
Robert Paris
Ranch Hand
Posts: 585
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Why does Java only have setReadOnly() for files? There's no way to give a file access again. This is ridiculous and completely unacceptable! It's still this way in JRE 1.4!! Is there a workaround for this? I need a cross-platform solution.
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Apparently they're going to address this as part of a larger set of improvements to the filesystem interface. It wouldn't really be enough to say setReadOnly(false) - we should have a way of specifying who can read or write a file. Apparently they were working on this for 1.4, but decided to drop it from that release due to lack of manpower at the time. I guess we just have to hope that 1.5 contains the improvements.
The only cross-platform workaround I see is that you can copy the original file to another file, delete the original, and then rename the new file to the old name. The problem is that some operating systems may prevent you from deleting a file you no longer have write access to.
 
Robert Paris
Ranch Hand
Posts: 585
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Any idea why this was left out originally? It makes no sense to me as it forces the developer to use NON-cross-platform methods to solve this problem.
I need this option, so now I have to write native code to solve it (the delete action is not safe enough since it's not guaranteed to work on all OS's). I can't figure out the thinking behind it and why more developers haven't been up in arms about it. I mean we're in Java 1.4 and it still isn't possible?
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Any idea why this was left out originally?
I'm not sure, but "because someone was on crack" does come to mind.
More seriously, there were a number of corners cut in getting the first couple releases of Java out the door. A lot of code got written in a short time, and some mistakes were made. Most were patched up nicely in subsequent releases. What's unusual her is not that the original API was underdeveloped, but that the problem has remained as long as it has. I'm guessing the reasons for this are (a) providing a good solution (as opposed to a hack) is more complex than it appears, and (b) not that many users have actually found themselves in situations where it was a problem. Not that that's much consolation to the few who do have a problem.
 
Robert Paris
Ranch Hand
Posts: 585
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I wonder if this is related to why Java is not very viable (or considered viable) as a desktop solution. What I mean is that areas such as this file handling feature were not given much thought or man-power, as a result Java ended up being passed over when companies were seeking to make desktop applications. It's a shame.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!