JDK-6336887 : Enhance final to provide immutable methods
  • Type: Enhancement
  • Component: specification
  • Sub-Component: language
  • Affected Version: 5.0
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: linux
  • CPU: x86
  • Submitted: 2005-10-14
  • Updated: 2005-10-17
  • Resolved: 2005-10-14
Related Reports
Duplicate :  
Description
A DESCRIPTION OF THE REQUEST :
The notion of avoiding side effects in a object passed into a method could be enforced by allowing child methods to inherit the keyword final from parent methods.  This prevents modification, but because it is not inheritable you can't enforce good code design with this mechanism.

Another mechanism would be to add a new keyword like immutable or modify the meaninf of the keyword final, so that when used would indicate the object being passed in is not to have it's state adjusted by the method in any way.

Immutable objects could not be changed after their construction was complete.

JUSTIFICATION :
The child methods would be restricted to returning a single value, and the use of objects as return values instead of using side effects that modify objects passed in would be encouraged.  In turn this enhances the thread-safeness of code running in a JVM and enables library writers to make certain optomizations (elimination of defensive copying and/or cloning for instance).

This may have implications for the creation of static methods in interfaces.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
<pre>
public class foo{
   public Object doSomething(final Object objectA){
      //No side effects should be able to change the internal state of objectA
   }
}

public class foo2 extends foo{
   public Object doSomething(Object objectB){//Shouldn't compile because ObjectB is not marked final
      //Side effects would be possible of the compiling wasn't prevented.
   }
}

</pre>
If a different keyword is desired, substitute immutable for final in the example above.
ACTUAL -
You can leave the final keyword off the children and things compile just fine.

---------- BEGIN SOURCE ----------
<pre>
public class foo{
   public Object doSomething(final Object objectA){
      //Object A should not be able to be modified
   }
}

public class foo2 extends foo{
   public Object doSomething(Object objectB){//Shouldn't compile because ObjectB is not marked final
      //Object B should be able to be modified, but this should be prevented.
   }
}

</pre>
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
You can create unmodifyable objects with some pain, and use these only as method parameters, but the copiler doesn't enforce it.  This change would help trade runtime or logic errors for compile time errors (much easier to fix).

Comments
EVALUATION While this RFE might not be an exact match of 4211070, it is very similar. It doesn't matter if you call the keyword "const", "immutable", or "final". If this feature isn't the same as 4211070, it represents a subset of 4211070 and the same arguments applies.
17-10-2005