Why an additional ResumptionSupportingConnectionStore about californium HOT 6 CLOSED

to keep backward compatibility.

from californium.

@balsmn, if your question has been answered, can you please close the issue?

from californium.

Actually not. May be the question was mis-interpreted.

@sbernard31 Adding a new method to an existing interface is also a compatible change. What I meant was, if resumption is an inherent property of a Connection, then Connection store shall provide a method to set the same. I don't see the need for an additional ResumptionSupportingConnectionStore.

from californium.

"Adding a new method to an existing interface is also a compatible change"

In java 7, I don't think so. (In java 8, this is possible by using default/defender method, but in this case it does really help because when we can not resume connection we want to clear the connection store)

This is the only reason of this choice.
(here more comments about that)

from californium.

@balsmn the problem here is that client code can provide its own implementation of the interface to the constructor. However, if Scandium wants to invoke the added method and the object passed in by the client only implments the old version of the interface without the new method we will end up with an ugly runtime exception.

from californium.

@sophokles73 Yes I agree. We could end up having linkage exceptions if scandium wants to invoke the added method. Thanks @sbernard31 for the link. My bad. I agree with you regarding the incompatible change. Now I could now see more in to this discussion and was very interesting to read about DTLS Handshakes. Thanks @sophokles73 for the wiki page describing the session resumption in detail.

from californium.