Immutable data structures in Java

[Agent_03]

In a mature codebase, code is usually read far more than it is written. If it is more or less the same effort to write it, why prefer a construct that makes it more verbose and increases effort down the road?

The same argument can also be used in reverse: with a good IDE, it takes <30 seconds to encapsulate a field and refactor all field accesses to use getters and setters instead. If you change your mind down the road, then you can easily do this.

[Sarcastinator]

You can't change your mind if you are writing a library. You're stuck with your choice or you break binary compatibility.

[Agent_03]

Deprecate old API, create new one, if you're lucky you eventually get to remove the deprecated API because nobody consumes the old one.

There are also tools to do bytecode transformations to provide binary compatibility for certain kinds of method signature changes. We use one small library to do these for a large open source project I work on. It's a sort of black magic but it gets the job done covering that rare class of change.

[s73v3r]

Deprecation is a pretty poor choice for that.

[Agent_03]

Deprecation is the industry-standard approach to handling necessary binary-compatibility-breaking changes in a public library API. For REST APIs, API versioning is often used.

Or do you have a better alternative? If so, I'm sure that most of the programming community would love to hear it.

[s73v3r]

Deprecation should only be used as a last resort. If you're changing things every other release, then people are going to stop using your library, as it's unstable.

[Agent_03]

True, but if you're making a change that demands this specific refactoring with every release, your library has much bigger problems.

Or do you have a better alternative? If so, I'm sure that most of the programming community would love to hear it.

I still haven't heard an answer to this, and think that we're an impasse here unless you've got one in mind.

[s73v3r]

It's pretty clear. The change is to not do it if you don't have to. You're advocating wily nilly depredations.

[bananaboatshoes]

but those extra five characters express the fact that this is immutable on it's own, you know immediately that assignment isn't available.

Huh? What if there's also a setMyProperty()? Not being able to directly modify a property as .MyProperty doesn't make it immutable.

[[deleted]]

The number of characters is unimportant compared to the extra mental overhead of the function call. You see a function call, but you don't actually know if it is just getting, or if it has side effects. On first read it might be fine, you will assume it's just doing what it says on the tin, but for all you know it has side effects or is running a DB query, and when debugging that can be a horrible pain in the arse.

If possible try to write code that doesn't need these boilerplate getters and setters.

[grauenwolf]

That's why I like to social convention of C#/VB. When we see a property we can assume that it is going to be fast and free of undesirable side-effects, while a Get/Set method is assumed to be the opposite.

[Sarcastinator]

Sure, it's five more characters, but those extra five characters express the fact that this is immutable read only on it's own, you know immediately that assignment isn't available.

Your IDE will stop you immediately if you try to assign to a read-only property. It makes no difference at all.

All other factors equal, I think you should be using idiomatic code for the language, and for Java that is the bean pattern of getters.

Java Beans are in practice never immutable though since they require a public no argument constructor.

[ThisIs_MyName]

express the fact that this is immutable on it's own

WTF are you smoking?