Definition
- Project Skara – The OpenJDK project that modernized how the JDK source code is stored and how contributions are reviewed.
- Migration – Moved the JDK codebase from Mercurial to Git and the repositories to GitHub.
- Skara bots – Automation that enforces the Oracle Contributor Agreement, links JDK Bug System issues, verifies reviewer counts and qualifications, and performs the actual merge into mainline.
/integratecommand – A PR comment that triggers the bot to merge the change into mainline with properly formatted commit messages.- Sponsor flow – Allows a committer to sponsor a non-committer's change through the governance process.
Imagine National Bank of India used to accept new policy proposals only by posting handwritten letters to a central office using an old postal system that few people understood, where every letter had to be formatted in a very particular way or it was rejected. Project Skara is like the bank switching to a modern, well-known submission portal that almost every professional already knows how to use, with helpful assistants that automatically check your submission meets the rules, attach the right case numbers, and route it to the correct reviewers. Nothing about the bank's strict approval standards changed, but far more people can now contribute.
Understanding the Concepts
What was the OpenJDK workflow before Skara?
Before Skara, OpenJDK development used Mercurial, a distributed version control system far less widely used than Git. Code review relied on mailing lists and webrev, a tool that generated static HTML diffs posted for reviewers to comment on by email. This workflow was unfamiliar, had a steep learning curve, and the mechanics of submitting, reviewing, and integrating a change were manual and idiosyncratic.
# Before Skara
1. Clone Mercurial repo (hg clone)
2. Make changes
3. Generate webrev (static HTML diff)
4. Post webrev link to mailing list
5. Reviewers reply by email
6. Manually verify contributor agreement
7. Manually count and verify reviewers
8. Committer pushes to mainline
# High barrier, unfamiliar tools, slow cycle
What did Project Skara change?
Skara changed three things. First, it migrated the source from Mercurial to Git. Second, it moved the repositories to GitHub. Third, it built the automation that reconciles the open GitHub workflow with OpenJDK's strict governance.
# After Skara
1. Fork on GitHub (git clone)
2. Branch, commit, push
3. Open pull request
4. Bot checks contributor agreement automatically
5. Bot links JDK Bug System issue
6. Bot verifies reviewer count and qualifications
7. Author comments: /integrate
8. Bot performs formatted merge into mainline
# Low barrier, familiar tools, fast cycle
How do the Skara bots work?
When you open a pull request against an OpenJDK repository, a set of bots handles the governance checks automatically.
Pull Request Opened
│
▼
┌──────────────────────────────┐
│ OCA Bot │
│ Checks contributor agreement │
│ is signed │
└──────────────┬───────────────┘
│
▼
┌──────────────────────────────┐
│ Issue Bot │
│ Verifies JDK Bug System │
│ issue is linked and valid │
└──────────────┬───────────────┘
│
▼
┌──────────────────────────────┐
│ Reviewer Bot │
│ Confirms required number of │
│ qualified reviewers approved │
└──────────────┬───────────────┘
│
▼
┌──────────────────────────────┐
│ Format Bot │
│ Checks commit message and │
│ whitespace rules │
└──────────────┬───────────────┘
│
▼
Author comments: /integrate
│
▼
┌──────────────────────────────┐
│ Integration Bot │
│ Performs formatted merge │
│ into mainline │
└──────────────────────────────┘
What is the /integrate command?
When all checks pass, the author comments /integrate on the pull request, and the bot performs the actual merge into the mainline, creating a properly formatted commit that preserves OpenJDK's history conventions.
# PR comment by author:
/integrate
# Bot response:
Going to push as commit abc1234...
Pushed as commit abc1234 to https://github.com/openjdk/jdk/commit/abc1234
What is the sponsor flow?
A non-committer cannot directly integrate, so a committer sponsors the change. The sponsor reviews and then comments /sponsor to trigger the integration.
# Non-committer opens PR, all checks pass
# Non-committer comments: /integrate
# Bot responds: requires a sponsor
# Committer reviews and comments: /sponsor
# Bot performs the merge
How did Skara affect contribution workflow? (Comparison)
| Aspect | Before Skara | After Skara |
|---|---|---|
| Version control | Mercurial | Git |
| Hosting | Internal servers | GitHub |
| Code review | Mailing list + webrev | Pull request + inline comments |
| Agreement check | Manual | Bot-automated |
| Issue linking | Manual | Bot-automated |
| Reviewer verification | Manual | Bot-automated |
| Integration | Committer pushes | Bot merges on /integrate |
| Learning curve | High (unfamiliar tools) | Low (familiar Git/GitHub) |
| Review speed | Slow (email threads) | Fast (PR workflow + bots) |
What CLI tools did Skara provide?
Skara produced CLI tools like git-jcheck for running governance checks locally before pushing, and replacements for the old webrev tool. Contributors can verify their changes meet all rules before opening a pull request.
# Run jcheck locally before pushing
git jcheck
# Verify commit message format
git jcheck --rev HEAD
Why does Skara matter for contributors?
The barrier to entry dropped because developers who already know Git and GitHub can contribute using skills they already have. The pull-request workflow gives inline, threaded review comments and clear status of checks. Review cycles got faster because bots automate clerical gatekeeping so human reviewers focus on actual code.
What should a senior engineer know?
Skara is not a language or runtime feature, so it does not change how Java code behaves. It is infrastructure and process modernization. But it matters strategically because the long-term health of Java depends on attracting and retaining contributors, and a modern, familiar, automated workflow is a major part of that. When an interviewer asks about Skara, they are testing whether you understand the OpenJDK ecosystem and governance, not just the language.
Visual Overview
┌───────────────────────────────────────────────────┐ │ Project Skara: Before vs After │ ├───────────────────────────────────────────────────┤ │ │ │ BEFORE: │ │ Developer ──Mercurial──→ webrev ──email──→ Review│ │ │ │ │ │ └── Manual agreement + issue check ───┘ │ │ └── Manual integration push │ │ │ │ AFTER: │ │ Developer ──Git──→ GitHub PR ──→ Bots check: │ │ │ ├─ OCA signed? │ │ │ ├─ Issue linked? │ │ │ ├─ Reviewers OK? │ │ │ └─ Format OK? │ │ │ │ │ └── /integrate ──→ Bot merges to mainline │ │ │ │ Result: Lower barrier, faster reviews, same rigor│ └───────────────────────────────────────────────────┘
Key Takeaway
Project Skara is the OpenJDK project that modernized how the JDK source code is stored and how contributions are reviewed. It migrated the codebase from Mercurial to Git, moved the repositories to GitHub, and built the automation that makes a pull-request workflow work under OpenJDK's governance. Before Skara, development used Mercurial with code review over mailing lists and webrev, which was unfamiliar and had a steep learning curve.
The heart of Skara is the set of bots that reconcile an open pull-request workflow with OpenJDK's strict rules. When you open a pull request, a bot checks the contributor agreement, verifies and links a valid issue in the JDK Bug System, and enforces the reviewer rules. When everything passes, the author comments /integrate and the bot performs the formatted merge into the mainline.
Why it matters is the key point. The barrier to entry dropped because the workflow is now the familiar pull request almost every professional already knows. Review cycles got faster because bots automate clerical gatekeeping so human reviewers focus on actual code.
Skara is infrastructure and process, not a language or runtime feature, so it changes nothing about how Java code behaves. But it matters strategically because the long-term health of Java depends on attracting and retaining contributors, and a modern, automated, familiar workflow is a major part of that. In banking work at National Bank of India the same idea was applied to internal shared-libraries, replacing an intimidating manual submission process with a pull-request flow plus automated gates, and both contributions and review speed improved.
Remember one sentence: Project Skara moved OpenJDK from Mercurial to Git on GitHub with automated bots that enforce governance, lowering the barrier to contribute and speeding up reviews while keeping the same strict standards.
---