Minor doc fixes

src/main/asciidoc/java/index.adoc

@@ -173,7 +173,7 @@ inconsistent state. See https://github.com/vert-x3/vertx-hazelcast/issues/24 for
 **IMPORTANT** Make sure Hazelcast is started before and shut down after Vert.x.
 Also, the Hazelcast shutdown hook should be disabled (see xml example, or via system property).
 
-=== Changing timeout for failed nodes
+== Changing timeout for failed nodes
 
 By default a node will be removed from the cluster if Hazelcast didn't receive a heartbeat for 300 seconds. To change
 this value `hazelcast.max.no.heartbeat.seconds` system property such as in:
@@ -190,15 +190,11 @@ http://docs.hazelcast.org/docs/3.6/manual/html-single/index.html#configuring-wit
 with system properties] for the other properties you can configure.
 
 == Using Hazelcast async methods
-Hazelcast's `IMap` and `IAtomicLong` interfaces can be used with async methods returning `ICompletableFuture<V>`,
-a natural fit for Vert.x threading model. Even though these interfaces have been available for a long time, they are not
-provided by the public `HazelcastInstance` API.
-
-The default behavior of the `HazelcastClusterManager` is to use the public API. Supplying the option
-`-Dvertx.hazelcast.async-api=true` on JVM startup, will indicate that the async Hazelcast API methods will be used to
-communicate with the hazelcast cluster. Effectively, this means that when this option is enabled,
-execution of all `Counter` operations and `AsyncMap.get`,`AsyncMap.put` and `AsyncMap.remove` operations will
-occur in the calling thread (the event loop), instead of a worker thread with `vertx.executeBlocking`.
+
+Hazelcast's `IMap` and `IAtomicLong` interfaces can be used with async methods returning `ICompletableFuture<V>`, a natural fit for Vert.x threading model.
+
+Supplying the option `-Dvertx.hazelcast.async-api=true` on JVM startup, will indicate that the async Hazelcast API methods will be used to communicate with the hazelcast cluster.
+Effectively, this means that when this option is enabled, execution of all `Counter` operations and `AsyncMap.get`,`AsyncMap.put` and `AsyncMap.remove` operations will occur in the calling thread (the event loop), instead of a worker thread with `vertx.executeBlocking`.
 
 == Trouble shooting clustering