Clearing code samples from internal API's and asserts.

[sancar]

I don't know if it is discussed before. Our code samples use internal API, which caused compile problem in this release when changed. Fixed here https://github.com/hazelcast/hazelcast-code-samples/pull/303/files The reason of usage seems to demonstrate some features are working. And it resembles our unit tests. I think the code sample does not need that much verification. Since it is to show how hazelcast should be used, it is giving wrong advice.

Heaviest usage is around simulating the split brain. That requires access to node. I think this should not be part of the code samples. Configuring split brain on code samples make sense. But simulating the behavior I think is part of the unit tests. https://github.com/hazelcast/hazelcast-code-samples/blob/master/jcache/src/main/java/com/hazelcast/examples/splitbrain/AbstractCacheSplitBrainSample.java#L105

I see generateKeyOwnedBy usage. I don't think we are advising this to our users. Make sense for tests but users should use affinity features instead of generating the key for a specific partition. And interestingly, this also accesses to node.

I think we also need rules for using assertions. We have the following methods on Common Utils. My gut feeling says that code samples should not do assert. .assertClusterSizeEventually; .assertEquals; .assertOpenEventually;

I am keen to do the following System.out.println(cache1.get("key1"));//prints 'value' instead of assertEquals("value",);

Lastly, I see abstract class usages too much. Especially around SplitBrainSamples. I think code samples should be one class and simple. Using abstractions to demonstrate simple usages will scare of the users. This again seems to be caused by simulating the split brain. When we remove that part, abstractions will go away too.

[mmedenjak]

Moving to 4.1