Last updated: September 10, 2026
By Devin Hornick, Co-Founder and Partner, KORE1
The Java developer job descriptions that fill in 2026 state the JDK version and Spring Boot generation the team runs, say whether the hire builds new services or maintains existing ones, and post a salary range. Most templates ranking for this search skip all three. Two of those three also picked up hard deadlines this year, which is the main reason I’d rewrite a Java posting from last spring instead of reposting it.
One of the most-copied Java templates online still lists a Sun Certified Java Developer credential under requirements. I checked. Sun Microsystems became part of Oracle in 2010.
That’s the whole problem in one line, really. I’ve been recruiting since before anybody said “J2EE” out loud, and over that stretch the language has changed almost beyond recognition while the postings people write for it have barely moved at all. Same responsibilities. Same wall of acronyms. Same “5+ years of Java” doing all the filtering.
This fall the gap got expensive. Free Oracle JDK 21 updates end with the September 2026 patch, Oracle’s Premier Support for JDK 17 ends the same month, and Spring Boot 3.5, the final 3.x release, dropped out of open-source support on June 30. Plenty of the Java reqs going out between now and next spring are upgrade reqs in disguise. Their postings leave that out.
About my angle. KORE1 is a firm I helped start in 2005, and our Java developer staffing desk, part of our wider IT staffing services practice, gets paid when one of our candidates is hired, so weigh what follows with that in mind. The template doesn’t need us. I’d genuinely rather you post a sharp req yourself than a vague one with our logo on it, because the vague ones tend to find their way back to us three months later anyway, and by then everyone involved is tired.
What this page won’t do is decide which kind of Java engineer you need. Backend services, legacy maintenance, streaming data, and Android are four different searches, and our guide to hiring a Java developer works through that choice first. If the seat is really mobile, start from the Android developer job description instead. Everything below is for the most common Java hire I see, a server-side engineer working in Spring, and it gets specific fast.
The Job Behind the Title
A Java developer designs, builds, tests, and supports applications that execute on the Java Virtual Machine (JVM), most often server-side Spring Boot services that move money, process claims, route shipments, or run a SaaS product’s API. Senior Java developers also own the harder layer underneath, which is performance, concurrency, and keeping the codebase on a supported version.
A senior engineer we placed last year walked me through her week once. She reviewed two pull requests on the payments service on Monday. Tuesday went to a Kafka consumer that kept lagging for no reason anyone could find, which turned out to be a connection pool somebody had sized for last year’s traffic and never revisited. The Flyway migration landed an hour before Thursday’s release. She lost an argument on Friday about the monolith and is still a little annoyed about it. Most weeks go like that.
Python gets the headlines these days. Java still runs the ledgers. In the 2025 Stack Overflow Developer Survey, 29.4% of all respondents reported working in Java and 14.7% in Spring Boot, and O*NET, the Labor Department’s occupational database, flags both Spring Boot and the Spring Framework as in-demand technologies for software developers. Lots of people still write Java. Far fewer want to write it for a company whose posting reads like 2012.
The JDK Version Line, and Why It Got Urgent
The version line gets read more closely than anything else in a Java posting. Senior engineers treat it as a confession about tech debt and a preview of their next twelve months. They’re usually right on both.
A payments company in Newport Beach sent us a req last winter asking for “Java 8+.” Their ledger service actually ran on Java 21 with virtual threads in production, which is exactly the kind of work strong engineers go hunting for. Nobody could tell. The “8+” read like a floor they were still standing on, and the three best candidates we talked to all asked, before anything else, how much Java 8 was left in the building. They’d killed it in 2024. We changed the line to “Java 21 in production, moving to 25 in the first quarter,” and the next round of first calls was about the ledger instead of the legacy.
Then there’s the calendar. Oracle’s Java SE support roadmap spells it out. Any Oracle JDK 21 update released after September 2026 ships under the Java SE OTN license rather than the free No-Fee Terms and Conditions, and OTN is the license Oracle already uses for Java 8 and 11 and 17 and, for most companies running Java in production, the one that comes with an invoice. Java 25, the current long-term release, stays free under those no-fee terms until October 2028, according to Oracle’s own Java blog. So a shop running Oracle’s JDK 21 has three options this fall. Upgrade to 25, start paying Oracle, or move to another OpenJDK build. Finance will notice.
Running Eclipse Temurin, Amazon Corretto, or Azul instead? Your dates differ. The hiring question doesn’t. Somebody is going to do that upgrade eventually, and the posting should say whether it’s the person you’re about to hire.
| What runs in production today | A version line that tells the truth | Who tends to raise a hand |
|---|---|---|
| Java 8 (released 2014) | “Java 8 on [WebLogic 12c / Tomcat 9] today, with a funded move to Java 21 or 25 starting [quarter].” | Engineers who have run an upgrade and want another. With no funded move, say so, and expect maintenance specialists |
| Java 11 or 17 | “Java 17 across [N] services. The move to 25 is on this year’s roadmap, and you’d help sequence it.” | Mid and senior people who like modernizing a system that already works |
| Java 21 | “Java 21 in production, virtual threads in [service], evaluating 25 before [date].” | The broad middle of the senior market. Your most competitive row |
| Java 25 | “Java 25 in production.” Then name one newer feature your team actually uses. | People who follow the release train closely. Expect questions about your upgrade cadence |
| Several at once | “Our services range from Java 8 to 21, and you’d own [these specific ones].” | Engineers who have worked inside real enterprises and aren’t rattled by it |
That last row is more common than all the others put together, in my experience. Nobody’s codebase is clean. Almost every mid-market Java shop runs at least two versions, and saying so costs you nothing with the engineers you’d actually want.
Spring Boot 3 or 4, and Who Does the Jump
Same logic, one layer up the stack. Spring Boot 4.0 shipped on November 20, 2025, on top of Spring Framework 7, with first-class Java 25 support and Java 17 kept as the minimum. The jars got split into smaller modules. Null-safety moved to JSpecify annotations across the portfolio, and API versioning arrived as a built-in feature. Nothing exotic. Different enough, though, that “Spring Boot experience” in a 2026 posting no longer tells anyone which Spring Boot you mean.
The Spring Boot support schedule is what turns that into a deadline. Open-source support for 3.5 ended June 30, 2026, and 4.0’s window closes December 31, which makes 4.1 the line most teams should be heading toward. Plenty of teams missed June. Commercial support runs longer on every branch, if you’re paying for it. Most teams aren’t. Still on 2.7? Free support for that one ended in June 2023, and getting to 3 means the javax-to-jakarta namespace switch that arrived with Jakarta EE 9, which renames every import that used to start with javax.persistence or javax.servlet.
A logistics software company in Costa Mesa learned this the hard way. They hired a strong senior engineer for “new feature development on our Spring Boot platform,” and in week two his manager handed him the 2.7-to-3 upgrade, roughly 1,400 javax imports plus a Hibernate 6 query regression in the billing module that nobody had budgeted a single hour for. The imports were easy. OpenRewrite’s Jakarta migration recipe handled most of them in an afternoon. The billing queries took six weeks, and he spent all six feeling like he’d been hired under somebody else’s job title. He stayed. Barely.
So put it in writing. “We’re on Spring Boot 3.5, and leading the move to 4.1 is about a third of your first six months.” Or, if someone else has it covered, “a contractor finishes our Spring Boot 4 upgrade this quarter, and you’ll own the result.” Either one works fine. Leaving it out and letting week two break the news is what doesn’t.
J2EE, Struts, and Other Carbon Dates
Java postings love a long list of frameworks. To the person writing it, the list looks thorough. To a senior engineer, it’s carbon dating.
An Irvine specialty insurer we’d worked with for years once posted “Senior Java Developer, Java 11+, Spring Boot, microservices, AWS.” All true, technically, in the sense that each of those things existed somewhere in the building. The person they hired spent about sixty percent of his week inside a policy-administration monolith on Java 8 and WebLogic 12c, with a JSP billing screen that broke whenever anyone touched the rating engine. Good engineer. Came from a SaaS company. Nobody lied to him, exactly. He resigned in month five, politely, and I didn’t blame him a bit.
The second posting said it straight. “Java 8 on WebLogic today. Funded move to Java 21 and Spring Boot starting in Q3, and you’d lead it.” Applications fell from around 210 to 55. The pool shrank. It got better, too. Four weeks later they hired a senior engineer who had moved a Charlotte bank’s WebSphere estate onto Spring Boot and wanted to do it again somewhere that would let her finish.
Here’s how the most common lines in a Java framework list tend to land with the people reading them.
| Line in the posting | What a senior Java engineer infers | What to do with it |
|---|---|---|
| “J2EE” | Nobody has edited the template since around 2006, when J2EE was renamed Java EE | Cut it and name the real framework |
| “Java EE” | Probably written before the platform moved to the Eclipse Foundation and became Jakarta EE | Say Jakarta EE, or name the application server you actually mean |
| “Struts, JSF, JSP, EJB” | A server-rendered monolith, most likely built between 2005 and 2015 | Keep them if they’re true, and say whether they’re being retired |
| “WebLogic, WebSphere, JBoss EAP” | Application-server enterprise Java, often inside a regulated business | Keep, with version numbers. A real pool, and an underrated one |
| “Swing” or “AWT” | A desktop client | Only if you ship one. Some trading desks and plant-floor tools still do |
| “Sun Certified” anything | A template older than 2010 | Delete it. Oracle’s current Java exams are 1Z0-830 and 1Z0-831 |
| “Microservices,” with no number | Almost nothing | Say how many services exist and who deploys them |
| “Spring Boot, Kafka, Kubernetes” | Cloud-native services, and the most crowded candidate market | Fine. Add the versions and your cloud provider |
None of this is an argument against legacy work. I’ve always liked those searches. Some of the most contented Java engineers I’ve placed over thirty years wanted exactly the unglamorous seat, a stable WebSphere shop and a codebase older than the interns and a manager who didn’t pretend otherwise. That seat fills fast when it’s described honestly, since the engineers who want it are tired of being sold greenfield projects that turn out to be maintenance. It fills slowly when it isn’t. Sometimes it fills, and then fills again.
What Java Developers Earn in 2026
I’d publish the range. Washington, New York, Colorado, and California already make most employers post one, more states have followed, and candidates everywhere else have started to assume a posting without a number pays under market. Usually they’re right.
| Level | Typical U.S. base, 2026 | What this level scans the posting for |
|---|---|---|
| Junior, 0 to 2 years | $75,000 to $100,000 | Who reviews their code, and how quickly |
| Mid-level, 3 to 5 years | $100,000 to $135,000 | A service they’d own from API to on-call |
| Senior, 6 to 9 years | $135,000 to $175,000 | The version, the upgrade plan, and the on-call reality |
| Lead or staff, 10+ years | $170,000 to $210,000 | Scope across teams, and who they answer to |
| Low-latency or trading Java, 6+ years | $180,000 to $235,000 | The latency budget in microseconds, and how the bonus works |
These are the bands we published in our Java developer salary guide, built from public pay data plus our own placement records in 30-plus metros. For the whole occupation, O*NET’s 2025 median for software developers is $135,980, and it projects about 115,200 openings a year through 2034.
City matters. That same guide puts San Francisco about 24% above the national average and New York about 17% above it, and the low-latency row is really its own market, with bonuses that can rival base in a good year. Equity complicates it. For one specific city before the req goes to finance, our salary benchmark assistant is quicker than anything I could write here. I’d also repeat the band on the first screen, not just in the posting. A candidate who hears the number twice stops wondering whether it’s real.
Java Developer Job Description Template
Anything in square brackets is either a blank to fill or my commentary on why the line matters. Pull the commentary before it goes public. And cut freely. Every extra section is one more place for a good candidate to find a reason to pass.
Job Title
[Senior Java Developer / Java Software Engineer / Software Engineer, Java (Spring Boot)] [Keep Java in the title. If your leveling system insists on “Software Engineer II,” add Java in parentheses after it.]
About the Role
[Company] needs a [senior] Java developer to [own / build / modernize] [the specific system: our claims adjudication service / the order-routing platform behind 40,000 daily shipments / the payments API our mobile app depends on]. You’ll join a team of [number] engineers reporting to [named role], working most closely with [product, data engineering, the platform team]. [Location: fully remote, U.S. only / [N] days a week on site in [city] / fully on site in [city].]
The Codebase You’d Walk Into
[This is the section most postings skip and the one senior candidates read twice.]
- Java [8 / 11 / 17 / 21 / 25] in production today. [If more than one, say which services run which.]
- [Spring Boot 3.5 / Spring Boot 4.1 / Quarkus / Micronaut / Jakarta EE on WebLogic, JBoss EAP, or WebSphere], built with [Maven / Gradle].
- [Roughly N services, or one monolith about N years old] running on [AWS / Azure / GCP / on-prem VMware].
- Data lives in [PostgreSQL / Oracle Database / SQL Server / MongoDB], with [Kafka / RabbitMQ / IBM MQ] carrying events between services.
- [Upgrade status, stated plainly: “We’re moving from Spring Boot 3.5 to 4.1 this year, and you’d lead it,” or “A contractor finishes that work before you start.”]
- [Test and deploy reality: coverage around X%, releases [daily / weekly / monthly], CI on [GitHub Actions / Jenkins / GitLab].]
What You’ll Own
- Design, build, and ship features in [named service or product area], from the API contract through production
- [Production ownership, honestly stated: “Carry the pager one week in six for the services you work on.”]
- Review pull requests from [N] engineers, and get yours reviewed with the same rigor
- Track down JVM performance problems, including garbage-collection pauses, thread-pool starvation, and slow queries behind [Hibernate / jOOQ / plain JDBC]
- [Upgrade or migration work, with a share of time attached: “About a third of your first six months goes to the Java 25 upgrade.”]
- Write the tests that let the next person change your code without fear
- [If regulated: work inside [PCI DSS / SOX / HIPAA] controls, including change management and audit evidence]
What You’ll Bring
- [X]+ years building production Java, [including work on Java 17 or later / including at least one major-version upgrade]. [Name versions or features, such as records, sealed classes, or virtual threads, instead of leaning on years alone.]
- Spring Boot [3 or 4] in production, with Spring Data JPA or a comparable persistence layer
- SQL you’d be comfortable defending in a code review
- Experience with [Kafka / REST and gRPC APIs / batch processing in Spring Batch], matched to what this service actually does
- A production incident you personally worked, and what you changed afterward. [Ask for this in the posting. The strong candidates arrive ready to tell it.]
- [Cloud and container experience on AWS, Azure, or GCP with Docker and Kubernetes, if the role deploys its own services]
Nice to Have
- Kotlin [only if it’s already in the codebase or on this year’s roadmap]
- [Your industry, if it matters. Insurance rating rules and payments reconciliation are both easier to hire than to teach.]
- GraalVM native images [if startup time or memory footprint genuinely matters to you]
- Oracle Certified Professional, Java SE 21 Developer (exam 1Z0-830) or Java SE 25 Developer (exam 1Z0-831) [Nice to see. Never required.]
Pay, Location, and the Pager
[$135,000 to $175,000] base salary, with [bonus target], [equity], and [benefits]. [Remote / hybrid in [city] / on site.] [On-call: how often the rotation comes around, and how often it actually pages.] [Include the range. It’s legally required in several states and expected in the rest.]
What Java Hiring Managers Keep Asking Me
Should the title say Java developer or software engineer?
Whichever your leveling system already uses, as long as the word Java survives into the title. Experienced Java engineers filter on the language before they read a line of the body.
“Senior Java Developer” and “Software Engineer, Java” both work fine. What loses people is a bare “Software Engineer II” with Java mentioned in the eighth bullet, because that posting now competes with every Python, Go, and TypeScript search on the same board. It happens constantly.
Is “5+ years of Java” still a useful requirement?
Not on its own. Ten years spent entirely on Java 8 and four years spanning Java 17 through 25 produce very different engineers, and a years number can’t tell them apart.
What I push clients toward is naming versions and features instead, records and sealed classes and virtual threads, with a years figure kept as a loose floor if HR needs one for leveling. The requirement that filters best is a production incident the candidate personally worked. That one is hard to bluff past a good interviewer for more than a few minutes. I’ve watched people try.
Kotlin keeps turning up on resumes. Does it belong in our posting?
Only if a Kotlin pull request would get merged on your team today. Listing it as an aspiration pulls in engineers who mainly want to write Kotlin, and they notice fast when the codebase is all Java.
Kotlin shows up for 10.8% of respondents in that same Stack Overflow survey, and it runs on the JVM, so a solid Java engineer usually picks it up in a few weeks. That’s the useful part. I wouldn’t recruit for it. If your Android team or one backend squad already writes it, say which one, and leave it off every other Java posting you run. When Kotlin really is the job, run it as a Kotlin developer search instead.
Are Oracle’s Java certifications worth listing?
Two current exams are worth recognizing, 1Z0-830 for Java SE 21 and 1Z0-831 for Java SE 25, and neither belongs under “required.”
Both sit on Oracle University’s exam pages and prove somebody studied the language carefully. Most of the best Java engineers I’ve placed never sat for either one.
How is this different from a backend developer job description?
It commits to a runtime. A backend posting can stay neutral across Java, Go, Node.js, and Python, while a Java posting has to answer the version and framework questions this whole page is about.
If you genuinely don’t care what language the service is written in, use our backend developer job description template instead, and you’ll see a wider pool. Strong Java people apply to those postings too, I should add, especially the ones who are curious about Go. Few teams are truly indifferent to the language, though. Most that call themselves language-agnostic turn out to have a Maven build and eleven years of Spring configuration they have no intention of rewriting, and the posting might as well admit that on day one rather than in the technical screen, where it lands as a small betrayal.
We need a Java 25 upgrade finished by spring. Contract it or hire for it?
$90 to $160 an hour, loaded, is the usual U.S. range for senior contract Java work, and for an upgrade with a real end date that’s often cheaper than adding a permanent seat.
Roughly one Java search in four that we run begins as contract-to-hire, and this is usually why. A contract Java developer can run the upgrade without anyone pretending it’s a permanent job. Where it goes wrong is the Costa Mesa pattern from earlier, a direct hire brought on for feature work who gets handed the upgrade in week two. If the upgrade really is the first chapter of a longer modernization, a permanent hire makes sense. Just tell them.
What I’d Change Before Lunch
The codebase section of the template. That’s where I’d put the first hour. The version, the framework, the upgrade status, who carries the pager. Candidates can’t learn any of that from your careers page. They’ll ask anyway. It’s also exactly where the Irvine insurer’s first posting went wrong and its second one went right.
A good part of my month goes to OCTP, the technology executive community I founded here in Southern California, and when hiring comes up the complaint I hear most isn’t about salary. It’s the engineer who left in month four because the job wasn’t the one on the posting. Nearly every version of that story starts with a req somebody copied rather than wrote.
That’s also most of why our numbers look the way they do. KORE1’s IT searches average about 17 days to hire, and a year after we place someone, 92 out of every 100 are still in the job. Neither figure comes from anything clever. It comes from describing the job correctly before anybody picks up a phone. If you’ve got a Java req drafted, send it to our Java team and we’ll mark it up the way we would for our own search. If you’d rather run with it yourself, our Java developer interview questions guide covers what to ask once the right people start showing up. Either way, write the version down.
