The latest expert opinions, articles, and guides for the Java professional.
What you can do about it all
If you think about what makes a programming language really grow, it’s how it’s adopted in the community of programmers. Indeed, Java’s community is strong and there are so many programs that you can get involved in, it ended up in RebelLabs making this very report about it.
All the things that make an active Java Community great
Besides having strong community driven development practices and a constant support from giant corporations starting with Oracle itself, the Java ecosystem employs multiple other directions to shine among other software projects.
Starting with the OpenJDK program, looking at how the powerful Java User Groups (JUG) community created a real community in addition to the Adopt a JSR program, what it takes to become a Java Champions and why EVERY Java developer out there should try to get to JavaOne in San Francisco (at least once)…
Back to OpenJDK again
Remember earlier when we were talking about OpenJDK? Well, OpenJDK is actually more important than it appears. It’s an open-source JVM implementation upon whose very standards Oracle bases their own HotSpot JVM implementation from. And if you remember, Oracle runs the Project Management Office (PMO) for the JCP, which more or less looks after JSRs, RIs and TCKs. So, in fact, OpenJDK is where it’s all happening in real life.
Every well defined and mature software project has a roadmap or a plan that contains some long-term and short-term goals. A roadmap is usually constructed from different proposals gathered from different users and product team members. So where does OpenJDK get it’s input for the roadmap? The solution is with a JDK Enhancement Proposal (JEP) & Roadmap Process (or just JEP 1 — JEP 0 is the index of all JDK Enhancement Proposals, known as JEPs).
A JEP is usually something bigger and nontrivial, something that takes more time and resources to implement:
- It requires two or more weeks of engineering effort;
- It makes a significant change to the JDK, or to the processes and infrastructure by which it is developed;
- It is in high demand by developers or customers.
The process is open to every committer and all proposals are made in a transparent manner but the final decision is always made ultimately by the OpenJDK Lead.
A JEP is not related to the JCP, nor influence it. As JEP 1 itself states:
“This process does not in any way supplant the Java Community Process. The JCP remains the governing body for all standard Java SE APIs and related interfaces. If a proposal accepted into this process intends to revise existing standard interfaces, or to define new ones, then a parallel effort to design, review, and approve those changes must be undertaken in the JCP, either as part of a Maintenance Review of an existing JSR or in the context of a new JSR.”
MAKING DECISIONS IN OPENJDK
The ultimate decision maker here is the OpenJDK Lead, but of course the OpenJDK Lead is not the only person who counts because it is hard to keep an eye on all the aspects of everything. The OpenJDK Lead also relies upon the demonstrated expertise of Reviewers, Group Leads, and Area Leads when evaluating incoming proposals.
A successful JEP passes through the following stages:
JEP documents are written in the good, old plain text format, using the Markdown lightweight markup language. The list of all existing JEPs is currently under JEP 0 on the OpenJDK website: http://openjdk.java.net/jeps/0.
OPENJDK IS OPEN 4 SUBMISSIONS
As with most open source projects out there, OpenJDK is open to contributions as well. As OpenJDK is mainly written in C and Java, then you should be very familiar with either of these technologies in order to help out. Also, some knowledge of Mercurial will be helpful as all of the source code is kept in Mercurial repositories. Take that Git! ;)
For each module in the JDK, there is a group. To get a clue about what’s going on, who are the main figures, who you should talk to and where to get information, it’s useful. Necessary even: it is the key to any communication with other contributors and developers so you should subscribe yourself to the mailing list of a corresponding group and start following and reading messages being sent in the group.
For viewing purposes the source code of the JDK is naturally distributed with the JDK builds, but the safest way to have a modifiable up-to-date copy of the code is to clone the repository to your computer. The source can be cloned directly from the Mercurial repository here: http://hg.openjdk.java.net/.
Thankfully, the OpenJDK team has provided access to everyone for accessing the repository and the source code, so it’s quite easy to start learning and trying things out. The structure of the repository and the development model is well described here: http://openjdk.java.net/guide/repositories.html.
Like any other software project, there are some code conventions to follow and some things to learn about change planning (http://openjdk.java.net/guide/changePlanning.html). Every change needs discussion (and of course code review and testing on multiple platforms), no matter how big or small it is. The best place to discuss the intended change is the appropriate development mailing list.
OKAY-OKAY, WHERE SHOULD I START?
Here are steps provided by Oracle, how to contribute to OpenJDK:
The OpenJDK team tries to accept only highest-quality and highest-priority patches, so do not feel bad if some of your change will not get accepted or recognized. As the process is a bit heavyweight and involves a lot of different parties, levels and concerns, then it is a good idea to think carefully and understand the scope of the change and any side effects it may add to the JDK. Want to bounce some of your suggestions off other JVM engineers? Why not join a JUG (there is even a virtual one!)
Leave a comment