Now that Oracle has handed off the technology formerly known as Java Enterprise Edition to the Eclipse Foundation, and the resulting EE4J Project will be developing that technology rebranded as Jakarta EE, I can't help wondering what will become of the group of enterprise Java jocks that, arguably, made this transition happen.
It was two years ago last month that the Java EE Guardians formally announced themselves, though its founding members had been meeting quietly for months before that. The group led a very public push to get Oracle to attend to its duties as steward of enterprise Java. Its members assembled and published evidence to support their assertion that Java EE is critical technology that needed more attention from Oracle. They launched a Web site, published a letter to the execs at Redwood Shores, followed up with a petition demanding action, and just generally became a thorn in Big Red's side.
Oracle might have offloaded Java EE on its own, eventually, but you've got to give the Guardians credit for throwing a spotlight on this issue and keeping it in front of the Java community.
Not surprisingly, the Guardians, themselves, have been wondering about their role in this brave new world. In fact, they recently took a vote on whether to stay together, disband or become an EE4J project. They voted overwhelmingly to keep on keepin' on.
I recently grabbed a few minutes between planes with the peripatetic Reza Rahman, senior architect at CapTech Consulting and former Oracle evangelist, who has been something of a driving force behind the Guardians, to ask him about the future of the group. He affirmed his personal desire to keep the organization together.
"I believe there will continue to be a valuable role for the Guardians to play in the ecosystem," he said. "Indeed, I had the idea to form a body like the Guardians while I was still at Oracle, long before the trouble with Oracle commitments to Java EE even began. The work on both the independent grassroots evangelism and activism fronts have been long-standing gaps the Guardians can help fill going forward."
The decision to keep the Guardians together was clear, but what the group will be called has yet to decided. In a recent vote, "Keep current name for now" edged "Rename to Jakarta EE Guardians" by one vote. (Rename to "JEE Guardians," "Java EE Evangelists" and "EE Guardians" came in a distant fourth, fifth and sixth, respectively.) The plan is to revisit the renaming question in a few months. Rahman says he has already secured "suitable domain names and Twitter handles."
"Honestly the renaming continues to be a hard pill to swallow for me personally," Rahman admitted in a discussion thread on the Guardians' Google Group site. "I've worked for so many years to advance the Java platform that the loss of the Java branding really feels like a tragedy. That's why not renaming or renaming to something ambiguous like JEE Guardians or EE Guardians continues to sound awfully good. [But] I really do think it's best to stand fully behind Jakarta EE and let a renaming reflect that support…."
How the Guardians will take part in the Java community in general and the Eclipse Foundation in particular is something the group is still working out. It appears that most members want to continue as an independent, grassroots Java EE advocacy organization. But for now, the membership has agreed to contribute to the Eclipse EE4J Project and the Eclipse MicroProfile Project as individuals, rather than as a group.
Meanwhile, Rahman said, the Guardians should avoid complacency, both in the long and short term. "Believe me I'd love to say Java EE is now out of the woods," he wrote, "but I just don't think that's true."
For example, the new standardization process for enterprise Java is still being worked out, he wrote, and the group should monitor the following:
- When will the transfer process to Eclipse actually finish?
- How open and effective are things actually going to be under this new standardization process?
- What does the roadmap for Jakarta EE in the next few years actually look like?
- How do we make sure this roadmap is what the community and industry actually wants vs. what vendors want?
- How do we know how well-funded this new technology will be? Are we so sure we won't slide right back to the lack of investment situation we ran into with Oracle? (While it is nice to think the community will pick up the pieces if vendors drop the ball, we all know reality in a competitive industry is not so simple.)
- How will EE4J and MicroProfile be aligned?
The Guardians are also in a unique position to do the following:
- Make sure vendors are implementing Java EE 8, MicroProfile and Jakarta EE in a timely fashion. We can do this by actively tracking progress and regularly publishing our findings.
- Hold vendors to higher implementation standards by routinely trying things out and publishing our findings. I think we should even compare implementations just like RebelLabs did.
- Make sure Java EE is well supported by tools, on the cloud, etc., by routinely trying things out and publishing our findings. Again, we could do comparisons here to keep vendors honest.
- When customers and users run into trouble with vendors, they should know they can come to us as a last resort and we will advocate collectively on their behalf.
- We all know the next bit of anti-Java EE FUD is right around the corner from the usual suspects. When this happens, we will need to act quickly and effectively as a collective.
"None of this is easy or pleasant but all of this is important to make sure Java EE remains relevant or competitive," Rahman wrote. "The only people who can really effectively and credibly do this is us."
Rahman said he is also expecting the organization's leadership to expand in the new world of Eclipse Jakarta EE. "I have, perhaps, been more of a central figure than I'd originally planned to be," he said. "And I know there are Guardians who are interested in stepping up with time and energy for this important work. This is something I welcome and expect to see in the near future."
Posted by John K. Waters on April 11, 20180 comments
The coming year is going to be an interesting one for Java pros. Java EE is now an Eclipse project. Oracle has accelerated the release cadence of Java SE. And modularization, via the Java Platform Module System, better known as Jigsaw, has finally arrived.
John Duimovich, IBM Distinguished Engineer and Java CTO, has been watching the evolving Java ecosystem for more than 20 years. He recently shared some of his expectations about the future of Java in this new environment.
2018 will be the year of Eclipse
With key projects like EE4J and MicroProfile now under its stewardship, the Eclipse Foundation will become even more important in 2018. Look for accelerated innovation as the open community becomes more involved in these and other Java-related projects. Developers will want to keep an eye on the Eclipse Foundation next year.
Convergence with containers will accelerate
As part of the broader effort to simplify development and management, containers and runtimes like Java will become more tightly coupled. They’ll be optimized together to enable seamless management and configuration of Java applications. Consistent memory management and easier wiring between Java constructs and containers will take hold so developers can leverage the benefits of containers and Java runtimes, which are essentially they’re another form of containers.
Kotlin will become the next hot language
Kotlin is poised to become a major force in the programming world. Kotlin’s concise coding syntax and interoperability with Java have already made it popular for many developers. Now, it has first-class support on Android, which is bound to boost its use for mobile. Look for it to gain even more ground in 2018.
New release model will drive faster innovation
Developers rejoice. The new six-month release interval for Java will mean more frequent changes and faster introduction of features. Look for enterprising Java shops to take advantage of these features and use Java to solve new problems and enter new areas. Large organizations will likely wait for the support of the long-term releases, but they’ll now have a clearer roadmap. Community support also has the potential to rally around popular changes in interim releases.
Serverless will begin a major reshaping of Java
Demand is growing for serverless platforms – initially driven as a consumption model but now expanding from simple, event programming models to composite flow-based systems. This innovation will continue as cloud developers want to shift their focus on the application, and not worry about servers. This means Java runtimes will need to be optimized and re-architected for a serverless world where fast start-ups and smaller footprints matter even more.
Posted by John K. Waters on February 14, 20180 comments
The Open Source Initiative (OSI) will celebrate its 20th anniversary on Friday, Feb. 2, and the global non-profit organization dedicated to raising awareness and adoption of open source software is gonna par-tay. By which I mean, the OSI has scheduled activities around the world this year to commemorate the event. (I'm hoping there will be snacks.)
Current plans include celebrations coordinated with the leading open source conferences, as well as stand-alone community-led events, the organization announced this week. As of this writing, those events include: All Things Open, Campus Party Brasil, FOSDEM, FOSSASIA Summit, Linux.conf.au, LinuxFest Northwest, Open Apereo, Open Camps, OSCON, Paris Open Source Summit and SCALE16x. In addition to official events, the OSI is also supporting volunteer organizers who want to host local, community-led celebrations in their own cities.
The organization is also inviting members of the open source community to share their stories. They're looking for personal anecdotes that "highlight the significant accomplishments and contributions that have made open source software a valued asset and community for your organization." Some are already posted. The OSI's anniversary Web site will also provide an opportunity for supporters to share events, videos, interviews, articles, timelines, and social media.
Also, as part of the celebration, the OSI is launching OpenSource.Net, which will serve both as a community of practice and a mentorship program. "The goal is to further promote adoption of open source software over the next twenty years as issues shift from open source's viability/value to issues around implementation and authentic participation," the Web site reads.
I received an e-mail from the OSI about this anniversary this week, and along with it, a little history lesson. I learned, for example, that the term "open source software" was coined at a strategy session held on Feb. 3, 1998, in Palo Alto, California. I looked around the Web and found several references to this moment in history, so it might very well be true. The OSI was founded "as a general educational and advocacy organization to raise awareness and adoption for the superiority of an open development process" that same month, the OSI stated. Shortly thereafter, the group set about drafting the Open Source Definition (OSD), which is considered by many a gold standard of open source licensing.
It's easy to forget that there were powerful forces arrayed against the open source movement back in the day. The OSI's initial mission was to counter "fear, uncertainty, and doubt" (FUD) generated by the shrink-wrap absolutists. But what started with Linux, Sendmail, Perl, Python, and Apache, and eventually, Java, has now won the imprimatur of, well, just about everybody. I was among the startled reporters who watched as Microsoft's then newish CEO, Satya Nadella, declared "Microsoft loves Linux!"
So let me say, happy birthday OSI. Save me a piece of cake.
Posted by John K. Waters on January 30, 20180 comments
Azul Systems unveiled a new support roadmap for users of Zulu Enterprise, the commercially supported edition of its flagship Java runtime. The roadmap lays out the company's plan to cope with what it calls "support cliffs" that will be created in the ramp up to Oracle's new faster release cadence for the Java SE Platform and OpenJDK.
Oracle's new, faster release schedule provides for a feature release every six months, update releases every quarter, and a long-term support (LTS) release every three years.
The accelerated cadence was greeted by the Java community largely as a positive development. But Scott Sellers, Azul Systems president and CEO, points out that, in the short run, the process of implementing this new schedule will leave two versions of Java without long-term support. If the next LTS release after Java 8 is going to be Java 11, Java 9 and Java 10 are effectively skipped. Java 11 is expected in September of this year on the new schedule. The next LTS version after that -- three years later -- will be Java 17, which gets released in September 2021.
"You almost need a decoder ring for all this," Sellers said.
Oracle has said that it will provide public updates for only six months after a given release has been made available. "What that means is, for a version like Java 8, which has been in the market for a long time and is by far the most widely used version of Java, come September 2018, public updates will cease," Sellers said. "We call this a ‘support cliff.' After that date, you either have to use an immature new release like Java 11 or continue using a version that will have more and more vulnerabilities that won't get a security update."
Azul plans to keep its customers from being driven off "support cliffs" by aligning Zulu Enterprise releases with Oracle's and OpenJDK's scheduled GA for all releases of Java SE, while also providing overlapping support coverage from one release to the next. The Zulu Enterprise LTS release will include bug fixes and security updates for a period of at least eight years from the GA date. The company is also offering Medium-Term Support (MTS) for certain Java releases, which enables practical use in production deployments of the new capabilities available in feature releases without having to wait for the next LTS release. The company will designate one MTS release per year in the years between LTS releases, and provide support, bug fixes, and security updates for 18 months past the GA date of the following LTS release. And there's also a Short-Term Support (STS) option for the remaining Java SE feature releases. STS support allows users the earliest access to new Java features with support and updates designed to allow a smooth transition to a newer JDK release.
"None of this is not a knock on Oracle, by any means," Seller said. "There's no doubt that the faster release cadence is good for Java. And there's also no doubt that maintaining backwards compatibility is a challenging thing that can limit the ability to evolve the platform on a rapid schedule. But the decision to break compatibility at will, from release to release, create challenges for users."
Zulu is free to download, use, and redistribute from the Zulu Community Web site. Azul provides support via Zulu Enterprise, a Java platform based on OpenJDK. The company also offers Zulu Embedded, a build of OpenJDK aimed at Java developers in the embedded systems and Internet of Things (IoT) space. Both editions are 100 percent open source.
Sunnyvale, Calif.-based Azul bills itself as the only vendor focused exclusively on the Java and the Java Virtual Machine (JVM). The company's Zing JVM is based on Oracle's HotSpot, a core component of Java SE. It's a "no-pause" JVM designed to eliminate Garbage Collection (GC) pauses, a long-standing challenge for Java developers. This pauselessness, which Azul calls "generational pauseless garbage collection" (GPGC), enables Java app instances to scale dynamically and reliably. Sellers, CEO has called GC "the Achilles heel of Java."
Posted by John K. Waters on January 30, 20180 comments
The predictions just keep coming! Honestly, I haven't seen this many tech-savvy industry watchers and execs ready to weigh in with their expectations for the coming year ... well ... ever. I think it speaks to the times we live in that so many of us seem to be focused on the future.
Among those execs is John Duimovich, Java CTO and Distinguished Engineer at IBM (and perennial attendee fav JavaOne keynoter and session leader). Duimovich has been working with Java for all of its 20 years, and he shared his predictions for the language and platform in the coming year via e-mail. Thought I'd pass them along.
Prediction 1: 2018 will be the year of Eclipse
With key projects like EE4J and MicroProfile now under its stewardship, the Eclipse Foundation will become even more important in 2018. Look for accelerated innovation as the open community becomes more involved in these and other Java-related projects. Developers will want to keep an eye on the Eclipse Foundation next year.
Prediction 2: Convergence with containers will accelerate
As part of the broader effort to simplify development and management, containers and runtimes like Java will become more tightly coupled. They'll be optimized together to enable seamless management and configuration of Java applications. Consistent memory management and easier wiring between Java constructs and containers will take hold so developers can leverage the benefits of containers and Java runtimes, which are essentially they're another form of containers.
Prediction 3: Kotlin will become the next hot language
Kotlin is poised to become a major force in the programming world. Kotlin's concise coding syntax and interoperability with Java have already made it popular for many developers. Now, it has first-class support on Android, which is bound to boost its use for mobile. Look for it to gain even more ground in 2018.
Prediction 4: New release model will drive faster innovation
Developers rejoice. The new six-month release interval for Java will mean more frequent changes and faster introduction of features. Look for enterprising Java shops to take advantage of these features and use Java to solve new problems and enter new areas. Large organizations will likely wait for the support of the long-term releases, but they'll now have a clearer roadmap. Community support also has the potential to rally around popular changes in interim releases.
Prediction 5: Serverless will begin a major reshaping of Java
Demand is growing for serverless platforms -- initially driven as a consumption model but now expanding from simple, event programming models to composite flow-based systems. This innovation will continue as cloud developers want to shift their focus on the application, and not worry about servers. This means Java runtimes will need to be optimized and re-architected for a serverless world where fast start-ups and smaller footprints matter even more.
Posted by John K. Waters on January 16, 20180 comments
Oracle and Alphabet Inc. subsidiary Google were back in court last week, adding yet another chapter to the long running saga of their conflict over Google's use of Java in its Android operating system. Oracle is appealing a 2016 finding by a federal jury that Google's use of 37 Java APIs in its Android OS constituted fair use.
Oracle filed its appeal in February with the U.S. Court of Appeals for the Federal Circuit. In that appeal, Oracle argued that the jury "reached a wrong result" because the district court "repeatedly undermined" its case and failed to allow the database giant to present evidence that would disprove Google's claim that Android was limited to the smartphone market, and consequently, didn't compete with Oracle. The court "eliminated one of Oracle's central arguments by precluding Oracle from showing all the markets where Android and Java overlapped," the appeal states. It goes on to claim that "Android supersedes Java in markets Java occupied before Android -- including TVs, cars, and wearables."
Adding a bit of drama to this new go ‘round are reports that Oracle is engaging in what Recode reporter Tony Romm called a "cloak-and-dagger, take-no-prisoners" lobbying effort in Washington that appears to be designed to damage Google's reputation. One of the sources for a recent story that appeared in Quartz, Romm reported, alleging that Google tracks the location of its Android users, even when location tracking is turned off, was Oracle.
There's a lot at stake here. Oracle originally asked for $9 billion in damages.
Here's a short-as-I-could-make-it summary of the long-running legal battle between the two companies:
- Oracle originally sued Google in 2010, claiming that, in developing its Android mobile OS, the Internet search giant infringed on patents associated with the Java Platform, which Oracle acquired when it bought Sun Microsystems Inc.
- In 2012, a 10-person jury serving in the Federal District Court in San Francisco ruled unanimously that Google had not infringed on Oracle's patents.
- Later that year, the presiding judge, U.S. District Judge William Alsup (who learned to write Java code to better understand the case), also ruled that the 37 Java APIs were not subject to copyright.
- In May 2014, a federal appeals court overturned that ruling, declaring that the Java APIs were protected under U.S. copyright law.
- What the appeals court found initially was that the declaration code in Oracle's API packages, which Google copied verbatim, was copyrightable. Google developed the implementation code independently, so it wasn't at issue. The court found that the Oracle code had not been merged with the functions performed by the code; that combinations of short code phrases, such as those used in the APIs, can be copyrightable; and the fact that the code serves a function does not preclude its copyrightability if, the as the court put it, "the author had multiple ways to express the underlying idea" at the time of creation of the code.
- In October 2014 Google filed a petition with the Supreme Court, asking it to review and reverse the appeals court's decision. The high court decided not to review the case, returning it to the district court.
- In May 2016, a jury ruled that Google's use of the Java APIs was allowed under the "fair use" provisions of the federal copyright law, and therefore did not infringe on Oracle-owned copyrights.
Posted by John K. Waters on December 13, 20170 comments
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 November 8, 20170 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 October 25, 20170 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 October 10, 20170 comments