The Java evening that fails is not the assertion. It is ./gradlew test pulling a JDK the wrapper pinned, or mvn test filling ~/.m2 while the ticket waits. Get that command green on the default branch before you open the method the issue named.

Generic hunting: how to find good first issues. Multi-language picking: best open source projects for beginners. Merge checks: how to pick an issue that will get merged. This URL is the Java filter.

Open the Java hub

Java hub

Labeled good-first and help-wanted issues on active GitHub repos whose language is Java. On 2026-08-31: about 2,244 labeled issues at 10+ stars. Snapshot. It moves.

Not writing Java? The homepage is the language switch.

Read the body. Skip stale, claimed, and repos that have not merged lately. I am not listing famous projects. A leftover label on a well-known name is still leftover. The feed is the hub, ticket by ticket.

JUnit: one test next to the method

The mergeable first Java PR is usually one JUnit test beside the method the issue named. Same package. Same src/test/java tree they already use. JUnit 5 if pom.xml / build.gradle already pulled it. JUnit 4 if that is the suite.

That is the job. It is not:

Adding TestNG because you like it on your laptop
Rewriting the class’s existing tests into a new style
Migrating JUnit 4 to 5 as a side errand
Inventing a runner, a @Rule, or an Extension the suite does not use
A @ParameterizedTest rewrite of cases the ticket did not name

FooTest next to Foo. One method. Assert the behavior the issue described. Run that test class, not the universe, unless CONTRIBUTING says otherwise.

If the project tests with JUnit, you test with JUnit. Do not “improve” the harness on issue one.

The first evening is Gradle or Maven going green

In Java the real first sitting is often getting ./gradlew test or mvn test green locally. Wrappers, toolchains, a daemon, a local cache. That hour is not wasted. If the ticket is a wrapper script, a README that names the wrong task, or a build-docs line that still says gradle test when the repo ships ./gradlew, that is a real first PR.

Do not upgrade Gradle. Do not bump the Maven wrapper, the plugin BOM, or the JDK toolchain “while you are here.” Version bumps review as policy and stall the JUnit case.

CONTRIBUTING will name the command. Run it on the default branch first. If the wrapper cannot boot on your machine, pick another ticket. Debugging a broken toolchain is two projects.

A green ./gradlew test / mvn test on main is the gate. The code change comes after.

Spring-ish size is not library size

A labeled ticket in a huge Spring-ish framework is not the same size as a labeled ticket in a small library. The badge is the same string. The review is not.

Huge framework: the class you touch is imported by a hundred modules. The test you want needs a context you cannot boot in one sitting. “Good first” there often means they need a volunteer who already lives in this tree.

Smaller library: a handful of modules, a method, a test you can run with the wrapper. Prefer that surface for issue one.

I am not listing famous Spring repos. Filter the Java hub and judge the repo surface, not the brand.

After a merge in a small lib, issue two can be a framework leaf. Not before.

Checkstyle, Spotless, google-java-format: the hunk

Java formatters are loud. Checkstyle, Spotless, google-java-format will rewrite a 2,000-line class because the editor offered.

Do not format the module. Do not format the file because import order looked messy. That hunk fights every open PR on the same class.

Rules:

Format only the lines you changed
If CONTRIBUTING says run Spotless / google-java-format before push, run it, then restore files the issue did not name
Never open a whole-module format PR
Leave checkstyle.xml, Spotless config, and .editorconfig alone unless that file is the ticket
Pre-existing warnings on lines you skipped stay

A formatted test is hygiene. A module-wide reformat is a closed PR.

JDK internals and framework core wait

java.base, hotspot-adjacent code, javac internals, and the core of a DI / servlet / framework runtime look labeled and are still issue two. Those files have implicit contracts. The badge means they want help. It does not mean the patch is first-timer sized.

Issue one is a leaf: one JUnit next to the method, a wrapper/docs fix that unblocks ./gradlew test, a small library — not the framework core.

After a merge in that repo, you can go inward.

Ship one ticket

Filter on the Java hub. Drop stale and claimed. Confirm recent merges. Prefer a small library over a Spring-ish surface.
Read CONTRIBUTING.md for ./gradlew test or mvn test and the formatter. Get default branch green.
Comment on one issue.
Diff stays on the ticket. One JUnit next to the method. Hunk-only Checkstyle/Spotless/google-java-format. No Gradle/Maven upgrade. Fixes #123. Say which test command you ran. Stay for review.

Git: first pull request guide. Week-1: how to contribute to open source.

FAQ

Should I add TestNG or rewrite the suite to match my laptop?

No. One JUnit test next to the method the issue named. Do not add TestNG. Do not migrate JUnit 4 to 5. Do not restyle the class’s existing tests. Do the ticket.

The wrapper takes forever. Is a build-docs or wrapper fix a real first PR?

Yes. Getting ./gradlew test or mvn test green locally is the actual first evening. A README or wrapper ticket that unblocks that command is a real merge. Upgrading Gradle or Maven as a souvenir is not.

Can my first issue be in a huge Spring-ish framework?

Prefer a smaller library. A labeled ticket in a giant framework is not the same size as a labeled ticket in a three-module lib. Do not pick by brand. Judge the surface. Framework core waits for issue two.

Should I run Spotless or google-java-format on the whole module?

No. Format the hunk you touched. A whole-module Checkstyle / Spotless / google-java-format PR is a style diff. Reviewers close it or make you revert. If CI formats the module, let CI.

Where do I find live Java good first issues?

On the Java hub. Filter, skip stale and claimed threads. Read CONTRIBUTING for the test command and the formatter. Other languages: the homepage.

Start here

Open the Java hub. Pick one unclaimed ticket that is one JUnit test, a wrapper/docs fix that makes ./gradlew test or mvn test green, or a small library — not a Spring-ish core class. Comment once, format only what you touched, keep the diff on that job, and stay for review. Not writing Java tonight? The homepage is the language switch.