38

Java docs of close() method of java.lang.AutoCloseable says

Note that unlike the close() method of Closeable, this close() method is not required to be idempotent. In other words, calling this close method more than once may have some visible side effect, unlike Closeable#close() which is required to have no effect if called more than once. However, implementers of this interface are strongly encouraged to make their close methods idempotent.


What do they mean by idempotent method and what are the side effects of calling this close() method twice?

And since interface Closeable extends AutoCloseable why are the side effects not to be seen in the close of Closeable interface?

informatik01
  • 16,038
  • 10
  • 74
  • 104
Aniket Thakur
  • 66,731
  • 38
  • 279
  • 289
  • 4
    Idempotent in a programming context means that you can safely repeat an operation. For example, you can issue the same HTTP GET request multiple times without fear of side effects (assuming it has been implemented correctly on the server). – John Topley Oct 11 '13 at 14:04
  • It means that you can repeat that operation 'n' times and get the same result ever, in Http idempotent method example is GET – RamonBoza Oct 11 '13 at 14:05
  • 2
    @RamonBoza Yes, assuming that the server doesn't change the resource returned, and that the web client doesn't count requests, and that the last request time isn't tracked, etc. A much better example would be `public int add(int first, int second) { return first + second; }` Two subsequent calls would certainly not change the state of the program, as the program doesn't even alter it's state. Another example `void close() { if (!closed) { file.close(); closed = true; } }` as it does change state on the first call, but state remains identical on subsequent calls. – Edwin Buck Oct 11 '13 at 14:11
  • @EdwinBuck It's a reasonable assumption to make because HTTP GET requests (amongst others) are supposed to be idempotent according to the HTTP specification. – John Topley Oct 11 '13 at 14:17
  • 1
    @JohnTopley Idempotence is very dependent on frame of reference. GET is meant to be idempotent from the point of view of the server's internal state. Certainly the client's point of view differs, or we would never revisit the same websites for daily updates. The only way the server gets away with changing data is that the server delegates the content of the request to something that is stateful (namely the file system or underlying application). – Edwin Buck Oct 11 '13 at 14:19
  • @EdwinBuck True. I was referring to the server-side state. – John Topley Oct 11 '13 at 14:20

3 Answers3

45

Idempotent means that you can apply the operation a number of times, but the resulting state of one call will be indistinguishable from the resulting state of multiple calls. In short, it is safe to call the method multiple times. Effectively the second and third (and so on) calls will have no visible effect on the state of the program.

So if you close this object once, and it closes, you don't have enough information to know if it is idempotent. However, if you close it twice, and the first time it closes, but the second time it throws an exception, it is clearly not idempotent. On the other hand, if you close it once, and close it twice, and the second closure results in the item remaining closed in the same manner (perhaps it is a noop), then it is idempotent.

One technique of making an idempotent Closeable could be:

public class Example implements Closeable {

  private boolean closed;

  public Example() {
    closed = false;
  }

  public void close() {
    if (!isClosed()) {
      closed = true;
    }
  }

  public boolean isClosed() {
    return closed;
  }
}

Where it is now obvious that if close() is called once or multiple times, all returns of the state through isClosed() will forever return true. Therefore, the method close() would be considered idempotent.

Aniket Thakur
  • 66,731
  • 38
  • 279
  • 289
Edwin Buck
  • 69,361
  • 7
  • 100
  • 138
  • Also note that this is but [**one** interpretation of the term "idempotent"](http://stackoverflow.com/a/1077421/632951). "idempotent" has other meanings in different contexts. – Pacerier Mar 10 '15 at 23:18
  • 1
    @Pacerier It is also the nearly word-for-word compatible description of the first sentence of your correction. If you use the mathematical theory approach to analyzing computation, it's still this definition, albeit with minor rewording `f(f(x)) = f(x)`, which if you speak math means "if you preform the operation `f` on `x` twice, it's the same as performing the operation `f` on `x` once. – Edwin Buck Oct 12 '15 at 15:47
23

Explanation of Concept Without Code

Einsteins definition of indempotency

To adopt Einstein's aphorism, if you do the same thing, and get different results, then the method is not idempotent.

Example of idempotency

"Please sir, can I have a pay rise?"

"No"

Same result every time. Asking for a pay rise is an idempotent operation.

Examples of non-idempotent operation:

...would be making a delete request to destroy a resource. For example, you can only delete a file once. After that, the operation doesn't make sense. It's not idempotent

BenKoshy
  • 33,477
  • 14
  • 111
  • 80
0

IDEMPOTENT Methods

HTTP method is imdempotent method if the result become same for every call. When you call any request n times then result would be same.

Take an example that adding ZERO in any number would be the same result.

HTTP methods divided into two types.

  1. Safely repeatable (Idempotent)
  2. Can't be repeatable safely (Non- Idempotent)

Safely repeatable (Idempotent): Call method any times, it gives same result. it called Idempotent methods.

GET, PUT, DELETE HTTP method called as Idempotent method. Because

GET method: retrieving the resource. PUT method: It will update one resource. DELETE method: It will used to delete the indiviual resource not impact other resource.

Can't be repeatable safely (Non- Idempotent)

But when POST method calls. POST method will create new resource everytime. Therefore it called as Non- Idempotent

Abhishek Gupta
  • 107
  • 1
  • 10