Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 313094

Summary: Delete deprecated IResource#isReadOnly API
Product: [Eclipse Project] Platform Reporter: Szymon Brandys <Szymon.Brandys>
Component: ResourcesAssignee: Platform-Resources-Inbox <platform-resources-inbox>
Status: CLOSED DUPLICATE QA Contact:
Severity: normal    
Priority: P3 CC: markus.kell.r, Mike_Wilson
Version: 3.6Keywords: api
Target Milestone: ---Flags: Szymon.Brandys: review? (john.arthorne)
Hardware: All   
OS: All   
Whiteboard:

Description Szymon Brandys CLA 2010-05-17 05:35:27 EDT 
IResource#isReadOnly API was marked deprecated during 3.1 in favor of a more general API IResource#getResourceAttributes(), see bug 26100. It should be removed according to the deprecation policy.

The specific API to be removed includes: 

org.eclipse.core.resources.IResource#setReadOnly
org.eclipse.core.resources.IResource#isReadOnly
Comment 1 John Arthorne CLA 2010-05-17 09:13:55 EDT 
I'm not convinced about deleting this one. I found 30+ references to it in the Eclipse SDK alone, so clearly it is heavily used and will cause migration pain for clients. One concern is that the equivalent of:

boolean result = resource.isReadOnly()

Using the new API is:

boolean result = false;
ResourceAttributes attrs = resource.getResourceAttributes();
if (attrs != null)
  result = attrs.isReadOnly();

Since the equivalent code with the new API is much longer, clients still use the old method as a convenience. So, unless we can argue that the old method produces a result that is misleading or wrong in some cases, I think we should keep it.
Comment 2 Szymon Brandys CLA 2010-05-17 11:57:56 EDT 
So maybe we should remove the @deprecated flag. Instead we should say that this is a convenience method as we already do in some other cases.
Comment 3 Markus Keller CLA 2015-03-12 14:18:51 EDT 

*** This bug has been marked as a duplicate of bug 208982 ***