Q&A with Heather VanCura, Chair of the Java Community Process

I last sat down with Heather VanCura, chair of the Java Community Process (JCP), in 2017, roughly a year after she'd stepped up to head the Java language and platform standards organization. A lot has happened in the Java community since then. (I mean, a lot.) Now that some of the dust kicked up by all that change has settled, it seemed like a good time for another conversation.

You're about two years into the job now. During that time, the Java community has seen a remarkable amount of change. I'd argue more than at almost any other time in its 20-plus year history -- Java EE moving to the Eclipse Foundation, Oracle's amped up release cadence, etc. How has the JCP managed to keep pace without losing its footing?
To be clear, the organization has been evolving throughout its history, even if that evolution was often pretty slow in the early days. But there's no doubt that things have sped up in recent years. I think the key for us has been constant communication with the community.

When you say "communication," what do you mean?
I mean presenting and interacting at conferences, trade shows, and events, as well as showing up, on-the-ground, to support Java communities around the world.

It's kind of an understatement to say that you travel more than your predecessor.
I like to say I've been to every continent on behalf of the Java community except for Antarctica. Actually, I said that in a tweet and then was actually invited to submit for a kind of tech-conference cruise event that does go there. It's a 10- or 12-day thing, which sounds kind of exhausting, but if it was a Java community event, I'd definitely do it.

Why is this kind of hands-on interaction with the community so important?
We're getting back to our roots, back to solving real-world problems for real-world developers. But there are many different kinds of developers using Java all over the world today. It used to be that most of our base came from the U.S. and western Europe, but we really see it diversifying, and people have different problems in Nigeria, Morocco, and Ivory Coast than they do in Belgium and the Netherlands. It's important to nurture these communities, and often the best way to do that is to show up at their events when it's possible to do so.

You're talking about Java User Groups (JUGs)?
Right.

What do you do at these events?
I talk about changes that are happening, of course, but also about how they can participate in this community and why they should.

I understand that, in addition to showing up for events in person, you interact with these communities virtually.
Yes, I do a lot of virtual JUG visits. I've found that it's sometimes useful to do virtual events in advance to give the groups ideas of how to engage with their own communities. I encourage them discuss things among themselves. What are your particular interests? What technologies are most important to you? What kinds of activities would you like to participate in? And then maybe, if they plan something like a hack day, I come in person for that. For example, I finally made it to Israel for the first time last year, but they had participated in a virtual hack day a couple of years ago. It sort of sets up things up for a productive visit.

And this is what you mean by "constant" communication?
We try to interact with the Java community wherever and whenever we can, and as much as we can. If I'm at a conference, I always try to engage with the local Java user group, to see if they want me to come and speak -- which they usually do. These communities are already invested in the platform; I want them to also feel connected to the process, to feel like their needs are being addressed by it, and that they can be valuable participants in it.

The message is, the process is community driven?
That's right. We want them to understand that their input is actually very important. But sometimes they need help understanding how to provide that input. That's sometimes the missing piece I try to provide. There's the infrastructure, the projects are there and they're open, now exactly what do I do to get my input in?

This strategy must provide you with lots of feedback on what's happening on the ground in the Java community.
It does. We get questions and comments right after a presentation, of course, and that's useful. But also, I keep in contact with the user group leaders and ask them what sort of feedback they got from a particular presentation, and they also keep me informed in terms of what they plan to do. For example, the London JUG let me know that they wanted to do a Valhalla workshop, and I was able to coordinate my travel so I could be there for that.

For several years now, the JCP has been working to improve itself, most recently under JSR 387 (Streamline the JCP Program"), the latest release of which (2.11) was announced last December. Where are you now in this process?
We've been looking at the JSR lifecycle, which was really based on an artifact of the waterfall development methodology. That's just not how spec leads are using the development process anymore. So, we've been modernizing that process with fewer discrete milestones. We're keeping the open development period that's transparent and the community review followed by a vote by the EC. But we're definitely moving to more of a continuous delivery model.

What do you think about the faster release cadence implemented by Oracle last year?
I think there are two sides to that story. Faster releases mean you get innovation quicker. You're putting new technology into the hands of developers every six months instead of every three years -- which is the expectation of developers using other languages, tools, and frameworks these days. The faster release cadence combats the perception that Java is for an older generation of developers.

But for some it's been hard to adapt to this new pace of change. It's kind of entrenched in the Java culture that we do this only every three or four years, and when we do it, it's a huge project involving 100-plus changes. With the faster releases, it's only, say, 15 changes. People are having to adapt to a different way of migrating between versions.

What about Oracle's new subscription model?
Choice is the whole foundation of the JCP. I talk about the compatibility triangle. We have the spec, the reference implementation, and the TCK. That's the structure the JCP provides. It's what creates the whole Java ecosystem. Oracle's offer is the reference implementation, but other vendors can have their implementations, and that's what creates the choice for developers. Obviously, Oracle provides a strong foundation, but I think having other choices helps to solidify Java's position in the market, because you're never tied to any single vendor.

How has Oracle's decision to move enterprise Java to the Eclipse Foundation affected the JCP?
It's a big change in some ways, but the platform is the foundation, so we definitely still have a lot to do. We continue to adapt the JCP program itself to meet the needs of developers. We continue to support the spec leads who are developing the core platform through the JCP, as well as the stand-alone JSRs. We continue to run the Executive Committee. And we're committed to the ongoing engagement with the community that I've talked about.

Which is not to say that we're not watching the progress of Jakarta EE closely and responding to questions about it from the community. The transition is actually still ongoing. The Foundation is still defining all the process that will take place. But it's clear that they recognize the value of multiple implementations and the importance of standards.

How is the JCP addressing the demands on developers of the rise of AI and machine learning?
We are addressing AI in a couple of ways. There's Project Panama in the OpenJDK, which addresses big data and machine learning, and there's JSR 381 [Visual Recognition (VisRec) Specification], which is a community-lead effort. The approach is to talk a specific piece of the AI/ML space -- visual recognition -- and create a Java API for that as a stand-alone JSR not as part of the platform.

In all your travels, what's the number one concern you're hearing from Java jocks around the world?
People are wondering about all the changes and how they're going to impact them. They want to know if Java is still a good choice for them. Am I with the right technology? What can I expect going forward? People are using multiple tools these days, and they need to be constantly learning, so I think it's fair to ask whether the investment you're making in Java is the right one.

It is, of course.

Posted by John K. Waters on March 13, 2019