Suggested change to JLS - immutable class modifier

[BradW]

I am looking for support, and/or suggestions for a change to the Java
Language Specification. I want to add the support for a new class
modifier - immutable.

The idea is that it would be included in the class file and held in
the JVM just like 'public' is. Furthermore, during compilation, the
code would be checked to make sure that all the instance variables are
'final'. Being held in the JVM, it would also make it possible to
make all subclasses 'immutable' as part of the contract.

Check out this link: http://www.java.net/forum/topic/jdk/java-se/jsr-proposal-immutable-class-modifier

What do you think?

[Louis Wasserman]

How are you going to handle arrays?  Marking them final doesn't guarantee that they'll be immutable.

Louis Wasserman
wasserm...@gmail.com
http://profiles.google.com/wasserman.louis

--
guava-...@googlegroups.com
Project site: http://guava-libraries.googlecode.com
This group: http://groups.google.com/group/guava-discuss

This list is for general discussion.
To report an issue: http://code.google.com/p/guava-libraries/issues/entry
To get help: http://stackoverflow.com/questions/ask (use the tag "guava")

[cowwoc]

Hi Brad,

Wouldn't an annotation be a better fit?

Gili

[Maaartin G]

On Monday, July 11, 2011 10:09:08 PM UTC+2, Louis Wasserman wrote:

How are you going to handle arrays?  Marking them final doesn't guarantee that they'll be immutable.

The same problem occurs for all member variables having any mutable state like e.g. List. All such member need a guarantee to be never modified. With access to global variables and external state a mutable class may be simulated even when all its members are final and immutable (simply move all the mutable state into a global variable (possibly ThreadLocal) or somewhere else (consider File.remove()). Unlike for "final", it's hard to define "immutable" in a concise way.

Btw., there's already a reserved word for this in Java ("const").  

On Monday, July 11, 2011 11:00:48 PM UTC+2, Gili Tzabari wrote:

 Wouldn't an annotation be a better fit?

I don't think so. If we had a good definition of "immutable" then it should became a part of the language. Annotations are just a hack for defining things missing in the language. However, I doubt if there's any definition of "immutable" worth it.

[Raymond Rishty]

Expect resistance adding reserved words. It seems clear that all fields in an immutable class would have to be immutable (and labelled as such). You'd have the compiler complain if there is a field of type "List" and not "ImmutableList". Arrays would be forbidden

[Raymond Rishty]

On the other hand, JSR305 annotations like @NotNull are great for enforcing constraints via the IDE (e.g., IntelliJ) or static analysis tool (e.g., FindBugs). You could have a useful and successful thing going on without changing the language.

[Craig Berry]

I don't think it's reasonable to expect that deep immutability could
be enforced in this way, given how Java works. Surface immutability
would be very useful in its own write. Just declare the class
immutable, and all members are required to be final, and all
subclasses must also be immutable.

--
Craig Berry
Software Engineer
Google (Santa Monica CA)

[BradW]

Firstly, have you looked at my link in the original posting?

Secondly, as far as the arrays, etc., have a look at this link:
http://www.javamex.com/java_equivalents/const_java.shtml

Also, the idea is to Keep It Simple Stupid (KISS).  :-)

No disrespect intended.  I'm just saying that by having it there in the JLS, and forcing the final on
instance variables and forcing all subclassesto be immutable, it will help the process.  Then the
programmer, and library class user will be able to go from there.  Such as suggested in the link above.

[BradW]

OK guys here's an example of what I'm on about:

// File: AnImmutableClass.java

//~--- JDK imports ------------------------------------------------------------

import java.util.Arrays;
import java.util.Collections;
import java.util.List;

//~--- classes ----------------------------------------------------------------

/**
 * This class is immutable
 * @author Brad Willcott
 */

