Blog

The latest expert opinions, articles, and guides for the Java professional.

A Short History of Nearly Everything Java

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:
short history of nearly everything java making decisions in openjdk JEP 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:
openjdk steps short history of nearly everything java

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!)


DOWNLOAD THE PDF

Responses (5)

  1. Avatar  

    Dmitry Leskov

    September 24, 2014 @ 8:47 am

    There is at least one more certified JVM that you did not mention: Excelsior JET (www.excelsiorjet.com). Developed in Novosibirsk, Russia, it has been on the market since 2000, and was certified Java Compatible in 2005. The main distinctive feature of Excelsior JET is its Ahead-Of-Time (AOT) compiler, which takes your jar files as input and produces an optimized native executable for Windows, OS X, or Linux. AOT compilation benefits are dual: it hinders reverse engineering of your app, and at the same time improves the end-user experience through faster startup, smaller footprint and JRE-independency.

    Disclaimer: Yes, I work for Excelsior.

  2. Avatar  

    Chris Snyder

    September 24, 2014 @ 3:56 pm

    I used JET for a consumer software product at my old company. It allowed us to distribute our software without worrying about whether the customer had a JRE installed. It worked great, and Excelsior support was excellent (even though we were a tiny company not paying for a big support contract).

    I don’t have a use for JET now (everything is web-based for me at the moment), but I’m glad to hear that you’re still going strong. Keep up the good work!

  3. Avatar  

    Oleg Šelajev

    September 24, 2014 @ 4:59 pm

    Great point, Dmitry. For brevity, we didn’t describe all the existing JVM implementations, not even all the certified ones. Just the most major ones.

    So, big thanks for contributing the info!

  4. Avatar  

    Debbie Fuller

    September 25, 2014 @ 7:52 am

    Nice blog Oleg, but there is another certified JVM that was missed off from Waratek (www.waratek.com). With a team of experienced dedicated JVM developers it is Oracle certified Java compatible and was initially developed to provide multitenancy with elastic memory and application isolation. (http://www.waratek.com/blog/december-2013/capacity-planning-memory-for-real-world-jvm-applic)

    The containment and isolation that the in built hypervisor provided has since been expanded to provide ‘Runtime Application Self Protection’ for Java apps. This is the first time that RASP has been provided within the JVM. Because the JIT compiler can intelligently interpret messages, it avoids ‘false positives’ and ‘gracefully blocks’ attacks. This protects applications from SQLi, Zero Day attacks as well as providing virtual patching for Legacy Java. (http://www.waratek.com/security/how-it-works)

    We’re going to be at JavaOne and hope to meet up with you there!

    Disclaimer: Yes, I do work for Waratek!

  5. Avatar  

    Dmitry Leskov

    September 25, 2014 @ 1:18 pm

    Thank you for your kind words, Chris.

RSS feed for comments on this post.

Leave a comment