pmd-ruleset.xml

<?xml version="1.0"?>
<ruleset name="Wasmtime4j PMD Ruleset"
         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>
        PMD rules for the Wasmtime4j project focused on maintainability,
        performance, and defensive programming practices.
    </description>

    <!-- Best Practices Rules -->
    <rule ref="category/java/bestpractices.xml">
        <!-- Exclude rules that conflict with JNI/Panama patterns -->
        <exclude name="UseVarargs"/><!-- JNI methods may require array parameters -->
        <exclude name="AccessorMethodGeneration"/><!-- May be needed for native field access -->
        <exclude name="GuardLogStatement"/><!-- java.util.logging doesn't require guards -->
        <exclude name="UnusedFormalParameter"/><!-- Native callbacks may not use all parameters -->
        <exclude name="DoNotUseThreads"/><!-- Thread pools may be needed for async native ops -->
        <exclude name="AvoidUsingVolatile"/><!-- Volatile needed for native/JNI thread safety -->
        <exclude name="PreserveStackTrace"/><!-- Native exceptions may need re-wrapping -->
        <exclude name="SystemPrintln"/><!-- May be acceptable for CLI tools and debugging -->
        <exclude name="LooseCoupling"/><!-- Concrete types may be needed for native interop -->
        <exclude name="AccessorClassGeneration"/><!-- Inner class patterns are acceptable -->
        <exclude name="UnusedPrivateField"/><!-- Fields may be accessed via reflection or native -->
        <exclude name="UnusedLocalVariable"/><!-- Variables may be kept for debugging -->
        <exclude name="UnusedAssignment"/><!-- Assignments may be kept for clarity -->
        <exclude name="LiteralsFirstInComparisons"/><!-- Object-first may be clearer sometimes -->
        <exclude name="UseEnumCollections"/><!-- Regular collections may be more flexible -->
        <exclude name="MissingOverride"/><!-- May be omitted intentionally -->
        <exclude name="ArrayIsStoredDirectly"/><!-- Direct array storage may be intentional for performance -->
        <exclude name="MethodReturnsInternalArray"/><!-- Array exposure may be intentional for performance -->
        <exclude name="UnusedPrivateMethod"/><!-- Methods may be called via reflection or native -->
        <exclude name="AvoidUsingNativeCode"/><!-- This is a JNI/Panama project -->
        <exclude name="AvoidUsingHardCodedIP"/><!-- Test IPs may be hardcoded -->
        <exclude name="UseTryWithResources"/><!-- Manual resource management may be needed for native -->
        <exclude name="ForLoopCanBeForeach"/><!-- Traditional for loops may be preferred -->
        <exclude name="UnnecessaryVarargsArrayCreation"/><!-- Explicit array creation can be clearer -->
        <exclude name="AvoidPrintStackTrace"/><!-- May be acceptable for benchmarks and debugging -->
        <exclude name="AbstractClassWithoutAbstractMethod"/><!-- Base classes without abstract methods are acceptable -->
        <exclude name="AvoidReassigningLoopVariables"/><!-- Loop variable reassignment may be intentional -->
        <exclude name="AvoidBranchingStatementAsLastInLoop"/><!-- Break/continue as last statement may be clearer -->
        <exclude name="UnnecessaryWarningSuppression"/><!-- Flags SpotBugs suppressions that PMD doesn't understand -->
        <exclude name="ImplicitFunctionalInterface"/><!-- Not all single-method interfaces need @FunctionalInterface -->
        <exclude name="ExhaustiveSwitchHasDefault"/><!-- Project convention requires default case in all switches -->
        <exclude name="EnumComparison"/><!-- .equals() for enums is acceptable -->
    </rule>

    <!-- Code Style Rules -->
    <rule ref="category/java/codestyle.xml">
        <!-- Exclude overly strict rules -->
        <exclude name="OnlyOneReturn"/><!-- Multiple returns can improve readability -->
        <exclude name="AtLeastOneConstructor"/><!-- Utility classes may not need constructors -->
        <exclude name="CommentDefaultAccessModifier"/><!-- Default access is intentional -->
        <exclude name="ConfusingTernary"/><!-- Ternary operators can be clear when used properly -->
        <exclude name="TooManyStaticImports"/><!-- Static imports can improve readability -->
        <exclude name="UseUnderscoresInNumericLiterals"/><!-- Not always necessary -->
        <exclude name="ShortClassName"/><!-- Some short names are appropriate (e.g., IO, VM) -->
        <exclude name="LongVariable"/><!-- Descriptive names are preferred -->
        <exclude name="ShortVariable"/><!-- Conflicts with standard abbreviations -->
        <exclude name="CallSuperInConstructor"/><!-- Not always required -->
        <exclude name="DefaultPackage"/><!-- Default package usage may be intentional -->
        <exclude name="FinalParameterInAbstractMethod"/><!-- Final on interface parameters is meaningless -->
        <exclude name="MethodArgumentCouldBeFinal"/><!-- Too noisy for native code patterns -->
        <exclude name="LocalVariableCouldBeFinal"/><!-- Too noisy, style preference -->
        <exclude name="ShortMethodName"/><!-- Some short names like get/set are appropriate -->
        <exclude name="UnnecessaryModifier"/><!-- Explicit modifiers can improve clarity -->
        <exclude name="FieldDeclarationsShouldBeAtStartOfClass"/><!-- Builder pattern fields may be grouped logically -->
        <exclude name="UselessParentheses"/><!-- Parentheses can improve readability -->
        <exclude name="LinguisticNaming"/><!-- Native API naming may follow external conventions -->
        <exclude name="UnnecessaryFullyQualifiedName"/><!-- FQN may be needed to avoid ambiguity -->
        <exclude name="PrematureDeclaration"/><!-- Declaring at top of method can be clearer -->
        <exclude name="UnnecessaryConstructor"/><!-- Explicit constructors can be clearer -->
        <exclude name="UnnecessaryLocalBeforeReturn"/><!-- Local variables before return can be clearer -->
        <exclude name="UnnecessaryCast"/><!-- Explicit casts may be needed for generics -->
        <exclude name="UnnecessaryBoxing"/><!-- Explicit boxing may be clearer -->
        <exclude name="UseShortArrayInitializer"/><!-- Long form may be clearer -->
        <exclude name="UseObjectForClearerAPI"/><!-- Specific types may be clearer -->
        <exclude name="LambdaCanBeMethodReference"/><!-- Lambdas may be clearer -->
        <exclude name="FieldNamingConventions"/><!-- Native code may follow external naming -->
        <exclude name="MethodNamingConventions"/><!-- Native wrappers may follow external naming -->
        <exclude name="ClassNamingConventions"/><!-- Native wrappers may follow external naming -->
        <exclude name="BooleanGetMethodName"/><!-- Non-standard boolean getters may be intentional -->
        <exclude name="EmptyControlStatement"/><!-- Empty statements may be intentional -->
        <exclude name="UseDiamondOperator"/><!-- Explicit type parameters can be clearer -->
        <exclude name="UselessQualifiedThis"/><!-- Explicit this qualification can be clearer -->
        <exclude name="UnnecessaryReturn"/><!-- Explicit returns can be clearer -->
        <exclude name="IdenticalCatchBranches"/><!-- Explicit branches can be clearer -->
        <exclude name="AvoidUsingNativeCode"/><!-- This is a JNI/Panama project -->
        <exclude name="UnnecessaryVarargsArrayCreation"/><!-- Explicit array creation can be clearer -->
        <exclude name="UseExplicitTypes"/><!-- Explicit types may be preferred -->
        <exclude name="LocalVariableNamingConventions"/><!-- Variable names may follow native conventions -->
        <exclude name="ForLoopCanBeForeach"/><!-- Traditional for loops may be preferred -->
        <exclude name="ControlStatementBraces"/><!-- Braces enforced by Checkstyle, not PMD -->
        <exclude name="VariableCanBeInlined"/><!-- Explicit local variables can improve readability -->
        <exclude name="UnnecessaryInterfaceDeclaration"/><!-- Explicit interface declarations can be clearer -->
        <exclude name="UnnecessaryImport"/><!-- Import checking handled by Checkstyle; PMD false positives on inner classes -->
    </rule>

    <!-- Design Rules -->
    <rule ref="category/java/design.xml">
        <!-- Exclude rules that may not apply to JNI/native patterns -->
        <exclude name="LawOfDemeter"/><!-- May not apply to fluent APIs or native wrappers -->
        <exclude name="LoosePackageCoupling"/><!-- Acceptable for internal API coupling -->
        <exclude name="DataClass"/><!-- DTOs and value objects are acceptable -->
        <exclude name="TooManyMethods"/><!-- Native wrapper classes may have many methods -->
        <exclude name="TooManyFields"/><!-- Native structures may have many fields -->
        <exclude name="ExcessivePublicCount"/><!-- Public APIs may be extensive -->
        <exclude name="GodClass"/><!-- Main API classes may be larger by design -->
        <exclude name="CouplingBetweenObjects"/><!-- API classes may have high coupling by design -->
        <exclude name="ExcessiveImports"/><!-- Comprehensive APIs may need many imports -->
        <exclude name="CognitiveComplexity"/><!-- Native wrapper complexity is inherent -->
        <exclude name="NPathComplexity"/><!-- Native code paths can be complex -->
        <exclude name="CyclomaticComplexity"/><!-- Native operations can be complex -->
        <exclude name="NcssCount"/><!-- Native wrapper classes can be large -->
        <exclude name="ExcessiveParameterList"/><!-- Native methods may need many parameters -->
        <exclude name="AvoidDeeplyNestedIfStmts"/><!-- Native error handling may require nesting -->
        <exclude name="CollapsibleIfStatements"/><!-- Explicit conditions can be clearer -->
        <exclude name="SimplifyBooleanReturns"/><!-- Explicit returns can be clearer -->
        <exclude name="UseUtilityClass"/><!-- Static-only classes may be intentional -->
        <exclude name="ImmutableField"/><!-- Fields may be set via native code or reflection -->
        <exclude name="SignatureDeclareThrowsException"/><!-- Native wrappers may throw Exception -->
        <exclude name="AvoidThrowingRawExceptionTypes"/><!-- Native wrappers may wrap native errors -->
        <exclude name="ExceptionAsFlowControl"/><!-- Sometimes appropriate for native error handling -->
        <exclude name="ClassWithOnlyPrivateConstructorsShouldBeFinal"/><!-- Utility class patterns -->
        <exclude name="AbstractClassWithoutAnyMethod"/><!-- Marker classes are acceptable -->
        <exclude name="AbstractClassWithoutAbstractMethod"/><!-- Base classes without abstract methods are acceptable -->
        <exclude name="FinalFieldCouldBeStatic"/><!-- Non-static finals may be intentional -->
        <exclude name="SingularField"/><!-- Single-use fields may be clearer -->
        <exclude name="SwitchDensity"/><!-- Dense switches may be appropriate -->
        <!-- Rules that may have moved categories in PMD 7 -->
        <exclude name="AvoidCatchingGenericException"/><!-- Native code may throw generic exceptions -->
        <exclude name="AvoidThrowingNullPointerException"/><!-- May be appropriate for null validation -->
        <exclude name="AvoidRethrowingException"/><!-- Re-throwing may be intentional for logging -->
        <exclude name="UseObjectForClearerAPI"/><!-- Specific types may be clearer -->
        <exclude name="AvoidCatchingThrowable"/><!-- Throwable may be caught for native error handling -->
        <exclude name="SimplifyConditional"/><!-- Explicit conditionals can be clearer -->
        <exclude name="AvoidUncheckedExceptionsInSignatures"/><!-- Native wrappers may throw unchecked exceptions -->
        <exclude name="TooFewBranchesForASwitchStatement"/><!-- Small switches may be clearer -->
        <exclude name="PublicMemberInNonPublicType"/><!-- Package-private types may expose public members intentionally -->
    </rule>

    <!-- Error Prone Rules -->
    <rule ref="category/java/errorprone.xml">
        <!-- Exclude rules that may conflict with defensive programming -->
        <exclude name="DataflowAnomalyAnalysis"/><!-- May produce false positives with native code -->
        <exclude name="NullAssignment"/><!-- Explicit null assignment can be defensive -->
        <exclude name="AvoidLiteralsInIfCondition"/><!-- Sometimes literals in conditions are clearer -->
        <exclude name="EmptyIfStmt"/><!-- May be used for defensive programming -->
        <exclude name="AvoidFieldNameMatchingMethodName"/><!-- May be acceptable for properties -->
        <exclude name="AvoidCatchingGenericException"/><!-- Native code may throw generic exceptions -->
        <exclude name="EmptyCatchBlock"/><!-- Empty catch may be intentional for optional operations -->
        <exclude name="DoNotCallGarbageCollectionExplicitly"/><!-- May be needed after native resource cleanup -->
        <exclude name="AvoidDuplicateLiterals"/><!-- String constants may be clearer inline -->
        <exclude name="MissingOverride"/><!-- May be omitted intentionally -->
        <exclude name="CompareObjectsWithEquals"/><!-- Reference comparison may be intentional -->
        <exclude name="AvoidThrowingNullPointerException"/><!-- May be appropriate for null validation -->
        <exclude name="UseLocaleWithCaseConversions"/><!-- Default locale may be intentional -->
        <exclude name="AvoidInstanceofChecksInCatchClause"/><!-- Type checking in catch may be necessary -->
        <exclude name="AvoidRethrowingException"/><!-- Re-throwing may be intentional for logging -->
        <exclude name="EmptyControlStatement"/><!-- Empty statements may be intentional -->
        <exclude name="SuspiciousEqualsMethodName"/><!-- Non-standard equals names may be intentional -->
        <exclude name="AssignmentInOperand"/><!-- Assignment in operand can be idiomatic -->
        <exclude name="CloseResource"/><!-- Resources may be managed by native code -->
        <exclude name="AvoidFileStream"/><!-- FileStream may be needed for native interop -->
        <exclude name="SingleMethodSingleton"/><!-- Singleton patterns are acceptable -->
        <exclude name="ReturnEmptyCollectionRatherThanNull"/><!-- Null may indicate different semantics -->
        <exclude name="MethodReturnsInternalArray"/><!-- Array exposure may be intentional for performance -->
        <exclude name="ArrayIsStoredDirectly"/><!-- Direct array storage may be intentional for performance -->
        <exclude name="AvoidUsingOctalValues"/><!-- Octal values may be intentional for native code -->
        <exclude name="DoNotTerminateVM"/><!-- VM termination may be intentional for test harnesses -->
        <exclude name="SingletonClassReturningNewInstance"/><!-- Factory pattern may be intentional -->
        <exclude name="AvoidCatchingThrowable"/><!-- Throwable may be caught for native error handling -->
        <exclude name="AvoidBranchingStatementAsLastInLoop"/><!-- Break/continue as last statement may be clearer -->
        <exclude name="ConfusingArgumentToVarargsMethod"/><!-- Single-element varargs calls to standard APIs are clear -->
        <exclude name="UseProperClassLoader"/><!-- J2EE-specific advice not relevant for standalone apps -->
    </rule>

    <!-- Multithreading Rules -->
    <rule ref="category/java/multithreading.xml">
        <!-- Exclude rules that conflict with native code patterns -->
        <exclude name="DoNotUseThreads"/><!-- Threads may be needed for native async ops -->
        <exclude name="AvoidUsingVolatile"/><!-- Volatile needed for native/JNI thread safety -->
        <exclude name="UseConcurrentHashMap"/><!-- Regular HashMap may be sufficient when externally synchronized -->
        <exclude name="AvoidSynchronizedAtMethodLevel"/><!-- Method-level sync can be appropriate -->
        <exclude name="AvoidSynchronizedStatement"/><!-- Sync blocks may be needed for native calls -->
        <exclude name="NonThreadSafeSingleton"/><!-- Singleton thread safety may be handled externally -->
    </rule>

    <!-- Performance Rules -->
    <rule ref="category/java/performance.xml">
        <!-- Exclude rules that may conflict with defensive programming -->
        <exclude name="AvoidInstantiatingObjectsInLoops"/><!-- May be necessary for native resource management -->
        <exclude name="UseStringBufferForStringAppends"/><!-- StringBuilder is preferred anyway -->
        <exclude name="RedundantFieldInitializer"/><!-- Explicit initialization can be clearer -->
        <exclude name="AppendCharacterWithChar"/><!-- String append can be clearer -->
        <exclude name="ConsecutiveAppendsShouldReuse"/><!-- Chained appends can be clearer -->
        <exclude name="ConsecutiveLiteralAppends"/><!-- Separate appends can be clearer -->
        <exclude name="InsufficientStringBufferDeclaration"/><!-- Default size is often sufficient -->
        <exclude name="InefficientEmptyStringCheck"/><!-- Different checks may be clearer -->
        <exclude name="UseArraysAsList"/><!-- Manual array iteration may be clearer -->
        <exclude name="AvoidUsingOctalValues"/><!-- Octal values may be intentional for native code -->
        <exclude name="AddEmptyString"/><!-- Explicit empty string can be clearer -->
        <exclude name="AvoidFileStream"/><!-- FileStream may be needed for native interop -->
        <exclude name="TooFewBranchesForASwitchStatement"/><!-- Small switches may be clearer -->
        <exclude name="TooFewBranchesForSwitch"/><!-- Renamed in PMD 7.22.0; small switches may be clearer -->
        <exclude name="UseIndexOfChar"/><!-- String indexOf can be clearer -->
    </rule>

    <!-- Security Rules -->
    <rule ref="category/java/security.xml">
        <!-- Keep all security rules - very important for native code -->
    </rule>

    <!-- Custom rules for the project -->

    <!-- LogNativeFailures rule disabled - generates false positives on methods with 'native' in name
    <rule name="LogNativeFailures"
          language="java"
          message="Native method calls should include error logging"
          class="net.sourceforge.pmd.lang.rule.xpath.XPathRule">
        <description>
            Native method calls should include appropriate error logging for debugging.
        </description>
        <priority>3</priority>
        <properties>
            <property name="xpath">
                <value><![CDATA[
                    //MethodDeclaration[contains(@Name, 'native')]
                    [not(descendant::PrimaryExpression[ends-with(@Name, 'log')])]
                ]]></value>
            </property>
        </properties>
    </rule>
    -->

    <!-- Exclude generated code and test utilities -->
    <exclude-pattern>.*/generated/.*</exclude-pattern>
    <exclude-pattern>.*/target/.*</exclude-pattern>
    <exclude-pattern>.*Test\.java</exclude-pattern>
    <exclude-pattern>.*IT\.java</exclude-pattern>
    <exclude-pattern>.*/test/.*</exclude-pattern>
    <exclude-pattern>.*BenchmarkRunner\.java</exclude-pattern>
</ruleset>