murdos opened a new pull request, #415: URL: https://github.com/apache/commons-jexl/pull/415
Property access (\`foo.bar\`) never resolves to a record's generated \`bar()\` accessor, only to \`getBar()\`/\`isBar()\`, a public field, or a duck-typed \`get(Object)\`. \`point.x\` on a record \`Point(int x, int y)\` throws \`JexlException$Property: undefined property 'x'\` today (or silently evaluates to null with \`strict(false)\`), and the only workaround is adding a manual bean-style getter on the record, which defeats the point of using one. This adds a \`RecordGetExecutor\`, tried right after the existing \`PropertyGetExecutor\`/\`BooleanGetExecutor\` so a record that already defines its own \`getFoo()\` keeps behaving exactly as before. It matches the property name against the class's record components, then resolves the actual accessor \`Method\` through the existing (permission-checked) \`Introspector\`, so record accessors go through the same sandboxing as every other property access. Detection and lookup use reflection only (\`Class#isRecord()\`, \`Class#getRecordComponents()\`, looked up once and cached) rather than compiling against these APIs directly, since the module still targets Java 8 - on such a runtime the lookup just fails to find the methods and quietly reports no match, same as it does today. The test compiles its record fixtures on the fly with \`javax.tools.JavaCompiler\` and skips itself below Java 16, for the same reason: \`record\` isn't valid source at this module's language level. No JIRA ticket yet - happy to open one if that's preferred before this gets reviewed. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
