Creating the Java Universe

For some time, I had this tension in me. On one hand, I have been a long-time Java developer. On the other hand, I found great joy in creating data visualizations. The tension came from not knowing how to bridge the gap and connect two areas that, at first glance, had nothing to do with each other.

Then a good friend, Bruno asked me why I did not visualize the evolution and impact of Java, using the official OpenJDK JDK and JEP pages as sources. It seemed like a good way to improve my skills while working on a project that could also be useful to the Java community.

The main goal became to visualize JDKs, JEPs, and the connections and relationships between them. I wanted to explain to a broader Java developer audience what they are, why they are important in the Java ecosystem, and why developers should understand them.

The second goal was to make Java’s evolution visible in a way that is attention-grabbing, not dry, and unconventional.

I wanted to imagine it through a metaphor for JDKs and JEPs that would be easy to understand and remember. I used my imagination first, without thinking yet about how I would build it technically later.

I also wanted to introduce the parts of the visualization step by step, so people would not feel overwhelmed when reaching the more complex parts. Thus, it was also a chance to try scrollytelling and use a story to guide the visitor.

Foundational Work

Goal & Audience:

The main goal became to visualize Java’s impact in an engaging way that needs little explanation and gives users the chance to explore the evolution of releases or individual features interactively.

I also wanted to show the relationships between JDKs and JEPs, and how they connect to JSRs and the JCP, the Java Community Process. The goal was to help the audience understand how Java’s evolution is driven.

The target medium is a publicly available static website hosted as a subdomain of my main website.

The main audience is Java developers who want to learn more about Java’s new features and understand the process behind them. It can also serve as an illustrative resource and visual aid in Java-related talks for the community.

The story needs to be clear and easy to navigate, while giving users enough room to explore the visuals themselves. Explanations should be clear and short, moving from the basics to the more complex parts so users do not feel overwhelmed. Using scrollytelling was also a personal goal.

Data Source:

OpenJDK provides official public pages with information on each JDK release and each JEP introduced so far. The JDK pages contain core metadata and lists of JEPs. The JEP pages contain metadata, relationships to other JEPs, summaries, and more detailed descriptions.

These pages are under:

I found these pages to be well maintained, so they could serve as a solid source for my visualization. Since the goal at this stage was not to automate or crawl the sites, I manually transformed the information into two CSV files: one containing the JDK list and the other containing the JEP list. This requires some regular maintenance, but it should not be much work.

For the project illustration, I found that the available project sites were not reliably maintained, not uniform, and in some cases did not contain useful details. They could not serve as a source for me at this point. For example: Which JEP belongs to which project? For this, I used the mailing lists found on the individual JEP pages.

Constraints:

Apart from the chosen data sources, there were no other constraints. I had no client telling me what to achieve, which technology to use, or by when it had to be finished. I had complete freedom to use my imagination and choose a metaphor that is easy to remember.

I also had the freedom to decide when to work on it and to move at my own pace.

At the beginning, I did not even think much about technical details. The only constraint I set for myself was to use D3.js. I knew that with this library and Vanilla JS, I would have the freedom to build any custom design I could imagine.

Data Analysis

I found the JDK source pages to be regularly updated, with a consistent structure and no missing data. However, the release date may not be known far in advance. In the case of JDK 27, the list of JEPs has only one item, even after the release of 26. This may simply be what is communicated publicly, while work continues behind the scenes and is not yet ready to be announced.

For future crawling, the last update value can show whether anything has changed on the page. This page also includes the JSR number of the platform JSR associated with that JDK release.

The JEP pages contain much more information and are also well maintained. I realized, also through technical discussions, that the Status field value - such as draft - is an important field to use and has future potential in the visualization.

The Release field shows which JDK a JEP belongs to. In some cases, a JEP does not have a JDK yet, depending on its state. It was important to recognize this.

The Discussion field seemed to be the only reliable source for extracting project ownership information. I do not know of any more complete public source for project ownership. So it is a bit unusual, but worth noting. For crawling, it is also important to note that there may be spelling errors in mailing list values. In theory, a JEP can belong to more than one project.

The Relates to field is another key field, as it makes it possible to group related JEPs together. It is important for navigating connected topics. Later, it may be useful to distinguish between different kinds of relationships.

I discovered that a feature can span multiple JDKs. In each JDK it has a different JEP number, and these JEPs are then related to each other.

I found that the Created field is a useful indicator for placing a JEP on the timeline in the projects view when the JEP has no corresponding JDK. This is based on the assumption that the JEP became associated with the project at creation. It is still only an assumption.