public immutable class AnImmutableClass {

    public final List< Data > dataList;

    /** Length of object */
    public final int length;

    /** Width of object */
    public final int width;

    /** Height of object */
    public int height;

    //~--- constructors -------------------------------------------------------

    /**
     * Constructs a new AnImmutableClass object.
     *
     * @param height of object
     * @param width of object
     * @param length of object
     */
    public AnImmutableClass(final int height, final int width, final int length, final Data[] dataArray) {
        this.height = height;
        this.length = length;
        this.width  = width;
        dataList    = Collections.unmodifiableList(Arrays.asList(dataArray));
    }

    //~--- inner classes ------------------------------------------------------

    public static immutable class Data {

        final String name;
        final int    age;
        final long   time;

        //~--- constructors ---------------------------------------------------

        public Data(final String name, final int age, final long time) {
            this.name = name;
            this.age  = age;
            this.time = time;
        }
    }
}

If you need full in-depth immutability, then you will have to work for it, by wrapping the mutable classes
in immutable classes.  However, with the immutable class modifier you'll be able to force some
compliance, both on yourself, and those others using you classes.

Oh, by the way, I tried the annotation approach, by it is not going to work because you cannot enforce
compliance on other users who subclass your @Immutable class.  Even keeping tract of this in your
own code can be a problem.  Unless it is in the JLS, it won't work.

[Raymond Rishty]

If you can subclass it, it's not immutable anyway--Immutable classes ought to be final (see, e.g. Effective Java, Item 13).

[Graham Allan]

Hi,

I hope the group doesn't mind me posting links to my own hobby project, and kinda going off-topicbut some folks on the list may be interested in this:

http://code.google.com/p/mutability-detector/

It's a static analysis tool for enforcing immutability. A feature that may be particularly compelling is using a unit test to specify and check that instances of a given class are immutable. It is still very raw; as others have alluded to it's a tough challenge just coming up with a shared definition of immutable, never mind enforcing that in static analysis (even java.lang.String has a non-trivial immutable implementation).

It won't be the same as enforcing it at the JVM label, particularly the requiring of it for subclasses, but I thought some of you may be interested.

Regards,
Graham

[BradW]

On Tuesday, July 12, 2011 6:42:29 AM UTC+8, Raymond Rishty wrote:

If you can subclass it, it's not immutable anyway--Immutable classes ought to be final (see, e.g. Effective Java, Item 13).

I disagree with Effective Java in that respect.  I believe it is quite acceptable to be able to subclass an immutable class.
After all, what is it we are trying to do?  I believe we are trying to protect the data from being changed.  That is the
purpose of the classes that would benefit from being immutable.  So, if that be the case, then by forcing all instance
variables to be final, we achieve this purpose.  Therefore, sub-classing is not a problem, as long as the sub-class is
forced into also being immutable, ad infinitum. 

[BradW]

Your mutability detector might be alright in a production environment where its use is enforced,
however, if you produce a class library for public use, then you have no way of enforcing
compliance in other environments.

If we have immutable classes, then compliance is automatically enforced, no matter the
environment that your class library is used in.

[Maaartin G]

On Monday, July 11, 2011 11:50:39 PM UTC+2, Raymond Rishty wrote:

Expect resistance adding reserved words. It seems clear that all fields in an immutable class would have to be immutable (and labelled as such). You'd have the compiler complain if there is a field of type "List" and not "ImmutableList". Arrays would be forbidden

This wouldn't work. The ImmutableList must be immutable, but it itself (I mean RegularImmutableList here) contains an array (whose elements can't be changed since it's private and the ImmutableList itself dosn't do it). I mean, the things are quite complicated, even when trying to simplify hard.

On Monday, July 11, 2011 11:58:29 PM UTC+2, Craig Berry wrote:

I don't think it's reasonable to expect that deep immutability could
be enforced in this way, given how Java works. Surface immutability
would be very useful in its own write. Just declare the class
immutable, and all members are required to be final, and all
subclasses must also be immutable.

As I wrote above, this is too restrictive. This way you could get hardly any immutable class (even ImmutableList contains a mutable member).

On Tuesday, July 12, 2011 1:03:17 AM UTC+2, BradW wrote:

On Tuesday, July 12, 2011 6:42:29 AM UTC+8, Raymond Rishty wrote:

