Help make the library
a little better.

Filing a good bug report

A useful report has three parts:

1. What you ran — the smallest snippet that reproduces the problem.
2. What you expected — including the JDK version, library version, and OS if relevant.
3. What you got — the actual error, stack trace, or wrong output.

Library version: 06.01.01
JDK:             OpenJDK 21
OS:              macOS 14 / Linux 6.6

Code:
  Result<Integer> r = Result.ofNullable("oops").map(Integer::parseInt);

Expected: Failure with the parse error as the reason.
Got:      NumberFormatException thrown.

Open it at github.com/svenruppert/functional-reactive/issues.

Submitting a pull request

The flow is:

1. Discuss first — for anything beyond a typo or a one-line fix, open an issue describing the change. We agree on the shape, then you write the code.
2. Fork & branch — branch off main, prefix the branch with fix/, feat/ or docs/ plus a short slug.
3. Stay small — one logical change per PR. A 200-line PR reviewed in a day is more useful than a 2000-line PR that sits for a month.
4. Tests required for code changes — add at least one JUnit 5 test that fails without your change and passes with it.
5. Run the build locally — mvn clean install should pass before you push.
6. Keep style consistent — match the surrounding code. No re-flowing unrelated files; the diff should be the change you want to land.

Local development

git clone https://github.com/svenruppert/functional-reactive
cd functional-reactive
mvn clean install

The build needs JDK 8+ on the path. If you’re on a newer JDK, the project still builds fine — the produced bytecode targets 8 (or whatever the pom.xml’s maven.compiler.release is set to).

Run only the tests:

mvn test

Run a single test class:

mvn test -Dtest=ResultTest

Code style

Nothing exotic. Match the surrounding code. A few specific points:

• No checkstyle / spotless gate — readability beats mechanical conformance. The reviewer flags style issues during review.
• Public API gets Javadoc. Internal helpers don’t have to.
• No comments restating what the code does. Comment the why — the surprising invariant, the workaround for a specific bug, the design choice a future reader won’t infer from the names.
• No new runtime dependencies without prior discussion. Hamcrest is the only test-scope dependency; that’s the bar.
• JDK 8 baseline. Records, switch patterns, var, sealed classes — fine in tests, not in src/main/java. The optional Java-21 module path (when it exists) is separate.

What gets accepted, and what doesn’t

Easy yes:

• Bug fixes with a regression test.
• Doc improvements, typo fixes, clearer examples.
• New utility methods that fit existing patterns (e.g. a new StringFunctions predicate).
• Test-coverage improvements for existing public API.

Discuss first:

• New top-level types or packages.
• Anything that changes a public API signature.
• New dependencies, build-tool changes, parent-POM bumps.

Probably no:

• “Make it more like <framework X>” rewrites.
• Mechanical reformatting that touches files you didn’t otherwise change.
• Replacing the licence, the build tool, the JDK baseline, or the test framework on a whim.

Licensing & signing off

All contributions are licensed under EUPL 1.2, the same licence the library uses. By submitting a PR you confirm that you have the right to license your contribution that way. There is no separate CLA to sign — your PR description and Git history are enough.

If the change is non-trivial, please add a Signed-off-by line to your commits:

git commit -s -m "feat: add Foo.bar()"

Community

By participating in this project’s discussions, issues, and PRs, you agree to follow the Code of Conduct. Be kind, be specific, assume good faith.

Thank you

Open source happens because people show up. If you take the time to file a careful bug report or a thoughtful PR, you’re keeping this library alive for everyone else using it. That matters. Thank you.