United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: 4229200 Immutable objects
4229200 : Immutable objects

Details
Type:
Enhancement
Submit Date:
1999-04-13
Status:
Closed
Updated Date:
2006-11-20
Project Name:
JDK
Resolved Date:
2006-11-20
Component:
specification
OS:
generic
Sub-Component:
language
CPU:
generic
Priority:
P4
Resolution:
Duplicate
Affected Versions:
1.2.1
Fixed Versions:

Related Reports
Duplicate:
Relates:
Relates:

Sub Tasks

Description
Name: dbT83986			Date: 04/13/99


It would be real cute to be able to mark objects as being
Immutable (as per Strings). This means that the internal
state is not permitted to change after creation. This would
allow extra optimisations at compile time. It would then be
useful to mark objects as being Primitive objects. Only
Immutable objects should be allowed to be Primitive. Primitive
objects would have the property that if a == b, then a.equals(b)
is also true (ie the object reference is formed from the object's
internal state such that two objects with the same internal state
are actually the same object - hence the need for Immutability).

i.e.
public interface Immutable {}
public interface Primitive extends Immutable {}

Then

int, long, float, double, short, char, byte, boolean
     are all Primitive
String
     is Immutable (and should be Primitive).

You see that Primitive types are the only types that can be
dealt with properly at compile time. It would also be nice
to re-introduce the const keyword, marking any object 
instance as immutable (not the class) for things like
constants and parameters!!!!
(Review ID: 56888) 
======================================================================

                                    

Comments
EVALUATION

4617197 is authoritative on this topic.
                                     
2006-11-20
WORK AROUND



Name: dbT83986			Date: 04/13/99


Java 3 I guess!!! P.S. do get some mathematicians to help you
next time around. After all, you do want a language with some
rigour to it.
======================================================================
                                     
2004-06-11
EVALUATION

Various proposals of this sort have been bandied about in the past,
and may be considered if a time arises where major language
changes are on the table, particularly in support of numeric programming.
See also 4069541 and 4213096.  Reassigned to java/specification.

william.maddox@Eng 1999-05-03

I have little to add, except that Bill is being too kind to this proposal.


gilad.bracha@eng 1999-05-04
                                     
1999-05-03



Hardware and Software, Engineered to Work Together