If you can subclass it, it's not immutable anyway--Immutable classes ought to be final (see, e.g. Effective Java, Item 13).

I disagree with Effective Java in that respect.  I believe it is quite acceptable to be able to subclass an immutable class.

IMHO, you both are right. In current Java, by allowing subclassing you'd lose immutability. If the JVM knew about the immutability concept, it could enforce   immutability on subclasses, too.

[morten hattesen]

Requiring all fields to be final would prevent java.lang.String from
qualifying as an immutable class.
Even though it is "effectively immutable", the hashCode is lazily
initialized, making it formally mutable.

Defining immutability is like nailing Jello to the wall.

/Morten

On Jul 11, 11:58 pm, Craig Berry <cbe...@google.com> wrote:
> I don't think it's reasonable to expect that deep immutability could
> be enforced in this way, given how Java works. Surface immutability
> would be very useful in its own write. Just declare the class
> immutable, and all members are required to be final, and all
> subclasses must also be immutable.
>
> On Mon, Jul 11, 2011 at 2:50 PM, Raymond Rishty
>
>
>
>
>
>
>
>
>
> <raymond.ris...@gmail.com> wrote:
> > Expect resistance adding reserved words. It seems clear that all fields in
> > an immutable class would have to be immutable (and labelled as such). You'd
> > have the compiler complain if there is a field of type "List" and not
> > "ImmutableList". Arrays would be forbidden
>

