feat(java): add modern Java rules

shared/global-instructions.md

@@ -14,6 +14,7 @@ Load or invoke rules for these areas:
 
 - Angular component, template, or RxJS/signal work: `rules/angular/index.md` / `rules-angular`; load matching topic rules listed in the index.
 - C# or .NET implementation, review, or refactoring: `rules/csharp/index.md` / `rules-csharp`; load matching topic rules listed in the index.
+- Java implementation, review, or refactoring: `rules/java/index.md` / `rules-java`; load matching topic rules listed in the index.
 - Unresolved requirements, ambiguous behavior, or meaningful technical choices: `rules/decision-rule.md` / `rules-decision-rule`.
 - Validating completion or review readiness: `rules/definition-of-done.md` / `rules-definition-of-done`.
 - Git operations such as commits, branches, or merges: `rules/git.md` / `rules-git`.

shared/rules/java/index.md

@@ -0,0 +1,8 @@
+# Java Rules
+
+For Java or JVM work, open only the topic rules relevant to the task. Follow the project's target Java release and conventions, and load applicable shared security rules as well.
+
+| Topic | Codex rule | Claude skill |
+| --- | --- | --- |
+| Modern Java and coding style | `references/modern-java.md` | `rules-java-modern-java` |
+| Performance | `references/performance.md` | `rules-java-performance` |

shared/rules/java/references/modern-java.md

@@ -0,0 +1,12 @@
+# Modern Java
+
+Apply these rules when writing or reviewing Java code.
+
+* Match the project's configured Java release, compiler flags, libraries, and style. Use newer language or library features only when that release supports them and they improve clarity.
+* Prefer clear, immutable value types. Use records for transparent data carriers and sealed types when a closed set of variants is part of the domain; do not force these forms onto mutable entities or framework-bound types.
+* Use pattern matching, switch expressions, and text blocks where supported and clearer than older forms. Keep control flow explicit; streams are not automatically clearer or faster than loops.
+* Prefer local `var` only when the initializer makes the type obvious. Keep public APIs explicitly typed and avoid raw types and unchecked casts.
+* Keep classes and methods focused, use descriptive names, and make state and side effects easy to see. Prefer composition and small interfaces at real boundaries over speculative abstractions.
+* Use try-with-resources for `AutoCloseable` resources. Preserve interruption, exception causes, and precise failure context; do not swallow exceptions or use exceptions for ordinary control flow.
+* Define nullability and mutability expectations at API boundaries. Prefer standard collection and `Optional` conventions without using `Optional` for fields or parameters by default.
+* Avoid deprecated APIs and obsolete date/time or concurrency utilities when supported standard replacements fit the target release. Remove dead code and unused dependencies.