/**
 * LMDB Low-level interface (LLI).
 * <p>
 * The LLI priorites (in order of importance) are:
 * <ol>
 * <li>Ensure lowest latency operation of the "priority use case" (below)</li>
 * <li>Add simple, zero cost abstractions over LMDB C functions</li>
 * <li>Fully encapsulate (hide) the native call technology and patterns</li>
 * <li>Avoid locks (expect callers to comply with any thread contracts)</li>
 * <li><code>ByteBuffer</code> is the primary buffer type and can be pointed at
 * other memory locations on demand (via unsafe or reflective techniques)</li>
 * <li>Do not add dependencies beyond the native call technology</li>
 * <li>Support standard 64-bit JVMs on typical operating systems</li>
 * <li>Prepare for Java 9 (eg Unsafe, native call technology roadmap etc)</li>
 * </ol>
 * <p>
 * The "priority use case" is:
 * <ul>
 * <li>Linux servers for production</li>
 * <li>Linux, Windows or OS X for development (and potentially production)</li>
 * <li>Read-biased workloads (consider LSM for write-heavy workloads)</li>
 * <li>Cursor-based reads with significant sequential key-value iteration</li>
 * </ul>
 * <p>
 * End users should generally avoid using the LLI, instead preferring a
 * higher-level API that offers a simpler and more idiomatic Java interface.
 */
package org.lmdbjava.core.lli;

@@ -5,583 +5,608 @@
  * L
-MDB Low-level interface (LLI).%0A * %3Cp%3E%0A * The LLI priorite
+ightning Memory Database (LMDB) for Java (LmdbJava).%0A * %3Cp%3E%0A * LmdbJava i
 s 
-(
 in
- order of importance) are:%0A * %3Col%3E%0A * %3Cli%3EEnsure lowest latency operation of the %22priority use case%22 (below)%3C/li%3E%0A * %3Cli%3EAdd simple, zero cost abstractions over LMDB C functions%3C/li%3E%0A * %3Cli%3EFully encapsulate (hide) the native call technology and patterns%3C/li%3E%0A * %3Cli%3EAvoid locks (expect callers to comply with any thread contracts)%3C/li%3E%0A * %3Cli%3E%3Ccode%3EByteBuffer%3C/code%3E is the primary buffer type and can be pointed at%0A * other memory locations on demand (via unsafe or reflective techniques)%3C/li%3E%0A * %3Cli%3EDo not add
+tended for extremely low latency use cases. Users are required%0A * to understand and comply with the LMDB C API contract (eg handle usage%0A * patterns, thread binding, process rules).%0A * %3Cp%3E%0A * Priorities:%0A * %3Col%3E%0A * %3Cli%3EMinimize latency, particularly on any critical path (see below)%3C/li%3E%0A * %3Cli%3EPreserve the LMDB C API model as far as practical%3C/li%3E%0A * %3Cli%3EApply Java idioms only when not in conflict with the above%3C/li%3E%0A * %3Cli%3EFully encapsulate (hide) the native call library and patterns%3C/li%3E%0A * %3Cli%3EDon't require runtime
  dep
@@ -638,25 +638,22 @@
 ve call 
-technolog
+librar
 y%3C/li%3E%0A 
@@ -670,28 +670,29 @@
 ort 
-standard 64-bit JVMs
+official JVMs running
  on 
@@ -699,16 +699,23 @@
 typical 
+64-bit 
 operatin
@@ -831,483 +831,169 @@
 %0A * 
-The %22priority use case%22 is:%0A * %3Cul%3E%0A * %3Cli%3ELinux servers for production%3C/li%3E%0A * %3Cli%3ELinux, Windows or OS X for development (and potentially production)%3C/li%3E%0A * %3Cli%3ERead-biased workloads (consider LSM for write-heavy workloads)%3C/li%3E%0A * %3Cli%3ECursor-based reads with significant sequential key-value iteration%3C/li%3E%0A * %3C/ul%3E%0A * %3Cp%3E%0A * End users should generally avoid using the LLI, instead preferring a%0A * higher-level API that offers a simpler and more idiomatic Java interface.
+Critical paths of special latency focus:%0A * %3Cul%3E%0A * %3Cli%3EReleasing and renewing a read-only transaction%3C/li%3E%0A * %3Cli%3EAny operation that uses a cursor%3C/li%3E%0A * %3C/ul%3E
 %0A */

Revise package description