Is it time to "reboot" the OpenJDK Mobile Project, which focused on porting the JDK to iOS, Android, and the now deceased Windows Mobile? Johan Vox, co-founder of Gluon, a Belgium-based mobile solutions, and a Java Champion, thinks so.
Vox made his case recently for restarting public work on the fallow project on the mobile-dev mailing list. "After a long time, it is a good moment now to restart the public work in the OpenJDK Mobile project," he wrote.
"In the past, we had a repository with code based on OpenJDK 9 that allows [us] to build the class libraries (including native code) and one or more VMs for Android and iOS," he explained. "While this works, we still have the limitation on iOS, where dynamic code is not allowed, hence a JIT is not an option. The Zero VM works there (interpreter mode) but [it] is slow."
Vox's idea is to use the GraalVM AOT compiler to compile the code at build time. The compiled Java code could be linked with native libraries compiled for the target OS and create executables. Most of the VM functionality is provided by a very small set of files in SubstrateVM, he explained, which are linked to via the GraalVM native image.
"We already did this for iOS, based on Java 11," he wrote, referring to the June release by his company of Gluon Client plugins that support Java and JavaFX on iOS devices. "The [difference] to the upstream code is remarkably small."
The Gluon Client plugins, currently in beta, offer configurations for running Java 11+ and Java FX apps on iOS devices or the iPhone simulator. They're designed to allow developers to create iOS and Android apps in Java. Gluon Mobile provides UI control for the client application, handles communication with the server-side cloud and third-party services, and abstracts the platform-specific APIs. Gluon Client tools can generate a native executable for iOS devices.
The OpenJDK Mobile Project was originally set up to manage two different repositories, each with a different set of integration rules. The mobile/jdk9 forest was allowed to contain only the OpenJDK officially approved changeset that had been reviewed as if it were going to be immediately integrated into JDK 9. The mobile/dev repository was designed to be used for integration of features that were not approved for JDK 9 integration, early prototypes, or sharing of early features not yet ready for integration into mobile/jdk9.
For his part, Voss plans to use Project Skara, an alternative SCM and code review tool, to create a "synchronized fork" of the OpenJDK master and to push the changes required to build the native libs for the core libraries.
"Ultimately, it would be ideal if all required changes can go upstream, he wrote. "At this moment, this is iOS only, but there are no showstoppers to do this for Android as well. The architectures are pretty similar."
Posted by John K. Waters on July 10, 20190 comments
The Eclipse Foundation announced the latest of its stepped-up simultaneous project releases last week. SimRel-2019-06, its second quarterly release, comprises 76 projects, including the latest Eclipse IDE. Actually, the entire list is simply considered part of the Eclipse IDE 2019-06 release train.
Although this new fast-paced release schedule has been largely welcomed by the community, keeping up has taken some getting used to for more than a few. If you're among those who find themselves scrambling to stay abreast of the changes, check out the Foundation's simultaneous release schedule.
Among the new and noteworthy in this release (according to the Foundation) are:
- Eclipse Buildship: Eclipse Plug-ins for Gradle 3.1.0 Eclipse Buildship is a collection of Eclipse plug-ins that provide support for building software using Gradle. Buildship aims to provide a deep integration, and to make the Eclipse IDE more powerful by allowing the user to do more from within the IDE.
Since Gradle 5.4, projects have been able to declare an arbitrary set of tasks in the eclipse.synchronizationTasks configuration. Once configured, Gradle will automatically execute those tasks every time the user synchronizes workspace with the build.
- Eclipse Business Intelligence and Reporting Tools (BIRT) 4.7.0 Eclipse BIRT is an open source Eclipse-based reporting system that integrates with Java/enterprise Java applications to produce "compelling reports." It's used to create data visualizations and reports that can be embedded into rich client and Web applications.
- Eclipse Business Process Model and Notation (BPMN2) 1.5.0 Eclipse BPMN2 is an open source component of the Model Development Tools (MDT) subproject to provide a metamodel implementation based on the forthcoming Business Process Model and Notation (BPMN) 2.0 OMG specification. The goal of this release is to synchronize with Eclipse Photon, a past version of Eclipse. No new major enhancement are currently planned.
- Eclipse C/C++ Development Tooling (CDT) 9.8.0 The Eclipse CDT Project provides a fully functional C and C++ IDE based on the Eclipse platform. Features include: support for project creation and managed build for various toolchains, standard make build, source navigation, various source knowledge tools, such as type hierarchy, call graph, include browser, macro definition browser, code editor with syntax highlighting, folding and hyperlink navigation, source code refactoring and code generation, visual debugging tools, including memory, registers, and disassembly viewers.
- Eclipse CDO Model Repository 4.7.0 The Eclipse CDO (Connected Data Objects) Model Repository is a distributed shared model framework for EMF models and meta models. CDO is also a model runtime environment with a focus on orthogonal aspects, such as model scalability, transactionality, persistence, distribution, and queries.
CDO has a 3-tier architecture supporting EMF-based client applications, featuring a central model repository server and leveraging different types of pluggable data storage back-ends like relational databases, object databases and file systems. The default client/server communication protocol is implemented with the Net4j Signalling Platform.
- Eclipse Collections 9.2.0 Eclipse Collections is a collections framework for Java. It has JDK-compatible List, Set, and Map implementations with a rich API, additional types not found in the JDK, such as Bags, Multimaps, and a set of utility classes that work with any JDK compatible Collections, Arrays, Maps, or Strings. The iteration protocol was inspired by the Smalltalk collection framework. Eclipse Collections originated as an open source project on GitHub called GS Collections. This is also the Photon release of Eclipse Collections project.
- Eclipse Dynamic Languages Toolkit 5.11 The Eclipse Dynamic Languages Toolkit (DLTK) is a tool for vendors, researchers, and end-users who rely on dynamic languages. DLTK comprises a set of extensible frameworks designed to reduce the complexity of building full featured development environments for dynamic languages, such as PHP and Perl. Besides a set of frameworks, DLTK provides exemplary Tcl, Ruby, and Python IDEs ready to use out of the box.
Posted by John K. Waters on June 26, 20190 comments
It's been about a month since Mike Milinkovich, executive director of the Eclipse Foundation, explained in a blog post the status of negotiations between Eclipse and Oracle on the final details of the enterprise Java handoff agreement. The last bone of contention was the use of the javax* package namespace "in the evolution" of Jakarta EE specifications, and the use of Java trademarks in the Java EE spec, but the two organizations got past it.
"[F]ollowing many months of good-faith negotiations, the Eclipse Foundation and Oracle have been unable to agree on terms of an agreement for the Eclipse Foundation community to modify the javax* package namespace or to use the Java trademarks currently used in Java EE specifications," Milinkovich wrote. "Instead, Eclipse and Oracle have agreed that the javax* package namespace cannot be evolved by the Jakarta EE community. As well, Java trademarks such as the existing specification names cannot be used by Jakarta EE specifications."
He added that the details of the talks would remain under wraps: "Because of the complexity and confidential nature of our negotiations, the Eclipse Foundation and Oracle have also agreed that we will not attempt to characterize here what has resulted in this outcome. It is the best outcome we could mutually achieve for the community."
Even one of the most vocal critics of Oracle's intractability on these two issues, the Java EE Guardians, seems ready to move on. The group of volunteers who joined forces in 2016 to support enterprise Java, then in the hands of a seemingly indifferent Oracle, declared in a recent blog post their "great excitement" about the final agreement between Big O and the Eclipse community. But that excitement was tempered with a splash of caution.
"One of the critical decisions that needs to be made prior to moving forward is how to proceed with the transition from the javax* namespace," they advised. "The Java EE Guardians agree with the consensus of many in the community, as there is a broad desire to move everything to the jakarta* namespace at once, rather than taking an incremental approach. The Java EE Guardians encourage the community and the Eclipse Foundation to focus on getting a clear consensus about this quickly so that Jakarta EE can confidently evolve with no more delays."
"The truth is, we're thrilled about this agreement," Dennis R. Gesker told me. "I know I'm commenting from out in the cheap seats, but here in my shop, we're like, wow, things have gone from glacially slow to superfast. And that's a good thing."
Gesker is chief technology officer at Alamon Inc., in Kalispell, Mo., and a member of the Guardians. And his "cheap seats" are in a real-world daily work environment.
"We see [the agreement] as a great opportunity to start building cohesion across the ecosystem," Gesker said. "Not to cast aspersions, but we've got an honest broker inside Eclipse now to start moving things along really fast, and then start bringing in some folks who have spun out into other projects. This is a chance to say, come on in and bring your ideas with you. Me in particular, but my guys as well: we're hoping they take a Big Bang approach: rename it, refactor, move on -- and deal with compatibility issues as they arrive."
Going forward, the enterprise Java community will have to steer clear of the "Java" trademark, and the evolution of the APIs cannot take place under the javax* package.
"However," the Guardians noted, "Jakarta EE will be able to use the Java EE APIs and javax* package as-is and be able to evolve the technology forward under the jakarta* package. This will provide a path forward to further evolve widely relied upon Java EE APIs such as Servlet, JPA, JAX-RS, WebSocket, JMS and so many others. It can also be objectively said the transition from Java EE to Jakarta EE represents one the largest and perhaps most significant technology stewardship transfers ever attempted. This includes not just the agreement but the source code transfer of the Java EE compatibility test kit (TCK) as well as the reference implementation GlassFish.
"This is not a big deal for us," Gesker said, "for the day to day, guys, but I fully appreciate that the folks who have been hardcore promoters of Java EE for so long might not be that happy. I get why they might want to hold onto javax. Programmers have tools they like, and they can be really passionate about them. I mean, there's a flareup in my office every couple of weeks about who's using the best IDE! But I want to say, hold on, we're going to get it together. A lot of these growing pains are going to go away, and we're all going to become more effective and efficient."
Posted by John K. Waters on June 12, 20190 comments
It took two and a half years, but the NetBeans Java-based IDE has finally graduated to Top-Level Project (TLP) status at the Apache Software Foundation (ASF). The popular open source development environment, tooling platform and application framework now comprises the largest codebases at the ASF. (It's 20 years old, after all.)
As a first-class-citizen in the ASF, the NetBeans project will now be able to receive more contributions from the open source community. Its previous status as an Incubator Project provided more limited access. That's the official entry path for projects and code bases whose supporters want them to become part of the ASF. It's where those projects are vetted to make sure they comply with the ASF legal standards and their support communities adhere to the ASF's guiding principles.
The stewardship of the IDE shifted from Oracle to the ASF in late 2016. NetBeans 8.2 was the last release by Oracle. It's worth noting that individual contributors from Oracle continue to work on the project "as part of the worldwide community of individual contributors, both self-employed as well as from other organizations," the ASF said in a statement.
NetBeans is literally the first Java IDE. It was originally demoed back in 1998, about two years after Sun Microsystems created the Java language. Sun acquired the IDE in 1999 with the goal of evolving the tooling along with the Java platform.
NetBeans 11.0 was released in April 2019. It's the project's third major release since the IDE entered the Apache Incubator.
"Being part of the ASF means that NetBeans is now, not only free and Open Source software, it is also uniquely, and for the first time, part of a foundation specifically focused on enabling open governance," said Geertjan Wielenga, vice president of Apache NetBeans, in a statement. "Every contributor to the project now has equal say over the roadmap and direction of NetBeans. That is a new and historic step and the community has been ready for this for a very long time. Thanks to the strong stewardship of NetBeans in Sun Microsystems and Oracle, Apache NetBeans is now ready for the next phase in its development and we welcome everyone to participate as equals as we move forward."
Wielenga was an Oracle product manager and developer advocate for open source projects. He reportedly did a lot of the heavy lifting when Oracle donated the NetBeans code to the ASF.
NetBeans continues to be a popular Java IDE (1.5 million active users, according to the community). The project won the 2018 Duke's Choice Award, a well-established industry award in the Java ecosystem. But the development environment has grown beyond its Java roots to support C/C++, Groovy, PHP, JavaScript and the HTML5 and CSS Web development standards.
Posted by John K. Waters on May 8, 20190 comments
Red Hat has again stepped in to assume the stewardship of OpenJDK projects no longer supported, long-term, by Oracle. The Raleigh, N.C.-based open source solutions provider and long-time Java community leader has taken on the role of steward of OpenJDK 8 and OpenJDK 11 update releases. Red Hat will "work with the community to enable continued innovation in Java," the company said in a statement.
Red Hat assumed stewardship of OpenJDK 6 in March 2013, and OpenJDK 7 in June 2015. The company has actually been involved in the OpenJDK, which is an open source implementation of Java, since 2007, when it signed Sun Microsystems' OpenJDK Community TCK License Agreement. The TCK (Technology Compatibility Kit) is the official test suite for compliance of implementations of Java Specification Requests (JSRs); they can only be provided by the spec lead of a JSR. Red Hat was the first big software vendor to license the TCK.
Red Hat is among the largest contributors to the OpenJDK project. Long-time Java technical lead and lead technical engineer of Red Hat's Java Platform team, Andrew Haley, was appointed as project lead for OpenJDK 8 and OpenJDK 11 in February 2019. He has been an active member of the OpenJDK governing board for seven years.
In addition to its work within individual OpenJDK communities, Red Hat leads the upstream development of Shenandoah, a high-performance garbage collector that is now part of OpenJDK 12.
In December 2018, Red Hat announced commercial support for OpenJDK on Microsoft Windows. Red Hat plans to launch OpenJDK in a Microsoft installer in the coming weeks and distribute IcedTea-Web, the free software implementation of Java Web Start, as part of the Windows OpenJDK distribution. JDK Mission Control is available as part of Red Hat Software Collections and for Windows through the Red Hat Customer Portal, enabling developers and administrators to collect and analyze data from Java applications running locally or deployed in production environments.
"My guess is we can expect more news on the transition of Java stewardship over the next few years," said Ovum analyst Michael Azoff, in a statement, "and I believe Red Hat is a safe pair of hands to take on that role. It's also a better fit with Java being open source and Red Hat being a leader in the open source software community."
Rich Sharples, Red Hat's senior director of product management acknowledged frequent public doubts have been expressed about the future of Java, but rumors of its demise, he told ADTmag, have been greatly exaggerated.
"From our point of view, there's still another 20 or 30 years of life left in Java," said Rich Sharples, Red Hat's senior director of product management. "There's a very long way to go for Java, and that's why we're continuing to put our resources behind it and the community."
Red Hat recently addressed some specific concerns that Java isn't competitive in emerging cloud-native architectures, such as microservices, containers, and serverless, with its newly released Quarkus framework, which is designed to significantly reduce the footprint and latency of Java applications.
"We're still all-in on Java," Sharples said.
Sharples also noted that Oracle's new faster release cadence is giving the community of Java users additional opportunities to reconsider what they're currently running on.
"People are going to be very consciously upgrading or thinking about upgrading much more frequently," he said. "Quite frankly, if you're upgrading version numbers, you've got to also be thinking about which vendor you source the JVM from."
"Java is in a renaissance moment," Mike Piech, vice president and general manager of Red Hat's Middleware group, said in a statement. "It continues to evolve and be a key component of new, emerging architectures. There is a developer hunger to bring Java into the next generation of development, and Red Hat is a leader in this movement through our involvement in the OpenJDK project. We are helping to lead the way in our efforts to enable users of JDK to have support and innovation in their existing environments. Red Hat remains committed to Java and is excited to have the opportunity to help steward the OpenJDK community."
Posted by John K. Waters on April 24, 20190 comments
In what is sure to be the last chapter in the seemingly unending courtroom drama that is Oracle v. Google, Oracle has responded to Google's hail-Mary request, filed with the Supreme Court in January, to review the appeals court's ruling that the Alphabet subsidiary infringed on Oracle's copyrights over its use of 37 Java APIs in the Android OS. In its 46-page petition, Oracle disputed Google's claim that the lower court's decision will harm software developers.
"Google claims the Court of Appeals' decision imperils the future of 'interoperable' software," the petition reads. "But Google has conceded that it purposely made its platform incompatible with Oracle's. So this is no case to consider the copyright implications of interoperability ... ."
The Oracle petition also shot down Google's fair use argument: "Google cites not a single case -- in any court -- that has ever held that copying this volume of code (or this much structure and organization) into a competing work is fair."
And it re-asserted that Google's actions "inflicted incalculable market harm" and represented "the epitome of copyright infringement."
The petition wraps up with a zinger: "Google's theory is that, having invested all those resources to create a program popular with platform developers and app programmers alike, Oracle should be required to let a competitor copy its code so that it can coopt the fan base to create its own best-selling sequel. That argument would never fly with any other copyrighted work ... ."
Oracle originally sued Google in 2010, but Google argued that its use of the Java APIs owned by Oracle was allowed under the "fair use" provisions of the federal copyright law, and therefore did not infringe on Oracle-owned copyrights. But that argument failed to persuade the court. "There is nothing fair about taking a copyrighted work verbatim and using it for the same purpose and function as the original in a competing platform," a panel of three Federal Circuit judges wrote in that opinion.
If my inbox is any indication, more than a few ADTmag readers are tired of this drama, and I don't blame them. But it's important to keep in mind what was originally at stake here; the court effectively ruled that copyright protections do extend to software interfaces. The impact of that decision is still to come.
Posted by John K. Waters on April 10, 20190 comments
Oracle announced the general availability of JDK 12 last week, which is the third release under its still newish accelerated release cadence. JDK 10 was the first feature release of the new cycle; Java 11, which was released six months later, was the first long-term support (LTS) release. The next LTS release will be Java 17, scheduled for release in September 2021.
Three releases into the new cycle seemed like a good time to touch base with Georges Saab, VP of the Java Platform Group at Oracle and chairperson of the OpenJDK governing board, about the impact of the faster Java release cadence on the developer community and his own team at Oracle.
We last talked about the new release schedule back in 2017 when Mark Reinhold [chief architect of Oracle's Java Platform Group] publicly proposed the idea. But you had already been laying the groundwork with Java 9. You said at the time that you felt "the time is right for the Java ecosystem to make this work." Were you right about that?
Back before we started this, before they actually experienced it, people were understandably skeptical. But in the past few months, especially since Java 11 came out, the developers I talk to are saying that, once they did the hard work of getting up to Java 9 , they were able to move forward with almost no difficulty at all. Java 9 was the last of the major disruptions. For people who have something running on Java 9, moving to 10, 11 and 12 are small steps that are akin to what we used to call "minor releases."
But people still have to make their way from Java 8 to Java 9 to experience all this easy-upgrade goodness.
A couple of years ago, I heard a lot of people saying, well, maybe Java 8 is good enough, and we should just stay on that forever. But now I hear from a lot of people who are very excited about the roadmap we have, because they're seeing concrete evidence on a regular basis that we're making good on that roadmap. The things we're talking about -- Valhalla, Panama, Loom, Metropolis -- are coming into releases. Those projects are exciting, and they understand that getting on a modern release train is going to put them in a great place to take advantage of those things as they come out.
So, you'd say the new release cadence is achieving the goals you originally had for it?
You have to keep in mind what our goals are, and where we were coming from when we decided to do this. In the past, we would work on one of these major releases for two to three, even four years. And we would have a bunch of changes and improvements that landed as a major, disrupting release, which was very hard on everyone. What we've done is found a better way of improving our processes and the way new versions of the spec are revved, so that we can get those changes out in smaller chunks to people much more rapidly. What this is really about is making sure we keep Java relevant and that we're able to deliver functionality into the hands of developers quickly.
This is a big change, and I think lots of people are still having to stop and remind themselves that the latest release isn't going to be this massive, disruptive challenge. Do you think your decision to rev the major release number each time has caused a bit confusing in this regard?
I do, actually. Because we chose to streamline the numbering, eliminate "major releases," and not use, say 11u20, 11u30, 11u40, there is that automatic expectation that these are major disruptions coming every six months. But, of course, our intention is the opposite. We're providing small, evolutionary steps forward and incremental change that is easy to adopt but getting you the functionality you need. And we're continuing to evolve the language and platform so that Java continues to be relevant for another two decades.
But another advantage with this approach, which I've heard you talk about, is how these incremental changes often will constitute pieces of a bigger picture.
A really good example of that is Switch Expressions [which was included in JDK 12]. People are very excited about this feature. It's small, it makes your code easier to write, and more importantly it makes your code easier to read. We're including it as a preview so we can get feedback and make sure it's as good and solid as it can be when it's finalized, and informed by real, live use cases.
But if you look at JEP 325, way down at the bottom of the page, you'll see under "Dependencies" it says "Pattern Matching (JEP 305) depends on this JEP." It's not an end in itself, but a step toward a much larger and more ambitious improvement to Java. This is something that we would have done previously in one of those large, disruptive releases, all at once. The faster cadence allows us to do this kind of thing in small improvements across multiple releases.
But the faster release cadence also makes it easier to leave features out of a release, as you did this time around with Raw String Literals.
That's right. This is a good example of a key advantage of this model. If this had been a two-to-three-to-four-year major release, the pressure to keep it in would have been extremely high, because if it didn't, you'd be waiting for it for years. The stakes of leaving it out were much, much higher.
How has your team adapted to the faster release cadence?
They've adapted wonderfully. Having the predictability of knowing when features come out means we can reduce the overhead of producing them tremendously. We're not constantly having to shuffle different schedules, planning and re-planning when a feature drifts out of scope. So, for the team, it has been quite liberating.
Any doubters in the bunch?
It has been a bit of a cultural shift. Some people on my team were apprehensive about [the faster release cadence] before we moved into it. But now they've seen how it's actually making their lives much easier. Our end game for releases has never been calmer than it has been in the last year and a half. And people love that.
One thing people worried about before we got started was what we would do if we had a release where there wasn't anything ready -- no new JEPs came in? We went through that thought experiment before we introduced the six-month releases. And we realized pretty quickly that the minor updates we did in the past were effectively on a six-month cadence. They sometimes involved quite significant implementation changes or improvements, but they always included a bunch of bug fixes. So, we decided, even if we don't have any JEPs come into a release, we're always going to have somewhere in the neighborhood of 1,500 to 3,000 bug fixes. That in and of itself is worthy of a release.
When the new six-month cadence was announced there was some talk about "release fatigue." Have you seen that in the Java community?
It's sort of like asking, if your kids had Christmas twice a year, do you think they'd experience "Christmas fatigue?" The parents might, I guess. What I'm hearing people say now is that they are seeing so much evidence that updating to 9 and finding the move to 10 and 11 so smooth, they're excited about the new cadence and what's coming down the pike.
Posted by John K. Waters on March 26, 20190 comments
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, 20190 comments
The JCP Expert Group in charge of JSR 107, the specification for the Java Temporary Caching API, better known as JCache, recently submitted the maintenance review for JCache 1.1.1. This is just an errata release and not particularly newsworthy, but it marks something of a milestone for the longest running spec request in the history of Java. And it seemed like a good time to talk with its co-author.
Greg Luck is the CTO of Hazelcast and co-spec lead on JSR 107 with Oracle software architect Brian Oliver, who works on the Coherence team. Hazelcast develops, distributes and supports a leading open source in-memory data grid (IMDG), also called Hazelcast. Oracle was the original submitter of the JCache spec, and Luck is the creator of Ehcache, a well-known version of that spec.
How did you become involved with this JSR?
I was doing some work for a big online share-trading company at the time, and they wanted me to create a JCache adapter for Ehcache. I tried to do it, but the spec wasn't complete, so, I told them that, and they said, well, can't you do some work on the spec? And that's how I got roped into it, though I didn't really have time to work on it until I was at Terracotta.
When you started working on caching technologies back in the day, it had sort of bad reputation, didn't it?
At the time, people felt, in the Java community, very, very strongly, that caching was a dirty trick, that if you were to do that, there was something wrong with your architecture. It was the very strong prevailing view. One of the reasons engineers felt that way is that caching is very seldom black and white. It's probabilistic in nature, a bit like AI techniques using statistics.
But it's a completely different era now. People came to realize that anything done at Web scale must be done with caching. Every single cloud provider now has, as a standard component, a caching service along with the different implementations they provide. It's now well understood that caching has a purpose.
Do I have it right that JSR 107 was the longest-running spec request?
It was, but I think it was worth the wait. It's now considered one of the most -- if not the most -- successful stand-alone specs, ever.
How do you measure that success?
In terms of the number of implementations. There are 13 now, and we recently saw IBM implement JCache for its eXtreme Scale API. It really has been enormously successful. The spec has been implemented now by so many people that it's a standard that can just be used and leveraged in all these different products.
One of those implementations -- Blazing Cache -- was created by the travel Web site Trivago. These guys actually created a cache for their own purposes for that huge site.
At Hazelcast we actually have some of our biggest customers using us for our JCache. I get in trouble if I say who these companies are.... In fact, our biggest production cluster in the world, which is an online store that services billions of people, uses us for our JCache.
At this point there is only one significant implementation in the caching world that has not adopted it: Pivotal's Gemfire, and its open source variant, Apache Geode. I don't entirely understand why. The guys tend to be Spring-centric, and Spring itself has got good support for JCache. I guess you could say that JCache is ubiquitous with one exception.
What's going on with this release?
It's a self-serving comment, but I have to say that 1.0 was pretty well done. There were a few things found in 1.1. And now 1.1.1 is really just an errata release. This thing is pretty mature and stable, and I think it's enormously important to the Java community. It's been out there now for four years, it can be used as a foundation.
I understand that you'd like to see JCache implemented in Jakarta and MicroProfile, both of which are now at the Eclipse Foundation.
If you look at the surveys, JCache is the number one thing people are asking to be included in the Jakarta spec. And I've been personally lobbying the MicroProfile people to add caching, because it's incredibly important. We [Hazelcast] joined MicroProfile, and I wrote a specification to include JCache in MicroProfile. Tons and tons of Hazelcast gets used with microservices, so it's clear to me that having the framework directly support it would be great. But the MicroProfile guys don't currently see caching as a priority, so nothing has happened yet. Jakarta has become energized under the stewardship of Eclipse, so we'll see what happens there.
What's your pitch to the MicroProfile folks?
With microservices, you take a monolithic application and you break it into pieces. You essentially have a container that you started from Java, and it's probably running in Docker. If it's a busy microservice, you'll want to scale it. With microservices, you can easily scale just the bit you want. Let's say you started with three and you want to scale it up ten or fifteen. If you pop an in-memory data grid (IMDG) in there, it can run in process, so it's in each of the nodes. And then, as you scale the thing, the IMDG scales along with it, literally.
So, IMDGs, through their embeddable nature in Java, are the perfect fit for microservices. If someone wants to build a microservice, if they use JCache, they can use their IMDG and they can use a first-class annotations library that's in JCache, and they can swap the IMDG at a very low cost.
The MicroProfile people are just leaving this as something the implementor has to deal with. But having caching as a first-class citizen inside the MicroProfle framework would be very useful for a lot of people.
And yet, one of the relatively unique qualities of JCache is that it's a stand-alone spec.
That is true. Because it's one of the few stand-alone specs, people can very easily just plug it in and use it. If you use a caching API in your code, if you use JCache, you can swap out implementations at no cost, which is always the promise of these things.
Posted by John K. Waters on February 13, 20190 comments