> > On Mon, Jul 11, 2011 at 5:08 PM, Maaartin G <grajc...@seznam.cz> wrote:
>
> >> On Monday, July 11, 2011 10:09:08 PM UTC+2, Louis Wasserman wrote:
>
> >>> How are you going to handle arrays?  Marking them final doesn't guarantee
> >>> that they'll be immutable.
>
> >> The same problem occurs for all member variables having any mutable state
> >> like e.g. List. All such member need a guarantee to be never modified. With
> >> access to global variables and external state a mutable class may be
> >> simulated even when all its members are final and immutable (simply move all
> >> the mutable state into a global variable (possibly ThreadLocal) or somewhere
> >> else (consider File.remove()). Unlike for "final", it's hard to define
> >> "immutable" in a concise way.
> >> Btw., there's already a reserved word for this in Java ("const").
>
> >> On Monday, July 11, 2011 11:00:48 PM UTC+2, Gili Tzabari wrote:
>
> >>>  Wouldn't an annotation be a better fit?
>
> >> I don't think so. If we had a good definition of "immutable" then it
> >> should became a part of the language. Annotations are just a hack for
> >> defining things missing in the language. However, I doubt if there's any
> >> definition of "immutable" worth it.
>
> >> --
> >> guava-...@googlegroups.com
> >> Project site:http://guava-libraries.googlecode.com
> >> This group:http://groups.google.com/group/guava-discuss
>
> >> This list is for general discussion.
> >> To report an issue:http://code.google.com/p/guava-libraries/issues/entry

> >> To get help:http://stackoverflow.com/questions/ask(use the tag "guava")

>
> > --
> > guava-...@googlegroups.com
> > Project site:http://guava-libraries.googlecode.com
> > This group:http://groups.google.com/group/guava-discuss
>
> > This list is for general discussion.
> > To report an issue:http://code.google.com/p/guava-libraries/issues/entry

> > To get help:http://stackoverflow.com/questions/ask(use the tag "guava")

[BradW]

On Tuesday, July 12, 2011 8:25:11 AM UTC+8, morten hattesen wrote:

Requiring all fields to be final would prevent java.lang.String from
qualifying as an immutable class.
Even though it is "effectively immutable", the hashCode is lazily
initialized, making it formally mutable.

What would be the 'cost' of changing that?  Why not have it calculated on instantiation?

Defining immutability is like nailing Jello to the wall.

I don't think so.  What is the goal of immutability?  Protecting the internal data of a class.  Right?
Well, as I've described it, that is achievable.

Oh, and as a side benefit, we can do away with those dam getter methods, and make the
instance variables public, since they'll all be final.

 

[Jed Wesley-Smith]

The cost is adding the expense of the hashCode function to String construction. As most Strings (particularly the big ones) aren't compared or used as keys and the hashCode function is O(n) where n is the length of the String, this could be a significant (as in noticeable) unnecessary overhead. For more details of this kind of thing see: http://jeremymanson.blogspot.com/2008/12/benign-data-races-in-java.html

We really really _don't_ want to get rid of accessor methods, even on final immutable classes. There are still benefits having the binary link to an accessor method rather than the field, particularly if you are creating public API, as you can change the implementation and remain binary compatible. The JIT is quite capable of removing any method calls and inlining as it sees fit anyway so the only thing you save is typing out the method definition. If you really don't like doing that I suggest you look at a language like Scala that removes the need entirely.

[Graham Allan]

On 12 July 2011 00:10, BradW <br...@willcott.com> wrote:

Your mutability detector might be alright in a production environment where its use is enforced,
however, if you produce a class library for public use, then you have no way of enforcing
compliance in other environments.

Just because it uses static analysis doesn't mean it cannot be used at runtime - you could inspect parameters to your library, and their runtime class, the way you would inspect a reference for nullness. That would enforce compliance in any environment. Performing the analysis is obviously not zero cost, but it only needs to be done once per class per execution, which is manageable in a lot of enviroments.

If we have immutable classes, then compliance is automatically enforced, no matter the
environment that your class library is used in.

How about environments using a previous version of Java? Would the keyword essentially cut you off from being binary compatible?

Again, not saying static analysis (or my own project) is anywhere  near as powerful as a compiler/bytecode enforced keyword, but if you have a pressing need for this behaviour today, it may be worth a look.

Regards,
Graham

[BradW]

On Tuesday, July 12, 2011 10:51:38 AM UTC+8, Jed Wesley-Smith wrote:

The cost is adding the expense of the hashCode function to String construction. As most Strings (particularly the big ones) aren't compared or used as keys and the hashCode function is O(n) where n is the length of the String, this could be a significant (as in noticeable) unnecessary overhead. For more details of this kind of thing see: http://jeremymanson.blogspot.com/2008/12/benign-data-races-in-java.html

OK then.  I understand what you are talking about here.  What about another keyword, as a modifier of final:  lazy.

final lazy int hash;

This would allow for your lazy initialization, and allow it to be set only once.  It would complicate things in the JVM, but I think that the results would out way the time
and effort needed to implement the changes.
 

We really really _don't_ want to get rid of accessor methods, even on final immutable classes. There are still benefits having the binary link to an accessor method rather than the field, particularly if you are creating public API, as you can change the implementation and remain binary compatible. The JIT is quite capable of removing any method calls and inlining as it sees fit anyway so the only thing you save is typing out the method definition. If you really don't like doing that I suggest you look at a language like Scala that removes the need entirely.

I agree.  However, I still prefer to avoid them as much as possible, especially when writing internal classes.  That is, classes not to be published or made available outside of my control.
I'm just lazy that way. ;-}

[BradW]

On Tuesday, July 12, 2011 4:30:17 PM UTC+8, Graham Allan wrote:

On 12 July 2011 00:10, BradW <br...@willcott.com> wrote:

Your mutability detector might be alright in a production environment where its use is enforced,
however, if you produce a class library for public use, then you have no way of enforcing
compliance in other environments.

Just because it uses static analysis doesn't mean it cannot be used at runtime - you could inspect parameters to your library, and their runtime class, the way you would inspect a reference for nullness. That would enforce compliance in any environment. Performing the analysis is obviously not zero cost, but it only needs to be done once per class per execution, which is manageable in a lot of enviroments.

That is an option.  However, I am a lazy programmer.  So, I want to do as little as possible to achieve the greatest result.  If by just adding a keyword to my class definition I can achieve the result,
why would I want to add all the extra coding necessary to do what you are suggesting?

If we have immutable classes, then compliance is automatically enforced, no matter the
environment that your class library is used in.

How about environments using a previous version of Java? Would the keyword essentially cut you off from being binary compatible?

That is a problem with ALL upgrades.  You cannot be fully backward compatible with previous versions.  Otherwise, why would you need to upgrade?
The purpose is to gain performance or functionality.  The functionality would not be backward compatible.  If you have a class:

public class MyObject {
   public final String name;
   public final int age;

   public MyObject(final String name, final int age){

      this.name = name;
      this.age = age;
   }
}

and you add the immutable class modifier, then you will have a new type of class.
The downside is a loss of binary compatibility, but the gain is the flow-on benefit
of it being tagged as immutable.

public immutable class MyObject {
   public final String name;
   public final int age;

   public MyObject(final String name, final int age){

      this.name = name;
      this.age = age;
   }
}

Remember, the keyword immutable is written to the class file, and is retained in the JVM when the class
is loaded.  So enforcement is automatic and internal to the JVM.  If implemented properly, even reflection
can be covered, vis-a-vis, enforcement of immutability.

[Jared Bunting]

Here's an example of using an annotation to force a condition on a subclass - and that enforcement happens at compile time.  Will this approach not work for @Immutable ?

http://www.javaspecialists.eu/archive/Issue167.html

--
guava-...@googlegroups.com
Project site: http://guava-libraries.googlecode.com

This group:...

[BradW]

On Tuesday, July 12, 2011 7:34:11 PM UTC+8, Jared Bunting wrote:

Here's an example of using an annotation to force a condition on a subclass - and that enforcement happens at compile time.  Will this approach not work for @Immutable ?

http://www.javaspecialists.eu/archive/Issue167.html

This appears to be a short term possibility, like the  "mutability detector".  Unless it was made universal, it would only be of use in controlled environments.  I still believe it
would be better for the Java Community to have the immutable keyword included in the JLS.  Also, it may be necessary to add another keyword: lazy, as a final instance variable
modifier, as per other comments.

[Graham Allan]

I like the idea in general, I just think it has deeper ramifications than your proposal suggests, and consensus is one of them, unfortunately.

You may also be interested in this: http://bugs.sun.com/view_bug.do?bug_id=4617197

Regards,
Graham

[cowwoc]

In light of the Generics debacle I think people should think
seriously question whether each feature request carries its weight. When
this feature was initially proposed it sounded great, but the more we
discuss it the more complications creep in. I also think that Immutable
classes (as great as they are) make up the minority of classes out
there. Not because they're hard to build, but because they're not
appropriate in most cases (obviously it depends what kind of software
you work on, but in my experience this is certainly true).

Does the benefit (for such a small number of classes) outweigh the
cost?

I like features like @NotNull because I can see myself using it on
the majority of fields and method parameters (let's be honest, the
language's default should really be @NotNull instead of null). As a
side-topic, what ever happened to JSR 303? Is it possible to specify an
annotation on a class-level and have all fields default to @NotNull
instead of having to annotate each one individually?

Gili

> --
> guava-...@googlegroups.com
> Project site: http://guava-libraries.googlecode.com

> This group: http://groups.google.com/group/guava-discuss

>
> This list is for general discussion.
> To report an issue: http://code.google.com/p/guava-libraries/issues/entry

[BradW]

On Wednesday, July 13, 2011 12:47:17 AM UTC+8, Graham Allan wrote:

I like the idea in general, I just think it has deeper ramifications than your proposal suggests, and consensus is one of them, unfortunately.

You may also be interested in this: http://bugs.sun.com/view_bug.do?bug_id=4617197

A lot of interesting issues are raised there.  However, I think that the 'const' controversy is completely separate and therefore not part
of this issue.

The main relevant issues raised, I believe are:

1: Whether or not immutable classes should be final.
2: Whether or not immutable classes with non static variables should be allowed to be sub-classed.
3: Immutability of objects assigned to final instance variables.
4: Immutable arrays.

1: I don't see any reason for forcing immutable classes to being final.  Under the proposal I have made, once all the instance
variables are set final, or final lazy, there would be no problem with a sub-class accessing these variables.  Indeed, some of them,
as appropriate, could be made public.  I know there are issues with that, however, data integrity is not one of them.

2: This issue has I think been covered by my answer to issue '1'.

3: This might be a little harder to implement than my basic proposal, which follows the KISS principle.  However, it should not
be too difficult to have the compiler, initially, and the JVM, subsequently, enforce this requirement.
The JVM would enforce immutability on runtime class creation (reflection) and so forth.

4: I see this issue as just a more specific version of issue '3'.  The solution being much the same, with the added advantage
of the JVM being able insert the immutable object instances directly into the array instead of references to them.  Atleast when
the objects are small enough.

[Ray Conner]

On Jul 11, 7:03 pm, BradW <b...@willcott.com> wrote:
> On Tuesday, July 12, 2011 6:42:29 AM UTC+8, Raymond Rishty wrote:
>
> > If you can subclass it, it's not immutable anyway--Immutable classes ought
> > to be final (see, e.g. Effective Java, Item 13).
>
> I disagree with Effective Java in that respect.  I believe it is quite

> acceptable to be able to subclass an *immutable* class.

> After all, what is it we are trying to do?  I believe we are trying to
> protect the data from being changed.  That is the

> purpose of the classes that would benefit from being *immutable*.  So, if

> that be the case, then by forcing all instance

> variables to be *final*, we achieve this purpose.  Therefore, sub-classing
> is *not* a problem, as long as the sub-class is
> forced into also being *immutable,* ad infinitum.  

That is not quite true. It does prevent the mutation of actual fields,
but it does not prevent the apparent mutation of state from the POV of
an outside observer. For example:

immutable class MyImmutable {
private final int foo = 42;
public int getFoo() { return foo; }
}

immutable class BadImmutable extends MyImmutable {
public int getFoo() { return new Random().nextInt(); }
}

While this example is clearly contrived, it's not difficult to imagine
a malicious subclass.

So, you have to make all declared methods final as well, and probably
most of you inherit from base classes (including from Object).

[BradW]

On Wednesday, July 13, 2011 3:08:39 AM UTC+8, Ray Conner wrote:

 
We need to back to basics, here. What is the purpose of immutability.  I believe it is to guarantee
that data held internally can not be changed.

You could prevent such malicious coding by making certain methods final, but, preventing
sub-classing altogether would be like "throwing the baby out with the bath water".  Are we trying to
prevent someone intentionally writing malicious code, or are we trying to make life easier for
ourselves when it comes to writing code, especially when threading is involved?  I don't think we
need to go to the extreme.  Java is meant to be flexible!  I just want it to be a little bit easier to
achieve good, safe, coding.

[Kevin Bourrillion]

Since this conversation doesn't seem to be dying down....

I don't want to be the jerk who says that this whole conversation is off-topic to the mailing list.

So I'll just say, "I don't want to be the jerk who says that this whole conversation is off-topic to the mailing list"!

--
guava-...@googlegroups.com
Project site: http://guava-libraries.googlecode.com
This group: http://groups.google.com/group/guava-discuss
 
This list is for general discussion.
To report an issue: http://code.google.com/p/guava-libraries/issues/entry
To get help: http://stackoverflow.com/questions/ask (use the tag "guava")

--
Kevin Bourrillion @ Google

Java Core Libraries Team
http://guava-libraries.googlecode.com

[Craig Berry]

Actually, for just about every sort of software, I very strongly
recommend that all objects be designed to be deeply immutable unless
there is a strong reason to make an exception. Immutable objects have
numerous advantages, both in thread safety and ease of understanding.

--

[BradW]

OK everyone.  For those of you interested in continuing this discussion, I have setup a new
group: https://groups.google.com/forum/#!forum/java-language-specification.

All are welcome.

[morten hattesen]

> ... so the only thing you save is typing out the

> method definition. If you really don't like doing that I suggest you look at
> a language like Scala that removes the need entirely.

Or, if you want to bust ALL the getter/setter boilerplate code, have a
look at http://projectlombok.org/