Add ADR for DI

[InAnYan]

User description

Closes https://github.com/JabRef/jabref-issue-melting-pot/issues/590

Just added an ADR.

Steps to test

No steps to test. Just check the contents.

Mandatory checks

• I own the copyright of the code submitted and I license it under the MIT license
• I manually tested my changes in running JabRef (always required)
• [/] I added JUnit tests for changes (if applicable)
• [/] I added screenshots in the PR description (if change is visible to the user)
• [/] I described the change in CHANGELOG.md in a way that is understandable for the average user (if change is visible to the user)
• I checked the user documentation: Is the information available and up to date? If not, I created an issue at https://github.com/JabRef/user-documentation/issues or, even better, I submitted a pull request updating file(s) in https://github.com/JabRef/user-documentation/tree/main/en.

---

PR Type

Documentation

---

Description

• Adds ADR 0055 documenting dependency injection strategy

• Defines hybrid approach: DI framework for JavaFX views, constructor-based DI for core logic

• Explains rationale balancing JavaFX constraints with architectural clarity

• Documents decision drivers, options considered, and verification methods

---

Diagram Walkthrough

flowchart LR
  A["DI Strategy Decision"] --> B["JavaFX Views<br/>DI Framework"]
  A --> C["Core Logic<br/>Constructor-based DI"]
  B --> D["Empty constructors<br/>Field injection"]
  C --> E["Explicit dependencies<br/>Testable"]

Loading

File Walkthrough

Relevant files

Documentation

0055-dependency-injection-approach.md ADR for hybrid dependency injection approach                          docs/decisions/0055-dependency-injection-approach.md New ADR document establishing hybrid dependency injection strategy Defines use of DI framework for JavaFX views with empty constructors Specifies constructor-based DI for core logic layer Documents decision drivers, considered options, consequences, and verification methods +67/-0

---

[InAnYan]

• TODO: We use @Inject only in Views, not in ViewModels. And this again helps in testing, as ViewModel uses constructor-based DI

[koppor]

• TODO @Inject for JAX-RS services - there, we use jakarta.inject.Inject and hk2: org.glassfish.hk2.api.ServiceLocator

[calixtus]

https://github.com/dlsc-software-consulting-gmbh/FxmlKit

[qodo-free-for-open-source-projects]

PR Compliance Guide 🔍

Below is a summary of compliance checks for this PR:

Security Compliance
🟢	No security concerns identified No security vulnerabilities detected by AI analysis. Human verification advised for critical code.
Ticket Compliance
⚪	🎫 No ticket provided Create ticket/issue
Codebase Duplication Compliance
⚪	Codebase context is not defined Follow the guide to enable codebase context checks.
Custom Compliance
🟢	Generic: Comprehensive Audit Trails Objective: To create a detailed and reliable record of critical system actions for security analysis and compliance. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Meaningful Naming and Self-Documenting Code Objective: Ensure all identifiers clearly express their purpose and intent, making code self-documenting Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Robust Error Handling and Edge Case Management Objective: Ensure comprehensive error handling that provides meaningful context and graceful degradation Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Secure Error Handling Objective: To prevent the leakage of sensitive system information through error messages while providing sufficient detail for internal debugging. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Secure Logging Practices Objective: To ensure logs are useful for debugging and auditing without exposing sensitive information like PII, PHI, or cardholder data. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Security-First Input Validation and Data Handling Objective: Ensure all data inputs are validated, sanitized, and handled securely to prevent vulnerabilities Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
Update

Compliance status legend

🟢 - Fully Compliant
🟡 - Partial Compliant
🔴 - Not Compliant
⚪ - Requires Further Human Verification
🏷️ - Compliance label

[qodo-free-for-open-source-projects]

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Impact
Learned best practice	Fix grammatical error in documentation Fix grammatical error: "too much" should be "too many" when referring to countable nouns like arguments. docs/decisions/0055-dependency-injection-approach.md [11] -However, sometimes there are too much arguments in a constructor. +However, sometimes there are too many arguments in a constructor. [To ensure code accuracy, apply this suggestion manually] Suggestion importance[1-10]: 6 __ Why: Relevant best practice - Correct grammatical errors in documentation to maintain professionalism and clarity	Low
	Fix grammatical error in documentation Fix grammatical error: "as a fields" should be "as fields" (remove the article "a" before the plural noun). docs/decisions/0055-dependency-injection-approach.md [40] -classes that are necessary for the view model are injected as a fields in view class. +classes that are necessary for the view model are injected as fields in view class. [To ensure code accuracy, apply this suggestion manually] Suggestion importance[1-10]: 5 __ Why: Relevant best practice - Correct grammatical errors in documentation to maintain professionalism and clarity	Low
Update

[calixtus]

Something is still thinking about is: To some extent our current solution for DI resembles in my eyes a ServiceLocator (see https://www.baeldung.com/java-service-locator-pattern#locator_di ). Is this true? Is this wanted? Don't we have to move to another solution? Do we have to include that in this PR?

[jabref-machine]

You modified Markdown (*.md) files and did not meet JabRef's rules for consistently formatted Markdown files. To ensure consistent styling, we have markdown-lint in place. Markdown lint's rules help to keep our Markdown files consistent within this repository and consistent with the Markdown files outside here.

You can check the detailed error output by navigating to your pull request, selecting the tab "Checks", section "Source Code Tests" (on the left), subsection "Markdown".