drccrd opened a new pull request, #3999: URL: https://github.com/apache/incubator-kie-tools/pull/3999
Closes https://github.com/apache/incubator-kie-tools/issues/3966 ### What changes Java permits only statics directly after a type name. Completion offered the *instance* view there — the one set that cannot legally follow a type name — and hover described a static as nothing. `JavaMemberSource` gains `staticFieldsOf` (name and type) and `staticMethodsOf` (signatures), implemented by reflection in `ClassMemberIndex` and from the parsed model in `JavaSourceTypeIndex`, both following `constructorsOf`'s existing fallback-on-load-failure pattern. `JavaSourceType`'s static field *names* became typed fields plus method signatures; the parser already saw the modifiers and the type, and was discarding the latter. The consumers needed little: both walks already knew whether a chain head was a type reference or a value, and neither propagated it. Each now does, clearing the flag after one hop — `Rounding.SCALE.precision` resumes instance members, because a constant is an ordinary value of its own type. Also fixed, since a type's own hover never showed statics either: its "Constants" section was filtered from `membersOf`, which excludes statics, so it could only ever populate for an enum. A type whose whole API is static (`java.lang.Math`, a constants holder) rendered as a bare header. ### Notes for review - **Interface constants moved to the static view.** An interface field is implicitly `public static final`, so reflection reports it only as a static; the source path had it in `membersOf`. This is the one change to existing behaviour beyond statics, and it improves parity between the two paths. - **Qualified type names get the same treatment**, so `Order.X` and `com.example.Order.X` agree. Not in the issue text, but the alternative is the two disagreeing. - **Inherited statics are included** (`getFields()`/`getMethods()`), since Java permits reaching an inherited static through a subtype's name. - Static method signatures carry the return type (`describe(int, String) : String`); constructors keep the shape they had. - Removed `isPublicInstanceMember`, now dead — its javadoc argued statics should not be modelled separately, which this reverses — and renamed `constructorSignature` to `signatureOf`, shared by methods and constructors. ### Verification `mvn test` in `packages/drools-lsp`: drools-completion 392, drools-lsp-server 52, all green, from a 370-test baseline on `main`. 22 new tests across the seam, both member sources, completion and hover, including the issue's own reproducer (`Pet.` no longer offering `name`/`friendly`/`legs`) and a parity test holding the source and reflected views to each other rather than to a hand-written expectation. No client files touched. ### Possible follow-ups Two gaps found while exercising this, both wider than statics and neither attempted here: 1. **Go-to-definition on members.** `DRLDefinitionHelper` resolves a single word to a *type* and jumps to its declaration; there is no chain walk, and `JavaSourceLocator` locates types by regex with no notion of member positions. So `Rounding.SCALE` fails because go-to-definition on any member is unsupported, instance or static. 2. **Bindings to method calls.** `LhsBindingResolver` models field, nested-path, accumulate and JDK-accessor bindings but not calls, so `$x : Rounding.roundHalfUp(y)` resolves to nothing in hover and in inlay hints — as does `$x : $order.getTotal()`. The accumulate case shows the shape a fix would take (an injected lookup, keeping the resolver pure regex over text), but inlay hints currently receive no `ClassMemberIndex` or `ClassIndex`, so it would widen that helper's API. Overload ambiguity is an open question there: the binding site carries an argument list the resolver does not type-check. 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
