As I write this, Heather VanCura, newish Chair of the Java Community Process, is on the road again. The top of her Twitter feed features a photo taken a few days ago of her, surrounded by women coders in the African country of Ivory Coast. Further down is a shot of her with the Abidjan Java User Group in the same country. And down a little further: there she is in Amsterdam.
VanCura’s latest community-building trip will take her to five countries in 16 days, which, coming so soon after JavaOne, seems exhausting to me. To VanCura, however, it’s just part of the job. The Java community, she reminded me when we spoke last week, is global.
“I think my first trip out of the country was to JavaOne Japan in 2001 or 2002,” she said. “It was a really big deal. But now, on this trip, I’ll be at developer conferences in the Netherlands, Belgium, Nigeria, Morocco, and Ivory Coast. JavaOne has gotten a little smaller, but that’s not an indication that the Java community is smaller. It’s because there are so many developer conferences now all over the world.”
VanCura has been working at the JCP since 2000 in various roles, from marketing manager to program director. As the current Chair, she leads the activities of the JCP Program Office, manages its organization’s membership, guides spec leads and experts through the process, leads the Executive Committee (EC) meetings, and manages the JCP.org Web site. She’s also responsible for the Adopt-a-JSR program, organizing hack days and other events, and the overall growth of the membership. And when she’s not doing all that, she contributes to the JCP blog, Twitter feed, and Facebook page. Unsurprisingly, she shows up on just about every “women in technology” list that matters, and she places a high priority on diversity in the ever-expanding Java ecosystem.
I sat down with her in Oracle’s San Francisco offices to talk about her first year as head of the organization behind Java’s standard technical specifications. I edited the following on my side of the conversation for clarity.
JKW: You’ve been at the JCP in various roles for nearly two decades, which means you’ve had a front row seat for some big changes in the Java language, platform,da and ecosystem. How would you define the JCP’s role today in that ecosystem?
VanCura: The mission of the JCP has been essentially the same from the beginning: to bring developer, real-world community feedback into the standardization process. That’s why it was created. That hasn’t changed.
JKW: You’ve been the Chair of the JCP since Patrick Curran retired officially in February after serving 10 years in that role. What are you doing differently?
VanCura: People ask me that, and I have to say, not a lot. Patrick and I were really kind of tag-teaming it for quite a while there. I was going to the executive committee meetings and we were working toward this point for about a year.
JKW: But the JCP has changed a lot since the Oracle acquisition: two ECs merged, the JSPA got revised, JSR 364 broadened JCP membership, Adopt-a-JSR got JUGs more involved, and JCP.next made everything more transparent. What were your roles in those initiatives, and which ones do you feel best supported the JCP mission?
VanCura: The JCP was developed originally at a time when it was more of a closed-source operation, and we had to adapt and become more open over time, and more transparent. That transparency was something that I started to push for in 2006. And a couple of years ago we recognized the need to give individuals more standing in the organization and to pull in more Java User Groups (JUGs). That was a major change I was involved in.
JKW: How Oracle’s new, faster release cycle going to affect the JCP?
VanCura: We’ve been talking about rolling out some changes that haven’t been approved by the EC yet, but almost. One is reducing the minimum review period for JSR milestones. For a long time 30 days has been the minimum review period, but now we’re going to have 14-day minimums. Spec leads will continue to have the freedom to run their projects as they think they’re going to best fit the needs of the community. They can choose to have longer review periods. For some of the Java EE JSRs the spec leads tended to choose 90-day review periods. But I anticipate that a lot of people will choose a 14-day review period.
JKW: You’re trying to reflect a more iterative style of development?
VanCura: You have to keep pace with the way people are working. Nowadays, you see new release builds every couple of weeks. Also, we’re moving to one-week EC ballots. The ballots have been 14 days, but if you’ve been looking at things all along, why do you need two whole weeks to decide if this should move forward. That’s why we have three ballots during the lifecycle of a JSR. And we’re also looking at adding language that encourages more transparency for spec leads: You should be sharing your TCK with your expert group members. You should be consulting with the EG members after final release. Reference implementation should be developed in open source. They can still pick the style that works best for them. We try not to get too into the details of how you’re going to carry this out. That’s part of the secret of the success of our community.
Another consequence of a faster release cadence is a kind of reordering of the process. When we have the milestones for the JSRs, we’re not necessarily expecting a full written spec. It used to be that you’d write the spec, then do the reference implementation, and then the TCK. But that’s not specified in the JCP process. You don’t have to start with the spec and then do the code behind closed doors. What we’ve seen over time is that things often start in open source — which we encourage. You start with the code, and then decide when you want to create a standard. You’re doing code development in the open in an open-source project, and then you see, oh, there’s some commonality here, there are different players converging, and this is what we should standardize on. So, you already have part of the reference implementation in the code in the open source project, and then you start the specification-writing process. And so, you start to see the full written spec coming later in the process.
JKW: How does the JCP view Oracle’s decision to contribute Java EE to the Eclipse Foundation?
VanCura: The fact that Oracle is donating Java EE 8 technologies to Eclipse is a good, positive step, but I don’t think anyone knows what the impacts will be.
JKW: How is it a positive step?
VanCura: Each year I do an annual summary of what JSRs have been active over the last year, which I publish. What I saw starting in 2011/2012 is less leadership happening outside Sun, and over the past few years, less leadership happening outside Oracle. The community is not leading as many JSRs as they used to. Does anyone think this is a healthy thing? From a community management perspective, this doesn’t seem good. More people should be stepping up. We need more community engagement and leadership outside of one company. So, from my perspective, Java EE moving to Eclipse is healthy, because you want more people and more stake holders have leadership positions. You want the community to be driving these things and not be dependent on one individual company.
The community is the number one thing that has made Java successful for the past 20-plus years, and I think it will continue to make it so. But also, the fact that it is the most well-documented language technology out there, and that is a result of the specifications.
Source:-adtmag
