Developer Guidelines for Using Java
Most Java compliance problems start with a simple mistake: downloading the wrong Java Development Kit (JDK). Picture this: you need Java for a project and grab Oracle’s JDK from the official site without a second thought.
It seems harmless, but that one download can create company-wide licensing headaches.
Follow these guidelines to keep your team safe — and your company off Oracle’s radar.
Pro Tip: “Compliance starts at the keyboard, not in the boardroom.”
Remember: the goal is to make compliance part of your daily development habits—not a legal panic later.
Read our ultimate guide to Oracle Java Compliance Management Best Practices.
Why Developers Need Java Licensing Rules
Oracle’s Java licensing model has changed again, and it’s more confusing than ever.
It wasn’t always this way – Java used to be freely available under Sun Microsystems. Many developers still assume “Java is free.” But Oracle’s newer licenses flipped that script.
Now, a single unapproved Oracle JDK on one machine can trigger an enterprise-wide license requirement.
Oracle’s pricing can run into hundreds of dollars per employee, per year – a huge cost for what started as a quick download.
It’s no wonder that teams today enforce an “OpenJDK-first” policy across all builds and environments.
This ensures developers use open-source or internally approved JDK builds by default, and avoid Oracle’s version unless it’s officially authorized by compliance.
The good news is that staying compliant is straightforward if you stick to a few rules. Use only approved JDK distributions and follow your internal guidelines.
Most importantly, never install software you can’t justify. Make compliance a habit now, so you won’t have to worry about Oracle audits later.
Read how to track employee licenses, Tracking Oracle Java Employee Counts.
The Golden Rule – OpenJDK First
For developers, the golden rule of Java compliance is simple: OpenJDK first.
Always use OpenJDK or your organization’s approved Java distribution for both development and production work.
It might be tempting to grab Oracle’s JDK out of habit or convenience, but it’s not worth the risk when free, safe alternatives are available.
Only use Oracle’s JDK if your licensing or compliance team has explicitly approved it.
In practice, nearly all applications run perfectly fine on OpenJDK. Vendor-supported builds (like Amazon Corretto, Azul Zulu, or Red Hat’s OpenJDK) offer the same functionality as Oracle’s JDK.
In modern Java releases, Oracle’s JDK and OpenJDK share the same codebase — only the licenses differ. You’re not missing out on anything by choosing the open-source option.
Pro Tip: “If you don’t know who pays for it — don’t install it.”
Approved Java Builds (Examples)
Your organization might standardize on one or more of these Java builds:
- Eclipse Temurin (OpenJDK) – Community-supported build (formerly AdoptOpenJDK).
- Amazon Corretto – AWS’s OpenJDK distribution with long-term support.
- Azul Zulu or Red Hat OpenJDK – Enterprise-supported OpenJDK builds.
- Oracle JDK – Oracle’s official JDK (restricted; use only with explicit authorization).
All of the above options provide the same core Java functionality.
Most companies maintain an approved JDK list — for example, “Java 17 (Eclipse Temurin)” or “Java 11 (Amazon Corretto)”.
As a developer, stick to your organization’s approved list and avoid downloading Java from unvetted sources.
Different vendors may offer various support plans or update schedules, but the Java platform itself remains consistent.
Pick a distribution that fits your needs, but always choose one that keeps you clear of licensing traps.
The functionality is identical — only the license terms vary. All these distributions receive timely updates, so you won’t fall behind on security patches by sticking with them.
What Developers Should Never Do
On the flip side, here are the top things a developer should never do in a Java environment:
- Don’t download Oracle JDK directly from Oracle.com (no unapproved downloads).
- Don’t use Oracle JDK for development, testing, or builds unless you have written approval.
- Don’t embed Oracle’s Java runtime in any software you distribute to clients.
- Don’t assume that “free for testing” means “free for business” when it comes to Oracle.
Every one of the above “don’ts” is based on real-world mistakes that have cost companies dearly.
Oracle might offer certain software “free” in theory, but there’s always fine print.
A casual download or assumption can trigger a compliance audit or an unexpected invoice.
In one case, a company was hit with a six-figure bill because a developer unknowingly included Oracle’s JDK in a production system.
Steer clear of these pitfalls to keep your development environment worry-free.
If you’re ever unsure about using a certain Java component or download, pause and ask your compliance team. It’s much easier to get a quick yes-or-no than to undo a license violation later.
Pro Tip: “The word ‘free’ in Oracle’s world usually means ‘for now.’”
Table – Java Compliance: Do’s and Don’ts
Here’s a quick reference of what to do and what not to do:
| Do | Don’t |
|---|---|
| Use OpenJDK by default | Download Oracle JDK without approval |
| Check your environment’s default JDK | Assume developer use is exempt |
| Ask if unsure before installation | Embed Oracle Java in builds |
| Follow the approved version list | Mix Oracle and OpenJDK builds |
| Document which JDK your app uses | Forget to remove unused versions |
Checklist – Developer Self-Audit
Here’s a self-audit checklist for developers. Make it a habit to run through this list regularly, so you catch issues early — before Oracle does.
This covers everything from your IDE settings to your Docker images, ensuring compliance is woven into daily work.
- ✅ Check which JDK your IDE or build pipeline uses.
- ✅ Verify the JDK comes from an approved vendor.
- ✅ Remove any Oracle Java installs from local machines.
- ✅ Log requests for exceptions through the internal license management team.
- ✅ Tag Docker and VM images with the correct JDK vendor and version.
Some organizations also run automated scans for Oracle software – better to find and remove any Oracle JDK yourself before those scans ever flag it.
When Oracle Java Might Still Be Allowed
Sometimes, using Oracle’s Java is unavoidable. A few scenarios where Oracle JDK might still be necessary include:
- A third-party vendor or product specifically requires Oracle’s Java binaries.
- A client’s environment or contract mandates using Oracle-supported Java.
- Certain tooling or monitoring components depend on an Oracle-only feature.
In such cases, always obtain explicit, written approval beforehand and document who is responsible for the Oracle Java subscription costs.
For 99% of projects, you won’t need Oracle at all. Reserve it only for truly unavoidable situations, and only with full oversight.
Bottom line: treat Oracle JDK use as an exception that requires paperwork, not a personal choice.
If you do get an exception, isolate that Oracle JDK instance and periodically re-evaluate whether it’s still necessary (or if an OpenJDK alternative can replace it).
Educating Teams and Embedding the Policy
Make sure everyone on the team knows the rules.
Include these Java licensing guidelines in developer onboarding materials, team communications, and wikis.
Embed compliance checks into everyday workflows.
For example, add a step in code reviews or CI/CD pipelines to confirm the JDK in use is on the approved list.
Standardize your build and deployment pipelines to use approved JDK base images or containers.
This way, the default option in every environment is always compliant.
Likewise, consider technical controls: it should be difficult (or impossible) to accidentally download or install Oracle Java in your environment.
For instance, some companies remove Oracle JDK from internal package repositories or require special approval to access Oracle’s download site.
These small barriers make compliance the path of least resistance.
Your Software Asset Management (SAM) or compliance group should be involved in promoting these rules and reviewing any exception requests.
Also, keep your policy documentation up to date — Oracle’s rules can evolve, so refresh your guidelines and training as things change.
Pro Tip: “Developers follow defaults — make your defaults compliant.”
Final Take
Staying on the right side of Java licensing isn’t about appeasing lawyers – it’s part of being a responsible engineer.
A few simple precautions now (like using OpenJDK by default) can save you from huge headaches and costs down the road.
By adopting an OpenJDK-first mindset, you protect both your project and your organization from surprise fees.
That means you get to focus on building software, not on scrambling to address licensing issues at the last minute.
In the end, following these guidelines keeps Java fun and productive — instead of a compliance headache.
Pro Tip: “Every compliant build starts with one simple rule — use OpenJDK first.”
Read about our Java License Compliance Services.
