Oracle's decision to shut down the java.net and kenai.com collaborative Web sites by next April has the Java community -- especially the Java EE community -- buzzing. The company announced plans last year to move the content and services of Kenai to java.net, but now says both portals will be "sunsetting" on April 28, 2017.
Java EE evangelist Reza Rahman, in a letter to members of the Java EE Guardians, called the decision "tragic," and "very troubling for Java EE."
"The problem is that Java EE JSRs and GlassFish itself is heavily reliant on java.net," Rahman wrote. "Oracle so far has not announced a transition plan and is basically asking everyone with java.net projects to do any migration on their own. This is especially troubling since our current projections show Java EE 8 scoped work is highly unlikely to be delivered by April 2017 -- which raises the question of how Java EE 8 will be delivered at all."
Oracle moved the so-called community content of the sites to the community.oracle.com Web site last fall, and insists that this portal will be a "much better platform for collaboration" because of new spaces provided for Java Champions, Java User Group (JUG) leaders, and the Java Community Process (JC). But for future code collaboration, Oracle is pointing developers to other social coding platforms.
"As for the forge half of the site, there has been a tremendous amount of innovation in the code collaboration space, and developers have migrated to a small set of very popular platforms like GitHub," the company said in a statement. "In light of this, we felt we could contribute more value to the community through other programs and by investing in GitHub, because our community is increasingly active there."
The Java community has been talking about the shortcomings of java.net for some time, but what some see as the abrupt termination of these two portals has been unsettling.
Ondrej Mihályi, a Java EE trainer, consultant and senior services engineer at Payara Services in the Czech Republic, allows that java.net and Kenai haven't kept up with modern trends. It makes sense for Oracle to reconsider their roles in the Java ecosystem, he said in an e-mail, but the abruptness of the shutdown announcement makes him question the company's motives.
"The way Oracle announced the plan to shut them down makes many members of the community wonder whether it was carefully planned or just a desire to cut costs and shut down projects they cannot monetize," he said. "The latter is more likely, as even many people from Oracle, who stand behind existing projects hosted on java.net, don't yet have a plan how to migrate their projects to somewhere else."
Oracle underestimates the value of these collaboration platforms for growing community involvement, Mihályi said, and perhaps the value of community involvement itself.
"There are many valuable resources on both java.net and kenai.com, including project sources and documentation, forums, blogs, and other sorts of information, such as JUG profiles and documents," he said. "[Oracle's decision] poses high risk that a certain amount of that information will be lost after the shutdown of both sites. We can remember the losses from recent history, when all sun.com sites were migrated under Oracle domains, but not all links are properly redirected to date. They say the Internet has very good memory, but it can also forget badly when a site goes down completely."
Werner Keil, DevOps Build Manager at Visteon Corp., is a member of the JCP Executive Committee, spec lead on JSR 363 and an Apache committer. He likens Oracle's decision to shutdown the forge sites with its decision to enfold the JavaOne developer conference within its own OpenWorld event.
"The Java community becomes less visible in a giant pool of various products and technologies from Oracle DB to Fusion Middleware or Siebel, just to name a few," he said in an e-mail. Fully assimilating Java as a product rather than supporting an open, community-based project is "consistent with Oracle's approach," he said.
"As other portals (for example, Google Code) faced before, it seems, Oracle wants to save the cost of maintaining its own separate forge and project hosting for Java," he said.
Both Werner and Mihályi are members of the Java EE Guardians, an independent, volunteer advocacy group formed a few months ago to support enterprise Java. Mihályi sees the java.net shutdown as especially threating to Java EE.
"The important fact to point out here is that java.net has been a standard place to host all the official resources for most Java EE JSRs, including project sites, history of public communication on mailing lists, tracked issues, sources of the reference implementations," he said. "If java.net was shut down right now, it would practically mean death to Java EE, or in a better case, a hibernation lasting for many months. We as Java EE Guardians intend to keep reminding this fact to Oracle, the JCP board, and JSR specification leads and actively offering our cooperation in finding a new home and in migration for all JSRs and related projects. We certainly want to make sure that no valuable resources are lost and that the new tools and hosting is even more appropriate than current solutions."
"In the end," he added, "if we are successful, we can all benefit from making the Java EE process more transparent and accessible to an even wider community. There is always a room for improvement in the Java EE JSR processes (licensing issues, accessibility to TCKs and certifications -- just to name a few). And we all hope that we are able to contribute to overall openness of the platform in order to foster cooperation and standardization."
Posted by John K. Waters on June 8, 20160 comments
The recent decision by a federal district court jury that Google's use of 37 Java APIs in the development of its Android OS was a "fair use" of that technology and did not infringe on Oracle-owned copyrights came as a relief to the developer community, generally speaking, if a temporary one. The reaction of Josh Juneau, a Chicago-based app developer, blogger and author, was typical:
"I think this is a win for the developer community," Juneau said in an e-mail. "APIs are different from fully functional and completed applications or products. Many of us developers utilize open sourced APIs every day, and it would be a huge burden if we had to worry about licensing, etc. That is one of the reasons we use and develop open source software: so that others can make use of it as they see fit."
Gartner analyst Mark Driver has been a vocal critic of "the absurdity of Oracle's case" for some time. He reiterated his position in an e-mail that "copyrighting APIs is ridiculous and threatens innovation across the entire industry." He doesn't love the fair use argument, but he allows that it effectively addresses the mistake the court made with the earlier decision.
Oracle is going to appeal the latest decision, of course, so this story -- this long, long story -- has a few chapters left. But in the telling of it, says former Oracle Java EE community evangelist Reza Rahman, a larger point is being lost.
"I think both sides in this case are wrong," Rahman told me, "because neither side is serving the interests of developers."
Rahman, as we reported earlier, was the driving force behind the recently formed Java EE Guardians, a group of volunteers committed to supporting enterprise Java. He left Oracle earlier this year and now works as a consultant with CapTech Consulting.
"These guys should be working together and providing a standard API that Java developers can rely on without having to hitch their wagons to either Oracle or Google," Rahman said. "That would be the right thing to do. That's what Sun Microsystems wanted to do when it was the steward of Java. And that's what these two companies would be doing if they truly cared about developers. I see only self interest in all of this."
But Rahman has what I would call mixed feelings about the copyrightability of APIs.
"If I create an API, it should be within my rights to copyright it," he said. "Fair use, which is always judged on a case-by-case basis, acknowledges that sometimes there's a greater purpose than that served by copyright, and that should be accommodated also. In a perfect world there is no IP, and yet, when you create value you should be able to monetize that. This as a very slippery slope we're on right now."
To be clear, U.S. District Judge William Alsup's original ruling that the Java APIs at the center of the lawsuit were not subject to copyright was overturned on appeal, and the U.S. Supreme Court refused to hear Google's appeal, which effectively means that APIs are copyrightable. Historically, APIs have not been protected by copyright, but Oracle has argued that the "structure, sequence and organization" of the API packages in Java are sufficiently complex to merit protection.
"It's time to leave the bickering and uncertainty that has been hovering over the Java community behind," Rahman added, "and let's arrive at an API that moves the standard forward."
Amen to that.
Posted by John K. Waters on June 6, 20160 comments
Containers offer a number of advantages over traditional virtualization software, but easy visibility isn't one of them. Modern modular application architecture has, in fact, created a kind of "black hole" of complexity swarming with packages and dependencies developers can't readily sort out.
It's no surprise to see a growing number of container scanning products emerge to address this problem, but the latest entry into this market, JFrog's newly announced Xray, promises unprecedented visibility into the contents of software components, which the company calls "radical transparency."
JFrog CEO Shlomi Ben Haim described his company's fourth major product release as a one-of-a-kind tool that will give organizations an unparalleled level of understanding about all their container images, software packages and binary artifacts.
"Xray will not only tell you that you have a security vulnerability or a licensing issue," he told ADTmag, "it will also provide you will a full graph of all dependencies. It tells you where you are exposed and how your Ops environment is suffering from this specific software package. You have the chance to zoom in and magnify a vulnerability, security, or license issue and put things on hold before blessing a production environment."
Xray's ability to provide this kind of impact analysis is the product's key differentiator, Ben Haim said.
A fully automated platform, JFrog Xray comes with a REST API that supports integration and automation with an organization's continuous integration and continuous delivery (CI/CD) pipeline, and allows other inspection and security tools to fit into the full build-to-production automated flow, Ben Haim said
It also includes notification technology from VersionEye, a Mannheim, Germany-based start-up that provides a system for tracking open source libraries and alerting developers in real time to security vulnerabilities, license violations and outdated dependencies. VersionEye technology monitors more than a million open source projects on a daily basis, said company founder and CEO, Robert Reiz, in a statement.
"Integrating the VersionEye technology with the JFrog platform creates an unparalleled capability for deep understanding of the quality and provenance of the software components organizations depend on," Reiz said.
The tool also integrates with other vulnerability and license compliance databases, such as Black Duck and WhiteSource.
Xray integrates tightly with JFrog's binary repository manager, Artifactory, which stores binary artifacts and the metadata that describes them in a defined directory structure. Artifactory was one of the first cloud-based binary repository managers. The company also makes Bintray, a distribution-as-a-service (DaaS) platform designed to give development organizations full control over how they store, publish, download, promote and distribute their software.
The software management and distribution tools provider unveiled Xray at its annual swampUP user conference, under way this week in Napa, Calif. The company also announced at the show the availability of Artifactory running as a SaaS application on the Google Cloud Platform, as well as a collaboration with Atlassian to integrate that company's Bitbucket cloud-based DVCS hosting service and the JFrog platform.
JFrog expects to ship Xray in early Q3.
Posted by John K. Waters on May 24, 20160 comments
Much of the press around this year's Google I/O event focused on the company's day-one consumer app-economy announcements, but there was plenty of news for enterprise developers in the opening keynote.
The most immediately relevant announcement was the launch of Preview 1 of Android Studio 2.2. The upcoming version of the official IDE for Android app development includes a rewritten layout designer, an automated test recorder, a Firebase plug-in, and the latest updates of JetBrains' IntelliJ IDEA and CLion development environments, on which the IDE is based.
The most welcome upgrade (judging from the applause the announcement received) is the new test recorder feature. Based on the Expresso testing framework provided by the Android Testing Support Library, the new tool allows devs to test an app manually while recording the interactions in Espresso code. That code can be played back across a number of platforms, including Google's Cloud Test Lab, to re-test the UI over and over again.
The new layout designer also drew its share of oohs and aahs from the crowd. Designing the UI for an Android app can be challenging, given the variety of screen sizes and resolutions the developer must accommodate. The rewritten designer calculates the screen positioning and sizing (constraints), which means the UIs can resize automatically for different screens.
Android Studio 2.2 also introduces support for the NDK-Build and Cmake build tools used for creating C++-based apps.
Versions of Android Studio 2.2 for Windows, Mac, and Linux can be downloaded now from the Canary Channel Page.
Google also announced that it will be adding features to its Firebase back-end-as-a-service product, which it acquired in 2014. The company plans to integrate Firebase fully with its existing products and services, and says that many previously paid-for features, such as Cloud Messaging, will be free going forward. The new Firebase is a single SDK that provides analytics, remote config, crash reporting, test lab, notifications, dynamic links, invites, AdWords and AdMobs. One notable new feature, Crash Reporting, provides reports to help diagnose and fix problems that show up in Android or iOS apps. The feature is based on Firebase Analytics, which allows developers to see information about how and where an app is being used.
The company also made several announcements around the third (and probably last) preview release of Android N. This version of the OS is shaping up to be very VR-centric, with support for the new Daydream system, announced at the show. The new OS will also support the advanced Vulkan graphics API, and and bring split-screen multitasking and picture-in-picture video playback. And there's a new JIT compiler designed to improve performance and take up less storage space.
The "N" in Android N is just a placeholder, of course, and Google has invited the public to help name the next version. ("Namey McNameface" has been disqualified as a potential option.) I'm guessing they'll be looking for something sweet, given the previous naming scheme. For what it's worth, I'd go retro with something like Abba-Zaba or Pop Rocks.
Posted by John K. Waters on May 19, 20160 comments
The Java EE Guardians this week unveiled a public draft of their charter, and it's worth reading for anyone interested in the future of enterprise Java. The charter makes and supports the argument that Java Enterprise Edition (Java EE) continues to be essential to the long-term health of the Java ecosystem, and then it lays out compelling evidence that Oracle is "conspicuously neglecting Java EE."
A big chunk of that evidence comes from data analysis conducted independently by Josh Juneau, a Chicago-based app developer and author. (He wrote JavaServer Faces: Introduction by Example and Java EE 7 Recipes.) Earlier this year, Juneau began tracking "a decline in activity" around Java Specification Requests (JSRs) aimed at Java EE 8 for which Oracle maintains the lead.
"I had noticed activity declining late last year, but it wasn't until other members of the community pinged me in January to express serious concerns about a slowdown they were seeing that I really sat up and took a hard look," Juneau told me. "That's when I saw a clear drop in activity on these JSRs starting back in October. And then I started compiling the numbers."
Juneau chronicled his analysis in a long blog post that I highly recommend. He focused on JSR 372: JavaServer Faces 2.3; and JSR 368: Java Message Service 2.1. Juneau serves on the expert group for JSR 372 and JSR 378: Portlet 3.0 Bridge for JavaServer Faces 2.2. Many of the charts he included in that blog post to illustrate his findings appear in the Guardians' charter document.
"It seems as though Oracle may be shifting direction with their enterprise technology toward microservices and the cloud," Juneau said, "which is the way things are going nowadays. The problem with that strategy is that most of the ecosystem for the cloud, and even microservices, relies completely on Java EE technology. This really should be a concern to the Java developer community as a whole."
The Java EE Guardians, a group of volunteers committed to securing the continuing evolution of enterprise Java, formally announced their organization in March, though many of the group's members had been meeting for several months over concerns about Oracle's seeming lack of commitment to the upcoming Java EE 8 release.
Juneau has been a part of that conversation for some time, and he joined the Guardians to continue it at another level, he explained. "I guess my primary goal is to get a clear answer from Oracle about the future of Java," he said. "And if it turns out that Oracle isn't interested in helping to evolve those JSRs that are a part of Java EE 8, I'd like to explore the possibility of seeing those opened up so that the community and other organizations can take them over and move them forward, because they are so important to the entire ecosystem."
At least some of the heat that sparked the formation of the Guardians was generated when the head of Oracle's Java EE group, senior vice president Cameron Purdy, left last year amid rumors that Oracle was thinning its Java evangelist ranks. Other Java execs followed, including Reza Rahman, a former Oracle Java EE community evangelist who has been something of a driving force behind the Guardians.
I think it's worth noting that Juneau, Rahman, and all the Guardians I've spoken with to date give Oracle credit for being a good shepherd of Java over most of the past five years, and applaud the work of of the Oracle spec leads in general. (Juneau gave a shoutout in his blog post to the spec leads for JSR 372.) Their current concerns, they have said, arise from recent developments.
The Java EE Guardians maintain a public Google Group for open discussions of their concerns and activities. And they post regularly to Twitter with the handle @javaee_guardians.
Posted by John K. Waters on May 6, 20160 comments
It's official: Jenkins 2.0 has arrived. Available today, this is the first major release of the open source continuous integration (CI) server in 10 years, and the excitement surrounding it is palpable. (Sorry, that was my Apple Watch telling me to stand up -- again.)
But seriously, this truly is an event. After 655 weekly releases, the once-controversial CI server has evolved into a continuous integration/continuous delivery (CI/CD) system that provides a flexible way to model, orchestrate and visualize the entire software delivery pipeline.
"Pipeline" is the key word here -- or rather "pipeline-as-code." With this release comes the first officially supported implementation of a domain-specific language (DSL) for the coding of pipelines for continuous delivery. The new Pipeline plug-in is designed to help Jenkins users model their software delivery pipelines as code that can be checked in and version-controlled along with the rest of their project's source code.
"Probably one of the most important changes in this release is that Jenkins can now understand and model a delivery pipeline, natively, which it couldn't do before," Jenkins community leader Tyler Croy told me last week. "For me as a practitioner and Jenkins administrator, the out-of-the-box defaults we've changed in this release are also important, especially for new users. New users of Jenkins are going to find it much easier to get set up with the tools they need, and Jenkins will be more secure out of the box."
Croy is a Jenkins evangelist and community manager at CloudBees (the chief commercial supporter of Jenkins), which means he gets to work on Jenkins full time. He's been a leader in this community since before the fork from Hudson, so he's seen most of its evolution. He told me that, among other things, Jenkins 2.0 represents some fundamental rethinking at CloudBees -- and by Jenkins creator Kohsuke Kawaguchi -- about how the CI/CD server is going to be developed going forward.
"This was the first time we've had a parallel branch of development -- literally, on Git -- to work on big features," Croy told me. "Kohsuke has been a big proponent of the agile development concept and getting changes out to users as quickly as possible and getting feedback. But it's been hard to step outside that release process and think about bigger initiatives we could tackle to improve Jenkins over the next five to 10 years. Incorporating some of the UI changes and improving the getting-started setup to make the out-of-the-box experience better, for example, were things we developed over the past five or six months in parallel with the weekly release cycle. We have the ability now to experiment, try new things, and take on bigger initiatives that are challenging and time consuming in that separated little space of Jenkins development."
Storage plugability improvements are at the top of the community's to-do list, Croy said. No committers to anything yet, but this is the type of project that can now be accommodated by this parallel Jenkins development process for bigger releases.
Continuous integration has almost become a default in the standard software development stack, Croy observed, and continuous delivery is heading in that direction, too.
"There was a time when source control management wasn't part of the stack," he said. "Now it's standard to use Git or Subversion, and if you don't, people look at you like you're crazy. The same is true now for CI, and the direction the industry is moving tells me that CD is going to become standard part of that stack, too. People are saying, great, you can build and test your software, but how do you deliver it to your customers? It's just a matter of time before CD is standard in the stack, too."
"My personal goal," Croy added, "is to make Jenkins vastly more usable and much better documented and easier to adopt by 2016. This is something that we've started to do in Jenkins 2.0, and I plan to continue focusing on that comprehensive user experience."
A detailed overview of the Jenkins 2.0 release is available on the Jenkins Web site. And there's some great documentation ("Getting Started with Pipeline") online.
Posted by John K. Waters on April 26, 20160 comments
The big news in the evolving container ecosystem this past week was Mesosphere's announcement that it will be open sourcing its flagship Data Center Operating System, rebranded as DC/OS. (The company will also offer a commercial Enterprise version.) Among the long list of companies partnering with Mesosphere on DC/OS beta is a startup called Avi Networks, which got my attention at the Container World 2016 conference.
Started by former Cisco execs, the Sunnyvale, Calif.-based company emerged from stealth mode in December 2014 with the aim of delivering an application services platform fully implemented in software. The Avi Vantage Platform provides an alternative to legacy application delivery controllers (ADCs). It comprises the Avi Controller and distributed "elastic micro-ADCs" called Avi Service Engines, which are distributed across the environment to deliver services close to the applications. The platform's virtual engines perform Layer 4-7 functions (transport, session, presentation, application), which puts the company in competition with such established providers as F5 Networks, Citrix Systems, A10 Networks and Radware. Avi execs announced the integration of the Vantage Platform with Mesosphere's then-commercial-only DCOS at the Container World conference.
I had a chance to talk with Avi's CEO, Amit Pandey, about his company and its efforts to modernize application services. Pandey, who has been working around the Layer 4-7 space since 1998, said he has seen very little change in the architecture of the upper layers of the OSI model.
"It sits so close to the application that it's really surprising changes haven't happened," Pandey said, "because the fundamental way applications are build and deployed have changed dramatically. We've gone through a couple of generations of change, in fact. We had three-tier applications, then the onset of virtualization led to significant changes, especially in the way apps were deployed, and more recently we have microservices, which fundamentally changes the architecture and the tools for building and deploying applications. And through all this change, the ADC has just sort of chugged along. It's a very sleepy industry."
Avi's founders, Umesh Mahajan, Murali Basavaiah and Ranga Rajagopalan, decided to wake up that sleepy industry with an architecture that mimics a software-defined networking (SDN) architecture, Pandey said, resulting in what amounts to software-defined ADCs and load balancing. But the founders also recognized that, to accommodate things like microservices, containers, and public clouds, the architecture would have to be distributed, with a centralized control plane, and the ability to, essentially, learn about deployments and traffic patterns and bring that learning back in a kind of feedback loop to facilitate things like elastic scaleout, remediation against attacks, and/or giving developers the ability to troubleshoot microservices.
"In this brave new world of modern applications, we need the ability to control and manage highly distributed architectures; to manage multiple clouds; and to give analytics, visibility, and feedback for a high level of elasticity," Pandey said.
In a nutshell, Avi is providing appdev teams with a software-defined system that delivers discovery, security, and load balancing services elastically, with centralized control and monitoring. And Avi's layer of infrastructure is so application-like it can be put into a container and deployed almost anywhere. "Our customers often tell us that we are more like an application than infrastructure," Pandey said. And that's really what our vision of networking infrastructure is. It should be part of your app, because then the level of visibility and flexibility you have is phenomenal. Why should your network services be a distinct and inflexible hardware box when you can actually containerize it?"
Posted by John K. Waters on April 25, 20160 comments
To describe the 2.0 release of the Jenkins continuous integration (CI) server as long-awaited would be the understatement of the decade -- which is literally how long Jenkins has been a 1.0 release. Really. Ten years.
"I don't know if it's the longest 1.0 release in history," CloudBees CEO Sacha Labourey told me during a recent visit to Silicon Valley, "but it's got to be close."
Technically, Jenkins has been around since it was forked from the Hudson CI back in 2011. Hudson was launched by Sun Microsystems in 2004. After Oracle acquired Sun, the company announced that it would be migrating the project to its java.net infrastructure and trademarking the Hudson name. The community objected to this move, voted to rename the project and moved the code to GitHub. Shortly thereafter, Oracle surprised the community by contributing the Hudson code, domain name and trademark to the Eclipse Foundation.
Kohsuke Kawaguchi, who created Hudson and instigated the Jenkins fork, became an elite developer and architect at CloudBees, and he's been a part of the community throughout the evolution of this technology. The open source, Java-based Jenkins CI server has been updated almost on a weekly basis for many years. Along the way, it has been evolving from a pure CI server to provide continuous delivery, as well.
"A lot of people still think of Jenkins as CI only," Labourey said. "But the teams have done a lot of work around Docker, pipeline support, usability -- so much work has happened in the last 12 to 18 months, in particular, that it's important to signal that this is not the good old Jenkins you knew five years ago."
CloudBees now refers to the Jenkins CI/CD server as an automation server, and many of the changes in version 2.0, the alpha build of which was recently released, reflects this evolving identity.
"People ask me, what is the competition for Jenkins," Labourey said. "The real competition for Jenkins is companies still doing everything manually. It's a tough culture to change."
Among other things, this release will bring the concept of "Pipeline as code" to Jenkins. The new Pipeline plug-in introduces a domain-specific language (DSL) designed to help Jenkins users model their software delivery pipelines as code, which can be checked in and version-controlled along with the rest of their project's source code. Users will be able to define simple and complex pipelines through the DSL and easily share pipelines among teams by story common "step" in shared repositories. (There's a great description with diagrams on the Web site.)
Jenkins 2.0 also comes with a buffed up setup and UI improvements. And Labourey emphasized that Jenkins 2.0 will be 100 percent backward-compatible with existing Jenkins installations.
"There will be no reason for people not to upgrade," he said.
CloudBees, which had been known since it was founded in 2010 primarily as one of the few providers of a Java-based PaaS, refocused on Jenkins in 2014. The company was an early supporter of the CI server and continues to be its leading commercial supporter.
Earlier this year the company rolled out the first-ever Jenkins-based CD-as-a-Service (CDaaS) platform. Last year the company combined its Jenkins Enterprise and Operations Center products into a single platform.
Details about the Jenkins 2.0 release are available now on the company Web site.
Posted by John K. Waters on April 12, 20160 comments
The list of Java evangelists exiting Oracle got a little longer this month when Reza Rahman announced that he would be leaving the company. But Rahman is not going quietly. In a personal blog post, he stated that he left because of his growing skepticism about Oracle's stewardship of enterprise Java, which he said was "independently shared by the ever vigilant Java EE community outside Oracle."
"As an evangelist, your entire existence depends on trust from the community," Rahman told me in an interview, "but I found I could not give the community straight answers about what Oracle is doing. In the end, I could not reconcile this."
And he couldn't leave it alone, either: Rahman and members of the community he served have joined forces to form the Java EE Guardians, a group of volunteers committed to supporting enterprise Java where they believe Oracle is falling down on the job.
The group has been meeting informally behind the scenes for a while, Rahman said, but is now formalizing the organization and going public with a Google Group (Java EE Guardians) and a Twitter handle (@javaee_guardian). It's still early days, but Rahman said to expect vision and mission statements, soon.
About 100 people have joined the Java EE Guardians as of this writing. The group's immediate plan is to assemble evidence to support their assertion that Java EE is, in fact, critical technology that needs more attention from Oracle. We can expect "complete metrics," Rahman said. Once that's established, they'll go on to substantiate their assertion that Oracles investment in server-side Java is not where it should be. They also intend to raise awareness of their concerns among Oracle's customers.
"Java EE is very much key to the overall server-side Java ecosystem, and maybe even the health of Java itself," Rahman said. "Without core investments from Oracle into Java EE, there's a very large part of the ecosystem that will be severely weakened. I simply do not believe that Oracle is doing enough with the Java EE specs, and I do not think they are fulfilling their commitment to the community. And I am very much not alone in this belief."
Ultimately, he said the group wants to secure the evolution of Java EE, and they're volunteering their own time to do it -- to "fill the resources gap" they perceive now to exist. They're even prepared take over some Java Specification Requests (JSRs), Rahman said.
"The reality is, the Java EE community is the most vocal and the most passionate, and yet they are the people Oracle is not leveling with today," Rahman said. "It's a huge problem."
Rahman was an independent consultant before joining Oracle, and he's gone back to that work with CapTech Consulting. He has served on the Java EE, EJB, and JMS expert groups for the JCP. He implemented the EJB container for the Resin open source Java EE application server. And he co-wrote EJB 3 in Action (with Debu Panda and Derek Lane). To say that he's passionate about Java EE would be an understatement.
He saw the writing on the wall at Oracle, he said, when the head of company's Java EE group, senior vice president Cameron Purdy, left last year amid rumors that Oracle was thinning its Java evangelist ranks. Rahman described Purdy in his personal blog as "a gem in the executive ranks of our industry," and one of the reasons he signed on to evangelize Java EE at Oracle.
Rahman says the greatest challenge the Java EE Guardians face is getting Oracle to accept their work, to essentially acknowledge that there is a problem. "The bottom line is, if Oracle is not committed to server-side Java and not committed to supporting the EE space, then fundamentally, someone else needs to step in."
I contacted Oracle for comment, but the company had not gotten back to me at press time.
This is an unfolding story, so stay tuned.
Posted by John K. Waters on March 22, 20160 comments