Configure sonar.coverage.jacoco.xmlReportPaths property to point
SonarCloud to the JaCoCo XML report location in the ognl module.
This resolves the issue where SonarCloud was reporting 0% coverage
despite tests running with coverage enabled.

Fixes #481

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-authored-by: Claude <[email protected]>

Port fix from PR #476 (ognl-3-4-x) to main branch with adaptations for
backward compatibility. Lambda expressions in list operations (selection,
projection) can now access properties from the original context root via
#root references.

Root cause: Ognl.getValue() called context.withRoot(root) which overwrote
the context root during nested evaluations (e.g., when processing list items),
making original root properties inaccessible.

Solution: Conditionally preserve original root by only calling withRoot()
when context has no root, root matches existing root, or context is empty.
This maintains backward compatibility while fixing #root access in lambdas.

Changes:
- Modified Ognl.getValue() to preserve root context during nested evaluations
- Added Issue472CustomMethodAccessorTest with 5 comprehensive test cases
- All 612 existing tests pass, maintaining backward compatibility
- Short-circuit optimization preserved (not removed like in PR #476)

Fixes #472

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-authored-by: Claude <[email protected]>

- Remove SecurityManager references from code comments in OgnlRuntime.java
- Remove Google AppEngine SecurityManager documentation from README.md
- Keep historical references in VersionNotes.md as part of release history

SecurityManager was deprecated in Java 17 and removed in Java 21.
This change prepares the codebase for future Java versions.

Fixes #355

Co-authored-by: claude[bot] <41898282+claude[bot]@users.noreply.github.com>
Co-authored-by: Lukasz Lenart <[email protected]>

…-plugin to v3.2.0 (#488)

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

…ven-plugin to v5.3.0.6276 (#490)

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

…gin to v3.5.0 (#492)

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

* refactor: change null-safe operator syntax from .? to ?.

Changes the null-safe navigation operator from ".?" to "?." to align
with industry-standard syntax used by Kotlin, TypeScript, C#, and Groovy.
This improves consistency across programming languages and provides a
more familiar syntax for developers coming from other ecosystems.

Updated components:
- Grammar definition in ognl.jj (token and production rules)
- ASTChain implementation (JavaDoc and toString method)
- All null-safe operator tests (4 test files)
- Documentation (NullSafeOperator.md and LanguageGuide.md)
- Updated rationale to emphasize language consistency

All 683 tests pass with the new syntax.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <[email protected]>

* refactor: reduce cognitive complexity in ASTChain.toString()

Extracted nested condition into shouldAppendNavigationOperator() helper
method to reduce cognitive complexity from 17 to below the threshold of 15.

This addresses the SonarCloud code smell (java:S3776) by improving code
readability and reducing the nesting level in the toString() method.

Changes:
- Extract complex condition into private helper method
- Simplify nested if statement with single condition check
- Maintain identical behavior while improving maintainability

All 683 tests pass.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <[email protected]>

* docs: add SonarCloud integration details to CLAUDE.md

Added comprehensive SonarCloud documentation including:
- Project key and URLs
- How to view PR-specific issues
- Available MCP tools for SonarCloud integration
- Common SonarCloud rules encountered in OGNL
- Best practices for addressing quality issues

This helps future development by providing clear guidance on:
1. Using SonarQube MCP tools to fetch and address issues
2. Understanding common code smells specific to this project
3. Following quality gate requirements for PRs

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <[email protected]>

---------

Co-authored-by: Claude <[email protected]>

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

…plugin to v3.4.0 (#500)

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

… classes in method resolution (#485)

* fix(method-resolution): prefer accessible methods over internal implementation classes (#286)

This fix addresses issue #286 where OGNL was selecting methods from
internal JDK implementation classes (like sun.security.x509.X509CertImpl)
instead of their public interfaces (like java.security.cert.X509Certificate),
causing IllegalAccessException due to Java module system restrictions.

Changes:
- Added isLikelyAccessible() helper method to check if a class is likely
  accessible considering the Java module system
- Enhanced findBestMethod() tie-breaking logic to prefer methods in this order:
  1. Accessible classes over inaccessible ones
  2. Interface methods over class methods (better encapsulation)
  3. Public classes over non-public classes
- Added comprehensive test cases in Issue286Test.java

The fix uses the Java Module API to check if packages are exported and
includes heuristics for known internal packages (sun.*, jdk.internal.*, etc).
This ensures OGNL selects the most accessible method variant when multiple
methods with the same signature exist in the class hierarchy.

Fixes #286

* refactor: remove 'test' prefix from test method names (JUnit 5 convention)

* test: expand Issue286Test coverage with comprehensive test scenarios

- Added 8 new test cases covering edge cases and different scenarios
- Tests now include: varargs, overloaded methods, abstract classes, generics,
  collections, interface inheritance, factory patterns, null handling, and primitives
- Added assertions on actual values, not just non-null checks
- Comprehensive coverage of method resolution tie-breaking logic
- Tests exercise different code paths in isLikelyAccessible() and findBestMethod()

* fix: simplify method resolution logic to be more conservative

- Focus on the core issue: prefer accessible over inaccessible methods
- Remove aggressive interface-over-class preference that could break existing tests
- Keep original tie-breaking logic (prefer public classes) when both methods
  have the same accessibility level
- Add null/empty package name check for safety
- This should fix #286 while maintaining backward compatibility

* test: remove problematic varargs test and clean up unused imports

- Removed interfaceMethodWithVarargs test that was failing due to OGNL varargs syntax limitations
- Removed unused VarargsInterface and VarargsImplementation classes
- Cleaned up unused imports (SSLContext, certificates, etc.)
- Simplified x509CertificateMethodResolution test comment
- Still have 14 comprehensive tests covering the fix

* test: add more comprehensive test cases for method resolution

- Added tests with actual JDK classes (HashMap, ArrayList, StringBuilder)
- Added test for package-private class to test accessibility logic
- Added tests for multiple interface inheritance
- Added tests with java.util classes to exercise different code paths
- Tests now cover Map vs HashMap, List vs ArrayList scenarios
- Total of 19 test cases covering various method resolution scenarios

* test: add interface-based method resolution tests

- Added tests for CharSequence and Comparable interfaces
- Added test to verify methods from both interfaces and classes are found
- Added HashMap/Map test to verify interface vs concrete class handling
- Tests cover various JDK interface scenarios
- Now 22 test cases total providing comprehensive coverage of accessible code paths

Note: Tests for inaccessible internal classes (sun.*, com.sun.*, etc.) cannot
be easily added as we cannot instantiate those classes in unit tests. The
inaccessibility detection logic is designed to handle real-world scenarios
where OGNL encounters actual internal JDK implementation classes.

* feat: make isLikelyAccessible() testable and add direct unit tests

- Changed isLikelyAccessible() from private to package-private for testing
- Added OgnlRuntimeAccessibilityTest with comprehensive coverage
- Tests verify interface detection, standard JDK classes, and internal package detection
- Tests attempt to load actual sun.* and com.sun.* classes to verify inaccessibility detection
- Handles ClassNotFoundException gracefully for classes that may not be available
- Significantly improves code coverage by testing the method directly

* test: add simulated internal classes to improve coverage

- Created sun.test.SimulatedInternalClass to simulate sun.* internal classes
- Created sun.test.PublicTestInterface for testing interface preference
- Created com.sun.test.AnotherInternalClass to test com.sun.* detection
- Added tests that verify classes in sun.* and com.sun.* are detected as inaccessible
- Added simulatedInternalClassVsInterface test to exercise the key code path
- Added simulatedInternalClassIsDetectedAsInaccessible for direct verification
- These simulated classes allow coverage of the (!currentAccessible && newAccessible) branch
- Updated OgnlRuntimeAccessibilityTest with additional test cases

This significantly improves coverage by allowing us to test the actual
accessibility preference logic without needing real internal JDK classes.

* fix: remove direct isLikelyAccessible() calls from Issue286Test

Issue286Test is in package ognl.test and cannot access the package-private
isLikelyAccessible() method in package ognl. Direct testing of that method
is already covered in OgnlRuntimeAccessibilityTest which is in the correct
package.

The simulatedInternalClassVsInterface() test still provides end-to-end
coverage of the fix by using classes in sun.test package.

* test: remove useless tests with no assertions

- Removed defaultPackageClassIsAccessible() which had no assertions
- Removed jdkInternalPackageWouldBeInaccessible() which only tested string operations
- These tests provided no actual coverage or value
- All meaningful test cases are already covered by other tests

* Cleans up test

---------

Co-authored-by: Claude <[email protected]>

) (#486)

This commit resolves Issue #103 where the OGNL parser would fail to parse
class references containing reserved keywords (like "or", "and", "not", etc.)
in package names.

Problem:
--------
Expressions like `@jp.or.example.IdUtils@generateId()` would fail at parse
time with ExpressionSyntaxException because "or" was tokenized as a keyword
rather than as part of the package name.

Root Cause:
-----------
In JavaCC, string literals used as operators in grammar productions (e.g.,
"or" for logical OR) become implicit keyword tokens that take precedence
over generic IDENT tokens during lexical analysis.

Solution:
---------
- Added new `classNamePart()` production that accepts either IDENT tokens
  or any reserved keywords, treating them as identifiers in the context
  of class/package names
- Updated `className()` production to use `classNamePart()` instead of
  direct IDENT references
- Updated `instanceof` production similarly to handle keywords in type names

Changes:
--------
- Modified: ognl/src/main/javacc/ognl.jj
  - Added classNamePart() helper production (lines 1389-1418)
  - Updated className() to use classNamePart() (lines 1374-1382)
  - Updated instanceof production to use classNamePart() (lines 948-969)

- Added: ognl/src/test/java/ognl/test/PackageKeywordTest.java
  - Comprehensive test coverage for keywords in package names
  - Tests for: or, and, not, in, and multiple keywords
  - Validates that parsing succeeds (no ExpressionSyntaxException)

- Added: ISSUE_103_ANALYSIS.md
  - Detailed analysis of the problem and solution
  - Impact analysis and backward compatibility notes
  - Build and verification instructions

Impact:
-------
- Fully backward compatible (only expands valid expressions)
- No ambiguity introduced (context is unambiguous)
- Keywords remain functional as operators in expression contexts
- Aligns with real-world Java package naming (e.g., jp.or.* domains)

Testing:
--------
The fix requires regenerating the parser via `mvn compile` which runs the
javacc-maven-plugin. All existing tests should continue to pass.

Fixes #103

Co-authored-by: Claude <[email protected]>

Address multiple SonarCloud code quality issues:

- Add missing @OverRide annotations (java:S1161)
- Use pattern matching for instanceof (java:S6201)
- Reduce cognitive complexity by simplifying nested conditions (java:S3776)
- Extract string literals "_currentChain" and "_lastChild" as constants (java:S1192)
- Improve exception handling by catching Exception instead of Throwable
- Improve code readability with isEmpty() and better variable naming

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-authored-by: Claude <[email protected]>