For now, I do not use the summary or other text fields, but they may become relevant later if I implement search.

In summary, I rely only on fields that have proven reliable enough.

No other data sources have been used, so everything is based on official information from OpenJDK pages.

Sketching & Design

Using an easy-to-understand metaphor was key to creating something people could remember easily. And are JDKs and JEPs not like little stars, filling the sky more and more as new releases appear? Is Java not trying to reach the sky?

Before choosing the final design, I also looked for inspiration in Nadieh Bremer’s book Chart. Why there? Because the book shows how to give ordinary charts a unique touch and, more importantly, how to design creative visualizations. I was inspired by a sky example that she used in a different context.

I had a clear idea on the forms. For me, JDKs are big stars, filled or empty depending on whether they are LTS releases or not. JEPs take a rhombus shape, as there are many more of them. Filled JEPs are completed, while empty ones are in a non-final state such as draft, or are experimental, incubating, or preview.

With this approach, I wanted to give JDKs a stronger form and make them easy to locate, while surrounding them with “their” JEPs. Both shapes have a minimum size so their numbers can still be read on a normal screen. This is already close to the limit, as the sky is now quite full, so I may redesign it in the future.

Lines between JDKs and JEPs indicate direct relationships.

To create a stronger connection to Oracle / OpenJDK, I chose the Hex equivalents of the official Pantone colors used in the Java coffee cup logo:

• Java Blue is Pantone C PMS 633 C, Pantone U PMS 314 U, Process C100 M5 Y10 K36, RGB R0 G115 B150, or Hex 007396.
• Java Orange is Pantone C PMS 144 C, Pantone U PMS 130 U, Process C0 M52 Y100 K0, RGB R237 G139 B0, or Hex ED8B00.

Source for the color information: Java Logo Guidelines

Even with this information, I spent quite a lot of iterations finding the right color mapping for the main elements, JDK and JEP, so that together with the sky color and accompanying text, the whole design would look harmonious.

Creating the Data Visualization

In this phase, I started with the sky elements and worked through different views that gradually reveal more information about them and their relationships.

For this - and to satisfy my own curiosity - I used the concept of scrollytelling, which reveals each element step by step.

For the technical implementation, I chose Scrollama for the scrollytelling part, and D3.js with vanilla JavaScript for the main visualizations. No frontend framework was used in the first release, but this may change in the future if more interactions need to be handled.

It was an iterative process, refining the designs until they more or less converged with my original idea.

Besides the more obvious basic elements, I used a beeswarm chart to show that JEPs belong to JDKs, surrounding their release.

A more complete view is created with a circle pack chart, which expresses this part-whole relationship more clearly.

For the sky, I chose a network chart for simplicity, as it works well for visualizing relationships. Finding the right simulation parameters also required a lot of experimentation. This sky view gives you the freedom to explore relationships by clicking on any element, including zooming and moving the selection.

Where it made sense, I used tooltips to reveal more information about the selected elements.

The whole visualization is best viewed on a larger desktop or laptop screen. For mobile use, I optimized some styles, but changing orientation requires a refresh to work correctly. A fully mobile-compatible design was not my first priority, as it is difficult to bring this level of complexity to a small screen and would have required different designs for different devices. So I focused on standard-size screens.

The first release I have now, after around three months of after-work dedication, already answers many questions Java developers may have. Some questions are still unanswered and will be addressed in future releases.

Delivering the Final Result

I was fortunate to have the chance to discuss the project with a few Java Champions while the main work was still in progress. After many iterations and refinements, the first official version of the visualization was ready to be published.

The official presentation took place on 24 February 2026 in an episode of the Out of the Box Developer podcast series, where I described the project, demonstrated the visualization, and answered questions from Java developers.

You can watch the recording on my channel: YT Video - The Java Universe

One month later, on 20 March 2026, right after the biggest event of the year, JavaOne, I was invited to present it at the JCP EC (Java Community Process Executive Committee) face-to-face meeting at Oracle. In this distinguished circle, I even received questions from some of the most influential figures in the Java world, which was a great honor for me.

This last meeting, together with my own ideas, resulted in a longer list of possible enhancements that could make the visualization even more useful for different groups of Java developers. One thing remains a priority for me, though: I want to keep the artistic touch of the visualization and preserve its uniqueness.

You can find the latest version running at The Java Universe Site.

You are welcome to show parts of this visualization in your own Java-related presentations. Please give proper credit when using it. This project is not open sourced at this stage.