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.
Posted by John K. Waters on 11/08/2017 at 5:55 AM0 comments
In-memory data grid (IMDG) specialist Hazelcast Inc. today announced the release of the latest update of its namesake product. With Hazelcast IMDG 3.9, the company continues to expand its traditional focus on Java to provide near cache capabilities to all clients, including Scala, .NET, C#, C++, Python and Node.js.
The ability to create an independent grid on each client that serves as a cache for remote, server-side cache -- what's known as "near cache" -- is a capability that is unique to IMDGs, explained Hazelcast CEO Greg Luck
"It's an extra cache inside the client," Luck told ADTMag. "A near cache is fast because it provides local in-memory access to a subset of the entire cached data set that is stored remotely. It's something only in-memory data grids do."
Enhanced application speed is the chief of benefit of using near cache, Luck explained. It's often used to serve a small subset of "very hot" items with minimal latency. When an entry is found in a near cache, it can be immediately returned to the caller and involved no network communication.
In older versions of Hazelcast's IMDG, near cache keys were stored as serialized Binary Large Objects (BLOBs), which meant that keys were serialized with each get request, and that impacted application performance. IMDG 3.9 mitigates this impact by allowing de-serialized objects to be used as near-cache keys, Luck said. Near-cache lookups now drop down to high nanosecond times, making near cache as fast as dedicated in-process caches, he said.
The Hazelcast IMDG is an open source product distributed under an Apache 2 license that allows developers to include the grid in their applications. Hazelcast Enterprise is the commercially supported version.
One of the most-requested upgrades from the Hazelcast user community included in this release, Luck said, is the ability to configure data structures dynamically. In previous versions, users had to provide all configurations upfront, and there was no supported way to submit, for example, a new IMap configuration into a running cluster. Version 3.9 also allows users to submit new configurations into a running cluster; Hazelcast automatically distributes this configuration to all cluster members.
Hazelcast IMDG 3.9 also adds support for high-density (HD) memory store indexes (HD IMap always stores indexes in HD memory), and rolling upgrades (customers can upgrade their 3.8 cluster into 3.9 without any outage).
Palo Alto, Calif.-based Hazelcast has roots planted deeply in the Java language and platform (its IMDG is written in Java), but the company has spread its support over the years, thanks in part to the efforts of its open source community, to include several clients and programming languages.
Posted by John K. Waters on 10/25/2017 at 9:06 AM0 comments
The news that the Java Platform Enterprise Edition (Java EE) would be moving to the Eclipse Foundation broke about two weeks before this year's JavaOne conference, and the event, held last week in San Francisco, was buzzing with the news. The community appears to be mostly happy about this development, and hopes are high that, finally, enterprise Java will get the attention it deserves.
But there's a detail in this deal that's rubbing a lot of Java jocks the wrong way: Java EE under Eclipse might not be called "Java." Oracle wants to restrict the use of the word in naming the platform, and also the use of "javax" for the standard package of extensions, because of branding intellectual property (IP) concerns.
Oracle is re-licensing Oracle-led Java EE technologies and related GlassFish technologies to the Eclipse Foundation, including reference implementations, technology compatibility kits (TCKs,) and associated project documentation. But the company also has said that it plans to "rebrand" the platform with a new name, yet to be determined.
The working name for the draft top-level project charter for Eclipse Enterprise Java is "EE4J." That acronym elicited such "passionate feedback" from the enterprise Java community, that the Eclipse Foundation's executive director, Mike Milinkovich, published a long blog post to clarify the issue.
"I think that many people are assuming that EE4J will become the brand that replaces Java EE," he wrote. "Wrong. Java EE is a certification mark. To label something as 'Java EE,' you need to get a license from Oracle and pass the TCKs. There are many implementations of Java EE, such as WebLogic, WebSphere, JBoss, and Glassfish. EE4J is the name of the top-level project at the Eclipse Foundation. As such it is the umbrella under which the source code and TCKs for Glassfish, EclipseLink, and (hopefully) Eclipse MicroProfile will exist."
Why does this matter so much?
"The fundamental issue here is this: by moving Java EE to Eclipse, Oracle is, to some degree, forcing a distance between Java EE and the Java Platform," said Reza Rahman, a former enterprise Java evangelist at Oracle and one of the founders of the Java EE Guardians. "But Java EE has been an intrinsic part of the platform from the very beginning. All the namespaces and APIs start with the 'java" or 'javax' prefix." People contribute and adopt it because they believe in and trust the Java brand."
Branding may seem like a trivial thing, Rahman told me, but it matters—not enough to stall the process of moving Java EE to the Eclipse Foundation, but enough to organize some feedback on the issue and send it to Oracle, which the Guardians have done via an email form. Rahman says that more than 500 people signed on and sent their opinions to Oracle, the Eclipse Foundation, IBM, and Red Hat.
The site is still generating feedback from the community, and Rahman strongly urges anyone interested in this issue to add their voice to the conversation.
The Guardians have tread lightly on this issue so far, but are poised to adopt the position, officially, for retaining "Java" in the Foundation version of Java EE.
"We want to clarify that collectively we value the EE4J initiative, and we don't want it to stall, but we really do want to retain 'Java," Rahman said. "We want to remain part of the community."
If Oracle won't budge on the issue, Rahman added, enterprise Java will survive, as have other platforms, such as OSGi, which has never been part of the Java Community Process, but has a respected position in the Java space.
"We are months away from even starting to define the specification process that will be used in the future," Milinkovich wrote in his blog post. "However, when we do, I expect that this new process will create a new certification mark which can be properly considered the new 'Java EE' name. We will be engaging with the community in the selection of that name."
Posted by John K. Waters on 10/10/2017 at 2:12 PM0 comments
Last week, Mark Reinhold, chief architect of Oracle's Java Platform Group, proposed a new, time-based release schedule for the Java SE Platform and the JDK that would provide a feature release every six months, update releases every quarter, and a long-term support release every three years. He also outlined some changes his team at Oracle plans to implement around OpenJDK. (Details here.)
After the annoucement I had a chance to talk with Georges Saab, vice president of development for Oracle's Java Platform Group and chairperson of the OpenJDK governing board, about what Reinhold proposed and what it means for the Java community.
"No one should be too surprised by this," Saab told me. "We've been talking with lots of people about a new release cadence and how that might work -- folks in the Java ecosystem, members of the [Executive Committee of the Java Community Process], people in the OpenJDK community, and just lots of developers. Many of the things we've been doing in Java SE 9 have actually laid the ground work for this change. We feel the time is right for the Java ecosystem to make this work."
Developers now expect their platforms to evolve quickly, Saab said, at a pace that keeps up with rapidly changing industry trends and gives them timely access to new tools and innovation. That expectation would be tough for Oracle and the JCP to meet without an acceleration of Java's release cadence.
"If you're only releasing a new major version every other year," he said, "you simply can't adapt as rapidly as you need to today. In Java 9, for example, we had close to 100 features that were done and ready to ship a year or longer before [the platform] would be ready. We simply didn't have a vehicle to put those features into the hands of developers. The proposed changes in the release cadence are intended to make sure all the great marbles aren't backed up behind basketballs."
For context, keep in mind that Java SE 6 was released in 2006, Java SE 7 in 2011, Java SE 8 in 2014, and Java SE 9 this month.
In his blog post, Reinhold backed off an earlier suggestion that the community adopt a release train model along the lines of the annual Eclipse Release Train, with a feature release every two years. Saab agreed that the model won't work, but he likes the analogy.
"Think of it this way," he said, "you're heading home after a long day at work to catch your train and you're running late. If it's an hour and 20 minutes until the next train, you're going to kill yourself running down the stairs to get there before the doors close. But if another train is coming in three minutes, you'll walk, hold onto the handrail, and get there without killing yourself. More frequent Java SE releases means developers are going to be more likely to wait if a feature isn't ready, rather than feeling they have to jam it in because it'll be a year before they get another chance."
Oracle is currently applying this thinking to Project Valhalla, the OpenJDK project that aims to improve Java's typing system and make the language more efficient at handling situations requiring identity-less types. "We're looking at ways we might be able to break down the project into smaller pieces that can come in successively over the course of several smaller releases," Saab explained. "It has been suggested that we could do the data classes first, and then pattern matching could come in as a second step."
If a faster release cadence is implemented for the Java Platform and the JDK, does that mean we won't see big changes in the future?
"Oh, big things are still coming," Saab said. "They'll just be coming in smaller pieces."
Posted by John K. Waters on 09/11/2017 at 12:20 PM0 comments
Mark Reinhold, chief architect of Oracle's Java Platform Group, says "Java needs to move forward faster" if it's going to compete effectively with other software development platforms, which are evolving at a more rapid pace. He made that rather non-controversial declaration this morning on his personal blog, but he also offered a strategy for making this happen that might stir some debate.
Reinhold backed off an earlier suggestion that the community switch from its historical feature-driven release model to a time-driven "train" model (think Eclipse Release Train, with a feature release every two years.) "The two-year train model was appealing in theory, but it proved unworkable in practice," he wrote.
Instead, he's now proposing a strict, time-based release schedule for the Java SE Platform and the JDK that provides a feature release every six months, update releases every quarter, and a long-term support release every three years.
"That's fast enough to minimize the pain of waiting for the next train," he wrote, "yet slow enough that we can still deliver each release at a high level of quality, preserving Java's key long-term values of compatibility, reliability, and thoughtful evolution."
Specifically, Reinhold is proposing the following:
- Feature releases can contain any type of feature, not just new and improved APIs, but also language and JVM features. New features will be merged only when they're nearly finished, so the release currently in development is feature-complete at all times. Feature releases will ship in March and September of each year, starting in March 2018.
- Update releases will be strictly limited to fixes of security issues, regressions, and bugs in newer features. Each feature release will receive two updates before the next feature release. Update releases will ship quarterly in January, April, July, and October, as they do today.
- Every three years, starting in September of 2018, the feature release will be a long-term support release. Updates will be available for at least three years and quite possibly longer, depending on the vendor.
This model doesn't really alter the current rate of change overall, he allowed, but it provides "many more opportunities to deliver innovation."
"The six-month feature releases will be smaller than the multi-year feature releases of the past," he wrote, "and therefore easier to adopt. Six-month feature releases will also reduce the pressure to backport new features to older releases, since the next feature release will never be more than six months away."
Reinhold acknowledged in the blog post that his proposal will, if adopted, require major changes in how contributors in the OpenJDK Community produce the JDK itself. In a note posted to the OpenJDK mailing list, he laid out how that community might implement this new model as a single, long-running "JDK" release project that hosts the mainline code base and produces the feature releases, and a single, long-running "JDK Updates" project to produce the update releases.
"Two long-running projects will save some administrative overhead, and also eliminate the confusion that regularly arises when someone is a Committer to JDK $N but not JDK $N + 1," he wrote, adding parenthetically, "We could consider just one long-running project, but two makes more sense since the two types of releases will have different policies, content, schedules, and leadership."
He gets specific here, too, outlining how his proposed JDK Project would run:
- The main development line will always be open but fixes, enhancements, and features should be integrated only when they're nearly finished. The main line should be feature complete at all times.
- We'll fork the main line into a release-stabilization branch three months before the GA date of the next feature release. That branch will immediately be in Rampdown Phase 1, enter Rampdown Phase 2 a month later, and then enter the Release Candidate phase a month after that. (Whether the branch is another repository or an actual Mercurial branch is a detail we can figure out later.)
- We'll continue to use the JDK Enhancement Proposal (JEP) Process for new features and other significant changes. The bar to target a JEP to a specific release will, however, be higher since the work must be Feature Complete in order to go in. Owners of large or risky features will be strongly encouraged to split such features up into smaller and safer parts, to integrate earlier in the release cycle, and to publish separate lines of early-access builds prior to integration.
He also laid out some changes his team at Oracle plans to implement:
- Starting with JDK 9 we'll ship OpenJDK builds under the GPL, to make it easier for developers to deploy Java applications to cloud environments.
- We'll continue to ship proprietary "Oracle JDK" builds, which include "commercial features" such as Java Flight Recorder and Mission Control, under a click-through binary-code license. Oracle will continue to offer paid support for these builds.
- After JDK 9 we'll open source the commercial features in order to make the OpenJDK builds more attractive to developers and to reduce the differences between those builds and the Oracle JDK. This will take some time, but the ultimate goal is to make OpenJDK and Oracle JD builds completely interchangeable.
- Starting with JDK 9 we'll reduce the set of ports that we maintain, focusing mainly on Linux, macOS, and Windows on the x64 architecture. Other OpenJDK contributors will be welcome to take on the other ports that Oracle engineers currently maintain.
- Finally, for the long term we'll work with other OpenJDK contributors to establish an open build-and-test infrastructure. This will make it easier to publish early-access builds for features in development, and eventually make it possible for the OpenJDK Community itself to publish authoritative builds of the JDK.
That's a lot of change, but to his credit, Reinhold is offering a well-considered plan and asking for feedback. And it could be argued that what he's proposing fulfills the long-held dreams of Java jocks everywhere.
Oracle is clearly gearing up for a big JavaOne this year. Reinhold's posts about accelerating the Java timeline come on the heels of news that Oracle is considering moving the Java EE Platform to an open source foundation. Should be an interesting show.
Posted by John K. Waters on 09/06/2017 at 10:07 AM0 comments
Java earned an "all-time low score" in the latest TIOBE Programming Community Index, along with C, and yet the two programming languages retained the top two spots, ranking first and second, respectively.
In fact, all the top 10 languages in the TIOBE index except one (Visual Basic .NET) slipped in the rankings, year to year. TIOBE researchers credit this shift to the rise in popularity of a group of leaner languages that includes Crystal (No. 32), Kotlin (No. 41), Clojure (No. 42), Hack (No. 43), and Julia (No. 46).
Crystal, a statically typed variant of Ruby, made a particularly noteworthy jump from No. 60 to No. 32 in a single month. TIOBE researchers even gave the language a shout out in this report: "Since it is compiled it is superfast and has a small memory footprint without losing the feeling of being easy to use," they wrote. "It seems worthwhile to give it a try."
TIOBE Software has been publishing the results of its monthly search for the languages in which the most lines of code were written since 2001. The ratings are based on the number of skilled engineers worldwide, language courses, and third-party vendors, the company says. TIOBE uses 25 search engines to collect key words from the highest ranked websites of Web traffic monitor Alexa and calculates the most lines of code written in a given month to determine its percentage share of developers' attention.
"It is important to note that the TIOBE index is not about the best programming language or the language in which most lines of code have been written," the company has said on its Web site. TIOBE publishes its search criteria on its Web site.
Apple's popular open-source Swift came in at 11th on the index with a gain of 0.16 percent share. Go, an open source climber that cracked the top ten in July, dropped to 16th, even though it actually early an additional 0.37 percent share. R, MATLAB, Scratch and Dart also climbed the chart.
Posted by John K. Waters on 08/07/2017 at 1:25 PM0 comments
Oracle set another record with its latest quarterly Critical Patch Update (CPU), which included 308 vulnerability fixes, 32 of which were Java-related. Released earlier this month, this CPU more than doubles the 136 fixes issued just over a year ago.
That last insight came my way from the folks at Waratek, the Dublin-based app security tools provider with a special focus on Java. I talked with the company's lead security architect, Apostolos Giannakidis, about this CPU, and he argued that the high number of vulnerabilities in the Java Runtime Environment (JRE) covered by this release demonstrate that the Java SE platform continues to be a very popular attack vector.
"The attack vector of the Java platform is huge," he told me. "More and more vulnerabilities are discovered that affect both the legacy and newer versions. Attackers are able to compromise applications and systems specifically by attacking the runtime itself -- and, this trend keeps increasing at a fast rate."
Of the 32 Java-related vulnerabilities covered in this CPU, 10 earned high-risk CVSS ratings. Oracle uses the Common Vulnerability Scoring System (CVSS) to provide an open and standardized rating of the security holes it finds in its products. Each vulnerability is issued a unique CVE number.
This CPU includes fixes for vulnerabilities in a range of Java components, including AWT, ImageIO, JavaFX, JAXP, ThreadPoolExecutor, AsynchronousChannelGroup, LambdaFormEditor, LDAP, Nashorn, JAR verifier, DSA, ECDSA, Elliptic Curve, X.509, PKCS#8 and the HotSpot VM. These vulnerabilities could allow attackers to escalate their privileges, corrupt the JVM's memory, crash the JVM or execute arbitrary code and system commands.
Giannakidis pointed to two new vulnerabilities fixed in this CPU in the serialization component of the JVM that would allow the excessive allocation of memory. (Serialization is the process of converting an object into a stream of bytes for transport and storage.) He also pointed to fixes in this release to deserialization vulnerabilities in the RMI and in the Distributed Garbage Collector. (Deserialization reverses the process when the data is received.)
"This is despite the fact that the January CPU addressed deserialization vulnerabilities in the same components," Giannakidis said. "This demonstrates that there are still critical deserialization attack vectors in the Java platform itself. I would have to say that it looks very much like Oracle is playing the Whac-A-Mole game with the deserialization vulnerabilities."
The problem here is that the Java Runtime is one of the most complex runtimes, he added. "The amount of lines of code in the code base is considerable," he said. "With such a big code base, it makes sense that you are going to have increased vulnerabilities. The important thing to remember is that these vulnerabilities were already there, lurking in the code base for a long time, based on my analysis. It's a matter of spending time finding them. In fact, the vulnerabilities in the runtime are now the focus of the security community."
Each quarterly CPU is a set of patches for multiple vulnerabilities put together since the previous update. They do not include the security advisories from previous updates; those are available on the Oracle Technology Network Web site. However, most CPUs are cumulative, Oracle has said, which means the application of this CPU should resolve new vulnerabilities and previously-reported security issues.
Oracle's CPUs are issued on a quarterly schedule announced at the beginning of the year. The purpose of that schedule is to provide users of Oracle products with a level of predictability that will foster regular maintenance activity, the company has said. The next CPU is scheduled for release on Oct. 17.
Posted by John K. Waters on 07/26/2017 at 11:43 AM0 comments
Did you hear that, a kind of whooshing sound coming from the Java community? It was a collective sigh of relief as word got out about the results of the Public Review Reconsideration Ballot for JSR 376, the Java Platform Module System (JPMS) specification, better known as Jigsaw. In case you missed it, the votes were 24 in favor with one abstention (Red Hat). No "no" votes this time around.
A vote in May by the Executive Committee (EC) of the Java Community Process (JCP) to reject JSR 376 moved the Expert Group to address the EC's concerns at something approaching warp speed, and that's just what they seem to have done.
"I think it's fair to say that people were highly motivated to reach closure on all of these issues," Georges Saab, VP of Development for Oracle's Java SE Group, told me in an earlier interview.
Red Hat explained its decision to abstain in the voting comments section of the ballot page:
Red Hat is voting Abstain at this time because although we think there has been positive progress within the EG to reach consensus since the last vote, we believe that there are a number of items within the current proposal which will impact wider community adoption that could have been addressed within the 30-day extension period for this release. However, we do not want to delay the Java 9 release and are happy with the more aggressive schedule proposed by the Specification Lead and EG for subsequent versions of Java because getting real world feedback on the modularity system will be key to understanding whether and where further changes need to occur. We hope that the Project Lead and EG will continue to be as open to input from the wider Java community as they have been in the last 30 days and look forward to the evolution of Java being driven by data from users and communities beyond OpenJDK.
SouJava's comment accompanying its vote included a noteworthy admonition to the community:
As a lesson for future JSRs: the Java Language is a fundamental piece of the Java ecosystem. JSRs that touch the Java Language Specification, should be very careful that proposed changes be reflected in the early drafts. Creating confusion around such a fundamental part of Java is very detrimental to the whole Java ecosystem. We are glad that those issues have been resolved now.
SouJava's comment about "creating confusion around such a fundamental part of what Java is" speaks to the source of much of the angst around the coming of Java 9, which prompted Mark Reinhold in May to engage in an effort to dispel a number of misconceptions about Jigsaw in Java 9. He offered his top 10 from "a long list" during the Devoxx UK developer conference, and later interviews. (My coverage here).
It's also worth noting TomiTribe's voter comment on the process itself:
As stated in our first vote and blog, we saw great value in the 30-day clock getting the EC and EG on the same page with a clear result. The spec lead has done an outstanding job of handling the flood of feedback that resulted and should be congratulated. We believe several of the decisions made, such as permitting illegal access by default but with clear warnings will lead to a smoother transition that still creates pressure for movement into modularity. Though some may have viewed the original vote as negative, it should be seen as a success of the JCP process and a sign of strength for Java overall.
More remains to be done, of course. More than one "yes" voter included a few pointed comments about updates and refinements in future releases. Twitter's comment is a good example:
We are disappointed that the community will not immediately see the benefits that they are expecting JPMS to provide (#AvoidConcealedPackageConflicts, in particular). But we understand that the most requested features will require a lot more discussion and due-diligence than is allowed in the JDK 9 timeframe. We hope that the first version of JPMS will provide a good basis for such features to be worked on and introduced in future JDK releases.
It's a process, after all, and the impact of modularization on Java is hard to overstate. Some industry watchers have said the JPMS will effectively transform Java into a new language. As IBM put it in its voter comments, "We see this release of JPMS as the strong foundation for a new Java SE platform architecture, and expect to build upon this with feedback and experience from our customers and the community."
Posted by John K. Waters on 07/17/2017 at 6:41 AM0 comments
As JDK 9 enters the Release-Candidate Phase, it's worth noting exactly what that means for this oft-delayed release. In a nutshell, the Initial Release Candidate phase, which started on June 22, is about fixing "showstopper" bugs and building momentum toward the Final Release Candidate milestone, currently scheduled for July 6.
That's how Mark Reinhold put it in a note on Monday on the JDK 9 mailing list. He also proposed tightening the goals previously adopted for Rampdown Phase 2 (RDP 2). These include:
- Fixing all P1 bugs that are new in JDK 9 and critical to the success of this release
- Decommitting from fixing any P1 bugs that are not new in JDK 9 and are not critical to this release, but were previously targeted to this release
- Explicitly deferring any P1 bugs that are new in JDK 9 but are either not critical to this release or cannot, for good reason, be fixed in this release
Reinhold said that all P2-P5 bugs should be left to future releases at this point, regardless of whether they are in product code, tests or documentation.
P1 (priority 1) bugs are the critters that have to be squashed before a product can be released. Bugs that should be fixed if there's time and resources, are the P2s. The latter bugs almost certainly won't be addressed before the JDK 9 release.
Those who are responsible for the P1 bugs in JDK 9 are advised to follow one of three courses of action: Develop a fix for the bug and then request approval to integrate it; remove it from the list if it's not new in JDK 9; if it is new, but isn't critical or can't be fixed in time, request that the bug be deferred. The JDK 9 community page advises issuing a request explicitly from the release through the bug deferral process adopted earlier for RDP 1. But Reinhold wrote, "There is no need to defer unfixed P2-P5 bugs explicitly."
In any event, they won't be fixed before the release.
P3-P5 are of vanishing importance at this point in the process; they are virtually irrelevant to the overall status of the release. In fact, the OpenJDK community page advises committers to take no specific action on these bugs at this time: "You don't need to defer them, either explicitly via the deferral process or even implicitly by adjusting the 'Fix Version' field...."
The latest list of JDK 9 Release Candidate bugs can be found here.
Posted by John K. Waters on 06/28/2017 at 6:08 AM0 comments