This page sets out the known TODO items for the RocksJava API, it also shows who is thinking/working on a particular topic; Through this mechanism hopefully we can avoid duplicating effort.

Some recent user requests (as of June 2017):

In order of priority:

  • Load Options APIs to dynamically reload the options without needing a restart. ([#2898](https://github.com/facebook/rocksdb/pull/2898))
  • Merge Operator API (#2282)
  • Compaction Filter API (#2483)
  • Ability to pass in native pointers/memory to reduce the JNI overhead
  • Shared block cache across all column-families and instances. (#3623)
  • Stats (Tickers and histograms) in sync with C++ API. (in-sync as of June 2017, due to #2429 and #2209)
  • Implement Statistics.getHistogramString (#2374).

Upcoming changes to the Java API (outdated — last updated in July 2016)

  • Adjust RocksJava Comparator implementation - We analyzed the current implementation and noticed a significant loss of performance using the current implementation. So we decided to do the following steps in order
  • Analyze which one of the comparator implementations is performing better either DirectComparator or Comparator
  • Outline a proper way to use Custom-C++-Comparators with RocksJava.
  • Remove everything but one Comparator implementation. Depending on the analysis listed above.
  • Document the performance penalties in related JavaDoc.
  • FindShortestSeparatorand FindShortSuccessor shall only do something if the Java method is implemented. What`s currently not the case.

  • Rework WBWIIterator to use both Slice and DirectSlice (see above).

  • Introduce final on variables/members everywhere they are immutable.

  • Implement ldb for Java. For example, the ability to specify the Comparator which implemented in Java.@adamretter

  • Custom merge operator for Java. At the moment it is only possible to use merge operators which are available in C++ but not implementing custom functionality solely in Java. Decision: will not be implemented.

  • Expose an AbstractLogger. RocksDB C++ api allows to provide a custom Logger. This shall also be possible from Java side and allows to attach RocksDB logging to application logging facilities.

  • Document the performance penalties if log level is too verbose.

  • Port remaining functionality in db.h to RocksJava.@fyrz

  • Update Statistics/HistogramData to 3.10@fyrz

  • Build isolation. Building Java API should not require building RocksDB. You should be able to use a Java API build with a separate existing RocksDB installation. The Java API native aspect will instead indirectly depend on a shared or static RocksDB lib.@adamretter

  • Expose optimistic locking@fyrz

Planned changes for 4.x

  • Move on to Java-8, especially because Java-7 is EOL this year.

  • Look at Java 8 Long#unsigned operations.

  • Consider whether we should add an UnsignedLong, UnsignedInt class types of our own to prevent users from sending invalid DBOptions.

  • Restructure the package layout within the Java part.

  • Implement ARM (Automatic Resource Management) e.g. try-with-resources Java 7 use via Closeable/AutoCloseable for iterators, db, write batches etc. Along with this change we will remove the auto-cleanup for c++ resources using finalize. Instead we will throw an exception if a C++ resource is going to be finalized without freeing the native handle first.DONE @adamretter

  • Consider converting callbacks to lambda expressions