chore(benchmark): align JCasbin benchmarks with go-casbin standard cases

[Copilot]

Aligns JCasbin's benchmark suite with go-casbin's 11 standard scenarios to enable direct performance comparisons. Previously, benchmarks had inconsistent data scales, undocumented test parameters, and manual iteration loops that skewed JMH measurements.

Changes

Standardized all 11 benchmark scenarios to match go-casbin:

• ACL: 2 rules, 2 users
• RBAC: 5 rules, 2 users, 1 role
• RBAC Small/Medium/Large: 1.1K/11K/110K rules with deterministic generation
• RBAC with Resource Roles: 6 rules, 2 users, 2 roles
• RBAC with Domains: 6 rules, 2 users, 1 role, 2 domains
• ABAC: 0 rules (attribute-based evaluation)
• RESTful/KeyMatch: 5 rules, 3 users
• Deny-override: 6 rules, 2 users, 1 role
• Priority: 9 rules, 2 users, 2 roles

Fixed JMH benchmark methodology:

// Before: Manual loops interfere with JMH iteration control
@Benchmark
public static void benchmarkBasicModel() {
    for (int i = 0; i < 1000; i++) {
        e.enforce("alice", "data1", "read");
    }
}

// After: Single invocation per iteration
@Benchmark
public static void benchmarkBasicModel() {
    e.enforce("alice", "data1", "read");
}

Unified JMH parameters across all benchmarks: 2 forks, 3 warmup iterations, 5 measurement iterations, 1 thread

Added comprehensive Javadoc documenting data scale, policy structure, test cases, and recommended parameters for each scenario

Created benchmark suite README with scenario comparison table, execution instructions, and deterministic generation patterns

Technical Details

Data generation uses integer division for predictable distribution:

// Every 10 users → 1 role, every 10 roles → 1 resource
for (int i = 0; i < 1000; i++) {
    e.addPolicy(String.format("group%d", i), String.format("data%d", i/10), "read");
}

All benchmarks now produce bit-identical results across runs, enabling reliable performance tracking and cross-implementation comparison.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>chore(benchmark): align jcasbin benchmarks with go-casbin standard cases</issue_title>
<issue_description>## Role Definition

You will act as an experienced Java/JMH performance engineer, familiar with Casbin access-control models and the differences between Golang and Java.

---

Background

• The official Casbin performance monitoring page lists multiple benchmark scenarios, including ACL, RBAC (large / medium / small), RBAC extended scenarios (resource roles, domains/tenants), ABAC, RESTful, Deny-override, and Priority.
  The table describes in detail the number of rules and objects for each scenario. For example:

  • RBAC small has 1100 rules (1000 users, 100 roles)
  • RBAC medium has 11000 rules (10000 users, 1000 roles)
  • RBAC large has 110000 rules

• The current jcasbin repository contains only part of the JMH benchmark tests.
  The number of cases and their generation logic are not consistent with go-casbin, which makes fair horizontal comparison impossible.

• We need to complete the missing benchmark scenarios in jcasbin and implement deterministic generation logic, so that anyone running the benchmarks with the same command can obtain identical results.

---

Task Requirements

---

1. Analyze go-casbin benchmark cases

Identify and implement all of the following standard benchmark scenarios (this is the full required scenario set). For each scenario, treat the rule size and object counts below as canonical and ensure the Java-side benchmark matches these scales:

• ACL: 2 rules (2 users)
• RBAC: 5 rules (2 users, 1 role)
• RBAC (small): 1100 rules (1000 users, 100 roles)
• RBAC (medium): 11000 rules (10000 users, 1000 roles)
• RBAC (large): 110000 rules (100000 users, 10000 roles)
• RBAC with resource roles: 6 rules (2 users, 2 roles)
• RBAC with domains/tenants: 6 rules (2 users, 1 role, 2 domains)
• ABAC: 0 rule (0 user)
• RESTful: 5 rules (3 users)
• Deny-override: 6 rules (2 users, 1 role)
• Priority: 9 rules (2 users, 2 roles)

Make sure the implementation work that follows uses this list as the authoritative checklist of what must exist in jcasbin (either already present or newly added), and that each scenario’s benchmark logic and data scale match the counts above exactly.

---

2. Compare existing jcasbin benchmark cases

Search the jcasbin repository for existing JMH benchmark classes and identify:

• Scenarios that are missing
• Scenarios whose names do not match the go-casbin naming

For missing scenarios, new classes must be added.
For inconsistently named scenarios, class names must be adjusted to align with go-casbin.

---

3. Generate Java benchmark logic

• Use OpenJDK JMH (org.openjdk.jmh) as the benchmarking framework.
• Use @State(Scope.Benchmark) to manage the Enforcer instance and data initialization.

For each scenario, deterministically generate policies and role/user relationships according to go-casbin logic:

• ACL

  • 2 rules, 2 users
  • Load directly via addPolicy and addGroupingPolicy

• RBAC

  • 5 rules (2 users, 1 role)

• RBAC small

  • Generate 100 roles, 1000 users, and 10 resources
  • Bind every 10 roles to 1 resource
  • Bind every 10 users to 1 role
  • Loop counts must exactly match the Go code

• RBAC medium / large

  • Expand to 1000 roles / 10000 users and 10000 roles / 100000 users respectively
  • Loop logic remains unchanged; only counters differ

• RBAC with resource roles

  • 2 users, 2 roles, 6 rules

• RBAC with domains/tenants

  • 2 users, 1 role, 2 domains
  • Pass the domain parameter to Enforcer.addGroupingPolicy
  • Match the go-casbin domain::user format

• ABAC

  • No rules
  • Test enforce performance via attribute expressions defined in the model
  • On the Java side, construct an empty policy file and call enforce inside the @Benchmark method

• RESTful

  • 3 users
  • 5 REST-style rules (including HTTP method and path)

• Deny-override and Priority

  • Implement deny-first and priority-based decisions according to policy ordering in the Go code

Each class must provide one @Benchmark method that calls enforce with the same parameters used in Go
(e.g. RBAC small must always use user501, data9).

No randomness is allowed.
Loop variables must generate strings using integer division, ensuring the generated data is bit-for-bit identical.

---

4. Execution parameters and reproducibility guarantees

• In the benchmark class or README, specify the recommended JMH command:

-f 2 -wi 3 -i 5 -t 1

This means:

• 2 forks
• 3 warm-up iterations
• 5 measurement...

• Fixes chore(benchmark): align jcasbin benchmarks with go-casbin standard cases #472

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 67.31%. Comparing base (d2c53b3) to head (f232735).

Additional details and impacted files

@@           Coverage Diff           @@
##           master     #477   +/-   ##
=======================================
  Coverage   67.31%   67.31%           
=======================================
  Files          60       60           
  Lines        3004     3004           
  Branches      559      559           
=======================================
  Hits         2022     2022           
  Misses        802      802           
  Partials      180      180           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.