pmd / pmd/pmd

[core] Turn PropertySource into PropertyBundle

Open
#3,869 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

an:enhancement
Dominant language
Java
Stars
5.5k
Forks
1.6k
Avg merge
1d 19h
Merged PRs (30d)
54

Description

Is your feature request related to a problem? Please describe.
The interface PropertySource is used to add the ability to have properties to rules and renderers and some other things. The interface is pervasive in our codebase and is a problem:

  • It's really not an interface, it's an abstract class, because it's so complicated to implement (and requires several fields) that if you implement PropertySource you have to extend transitively from AbstractPropertySource.
  • This strengthens the same dynamic between Rule and AbstractRule, if you extend Rule you have to extend AbstractRule. If you want a delegate rule you need to delegate 20 methods from PropertySource.
  • We can't replace PropertySource or make it evolve easily because every inheritor (every rule and renderer) is affected directly

Describe the solution you'd like

I think we would have much cleaner interfaces if we just renamed AbstractPropertySource to PropertyBundle (with the same functionality, but not abstract), and have the Rule interface have a method PropertyBundle getProperties(). We only need one implementation of the bundle.

Additionally, this allows us to implement custom PropertyBundle implementations, eg an IgnoredAnnotationsPropertyBundle which predeclares a property and adds nice getters. We can share property-related things between rules without having to put shared logic in a base rule class, which is more inflexible. This will also come in handy with language properties #2518.

Note that TreeRendererDescriptor already uses PropertySource in this way: instead of extending the interface it just uses an instance. I'd like to use the same model for #2518 and eventually for the large rule API restructuring needed for #3868

Describe alternatives you've considered

Additional context

  • #1432
  • Removing getDysfunctionReason from PropertySource is related to #3868

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by tracing PropertySource, AbstractPropertySource, Rule, AbstractRule, and TreeRendererDescriptor usages across the core API. Compare the existing PropertySource instance model in TreeRendererDescriptor with the proposed Rule.getProperties() model, then identify the affected rules and renderers. Done means the property bundle replaces the inheritance-based API without breaking its consumers or the related restructuring goals in #2518 and #3868.

Written by the indexing model from the issue text.

Assessment

Tech stack
java
Domain
backend-api-design
Issue type
Refactor
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.