rocksdb/java/pmd-rules.xml

63 lines
2.9 KiB
XML
Raw Normal View History

<?xml version="1.0"?>
<ruleset name="Custom Rules"
xmlns="http://pmd.sourceforge.net/ruleset/2.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://pmd.sourceforge.net/ruleset/2.0.0 https://pmd.sourceforge.io/ruleset_2_0_0.xsd">
<description>
Custom rules for checking RocksDB
</description>
<!-- Use PMD rules from a few sets, and then make exceptions -->
<rule ref="category/java/codestyle.xml">
<!-- These problems are acceptable in perpertuity -->
<exclude name="AvoidUsingNativeCode"/>
<exclude name="LongVariable"/>
<exclude name="ShortVariable"/>
<exclude name="ShortClassName"/>
<exclude name="OnlyOneReturn"/>
<exclude name="FieldNamingConventions"/>
<exclude name="FormalParameterNamingConventions"/>
<exclude name="LinguisticNaming"/>
Java API consistency between RocksDB.put() , .merge() and Transaction.put() , .merge() (#11019) Summary: ### Implement new Java API get()/put()/merge() methods, and transactional variants. The Java API methods are very inconsistent in terms of how they pass parameters (byte[], ByteBuffer), and what variants and defaulted parameters they support. We try to bring some consistency to this. * All APIs should support calls with ByteBuffer parameters. * Similar methods (RocksDB.get() vs Transaction.get()) should support as similar as possible sets of parameters for predictability. * get()-like methods should provide variants where the caller supplies the target buffer, for the sake of efficiency. Allocation costs in Java can be significant when large buffers are repeatedly allocated and freed. ### API Additions 1. RockDB.get implement indirect ByteBuffers. Added indirect ByteBuffers and supporting native methods for get(). 2. RocksDB.Iterator implement missing (byte[], offset, length) variants for key() and value() parameters. 3. Transaction.get() implement missing methods, based on RocksDB.get. Added ByteBuffer.get with and without column family. Added byte[]-as-target get. 4. Transaction.iterator() implement a getIterator() which defaults ReadOptions; as per RocksDB.iterator(). Rationalize support API for this and RocksDB.iterator() 5. RocksDB.merge implement ByteBuffer methods; both direct and indirect buffers. Shadow the methods of RocksDB.put; RocksDB.put only offers ByteBuffer API with explicit WriteOptions. Duplicated this with RocksDB.merge 6. Transaction.merge implement methods as per RocksDB.merge methods. Transaction is already constructed with WriteOptions, so no explicit WriteOptions methods required. 7. Transaction.mergeUntracked implement the same API methods as Transaction.merge except the ones that use assumeTracked, because that’s not a feature of merge untracked. ### Support Changes (C++) The current JNI code in C++ supports multiple variants of methods through a number of helper functions. There are numerous TODO suggestions in the code proposing that the helpers be re-factored/shared. We have taken a different approach for the new methods; we have created wrapper classes `JDirectBufferSlice`, `JDirectBufferPinnableSlice`, `JByteArraySlice` and `JByteArrayPinnableSlice` RAII classes which construct slices from JNI parameters and can then be passed directly to RocksDB methods. For instance, the `Java_org_rocksdb_Transaction_getDirect` method is implemented like this: ``` try { ROCKSDB_NAMESPACE::JDirectBufferSlice key(env, jkey_bb, jkey_off, jkey_part_len); ROCKSDB_NAMESPACE::JDirectBufferPinnableSlice value(env, jval_bb, jval_off, jval_part_len); ROCKSDB_NAMESPACE::KVException::ThrowOnError( env, txn->Get(*read_options, column_family_handle, key.slice(), &value.pinnable_slice())); return value.Fetch(); } catch (const ROCKSDB_NAMESPACE::KVException& e) { return e.Code(); } ``` Notice the try/catch mechanism with the `KVException` class, which combined with RAII and the wrapper classes means that there is no ad-hoc cleanup necessary in the JNI methods. We propose to extend this mechanism to existing JNI methods as further work. ### Support Changes (Java) Where there are multiple parameter-variant versions of the same method, we use fewer or just one supporting native method for all of them. This makes maintenance a bit easier and reduces the opportunity for coding errors mixing up (untyped) object handles. In order to support this efficiently, some classes need to have default values for column families and read options added and cached so that they are not re-constructed on every method call. This PR closes https://github.com/facebook/rocksdb/issues/9776 Pull Request resolved: https://github.com/facebook/rocksdb/pull/11019 Reviewed By: ajkr Differential Revision: D52039446 Pulled By: jowlyzhang fbshipit-source-id: 45d0140a4887e42134d2e56520e9b8efbd349660
2023-12-11 19:03:17 +00:00
<exclude name="ConfusingTernary"/>
<!-- These could be fixed if we take the time to do it -->
<exclude name="CommentDefaultAccessModifier"/>
<exclude name="FieldDeclarationsShouldBeAtStartOfClass"/>
<exclude name="FinalParameterInAbstractMethod"/>
<exclude name="EmptyMethodInAbstractClassShouldBeAbstract"/>
<exclude name="MethodArgumentCouldBeFinal"/>
<exclude name="LocalVariableNamingConventions"/>
<exclude name="LocalVariableCouldBeFinal"/>
<exclude name="ControlStatementBraces"/>
<exclude name="CallSuperInConstructor"/>
<exclude name="ControlStatementBraces"/>
<exclude name="MethodNamingConventions"/>
<exclude name="UselessParentheses"/>
<exclude name="AtLeastOneConstructor"/>
</rule>
<rule ref="category/java/errorprone.xml">
<exclude name="AvoidFieldNameMatchingMethodName"/>
</rule>
<rule ref="category/java/errorprone.xml/AvoidLiteralsInIfCondition">
<properties>
<property name="ignoreMagicNumbers" value="-1,0,1,2,0x0,0x1,0xff" />
<property name="ignoreExpressions" value="true,false" />
</properties>
</rule>
<rule ref="category/java/bestpractices.xml">
<exclude name="UseVarargs"/>
</rule>
<rule ref="category/java/errorprone.xml/CloseResource">
<properties>
<property name="types" value="java.lang.AutoCloseable,java.sql.Connection,java.sql.Statement,java.sql.ResultSet" />
<property name="closeAsDefaultTarget" value="true" />
<!-- we allow these org.rocksdb types as generally our API is opening them for the user. -->
<property name="allowedResourceTypes" value="java.io.ByteArrayOutputStream|java.io.ByteArrayInputStream|java.io.StringWriter|java.io.CharArrayWriter|java.util.stream.Stream|java.util.stream.IntStream|java.util.stream.LongStream|java.util.stream.DoubleStream" />
<property name="closeNotInFinally" value="false" />
</properties>
</rule>
</ruleset>