In March we announced that ADTmag is participating this year in the very popular Live! 360 conference, scheduled for December 5-9 at Loews Royal Pacific Resort at Universal Orlando. This multi-conference conference comprises Visual Studio Live!, SQL Server Live!, Office/SharePoint Live!, Modern Apps Live!, TechMentor and now AppDev Trends 2016. We don't have the exclamation point in our title, but we're as excited as if we did.
We're especially thrilled to announced our keynote speaker: Reza Rahman. As regular readers of this column know, Rahman has been one of the chief drivers behind the Java EE Guardians and an expanding effort to encourage Oracle to give enterprise Java the attention it deserves and to preserve the overall interests of the Java EE community.
I first spoke with Rahman shortly after he left his position as Java EE evangelist at Oracle in March. "Java EE is very much key to the overall server-side Java ecosystem, and maybe even the health of Java itself," he told me. "Without core investments from Oracle into Java EE, there's a very large part of the ecosystem that will be severely weakened."
A lot has happened since then: the Guardians published their charter, launched a public website, and published a petition aimed at Oracle executives. Google won its "fair use" argument against Oracle's charge that it infringed on a copyright of 37 Java APIs. Oracle shut down the java.net and kenai.com collaborative Web sites. And another effort to support enterprise Java, the MicroProfile.io project, got underway.
And between now and our show in December: JavaOne, during which Oracle has promised to provide "a very well-defined proposal for the next version of the Java EE specification."
Rahman's keynote, entitled "You Are the Future of Enterprise Java!" couldn't be more timely. (Notice that he got into the spirit of the conference with his own exclamation point!) And I can't think of a better speaker to present it.
Rahman has been working with enterprise Java since its inception, developing on almost every major application platform, from Tomcat to JBoss, GlassFish, WebSphere, and WebLogic. He implemented the EJB container for the Resin open source Java EE application server, and he has served as a member of the Java EE, EJB, and JMS expert groups of the Java Community Process (JCP). He also co-authored EJB 3 in Action (with Debu Panda and Derek Lane), and contributes to a number of industry publications. He's also a winner of the JavaOne Rock Star Speaker award.
"Java EE remains one of the most important technologies for global IT," Rahman said in an email. "It has come a long way since J2EE and has grown to become highly community-centric. Indeed, the process of defining the scope of Java EE 8 was the most community-opinion-driven process in the history of the platform. In fact, it was the community that helped to smooth the many bumps along the road to Java EE 8 for the entire IT industry."
Rahman's keynote will tell that unique story, focusing on what's inside Java EE 8 and how it got there, and exploring the critical role Java EE and APIs currently play in maintaining the health of the entire Java and IT ecosystem. And perhaps most importantly, he will attempt to answer the question, What do we need to do now to move enterprise Java forward?
Our goal was to tweak the ingredients of an already great conference with dash of Java and some sessions specifically aimed at ADTmag readers, and I think we've succeeded. This is a show you won't want to miss. Find out more here.
Posted by John K. Waters on September 14, 20160 comments
The annual JavaOne conference, which kicks off on Sunday (Sept. 18), looks to be chock-a-block with sessions, workshops and keynotes, and I'm expecting significant news from the Oracle Java team and tons of third-party product announcements. One of the best components of this consistently great conference, in my opinion, is NetBeans Community Day, which focuses on what continues to be one of the industry's favorite open source IDEs.
As the no-frills NetBeans Day Web site puts it, "The NetBeans team, NetBeans Dream Team, and NetBeans community will share highlights of how the NetBeans ecosystem has evolved, the work that developers around the world are doing with NetBeans IDE, what's new and noteworthy in NetBeans IDE 8.2, and together we'll explore what's up ahead in the coming period."
The speaker lineup includes NetBeans community members from around the world -- from Serbia to Burkina Faso (a country I confess I haven't actually heard of). Two of my personal favs will be presenting: Arun Gupta, VP of developer advocacy at Couchbase and founder of the U.S. chapter of Devoxx4Kids, and the Father of Java himself, James Gosling, now applying his considerable experience to the challenges of writing software for an unmanned ocean robot at Liquid Robotics . There are some juicy-looking sessions on Java 9 and Jigsaw, open-source tools for teaching Java, so-called DukeScript, Big Data, MVC 1.0 and more.
One session that caught my eye is being presented by Gluon's Johan Vos (CTO) and José Pereda. The session, "Java Mobile and Embedded Development with Gluon and NetBeans," promises to show "how the flow between writing a Java application and deploying it on mobile and embedded devices is extremely easy with NetBeans and the Gluon plug-in."
Gluon is the company that stepped in to fill a serious mobile-development gap left when RoboVM was
acquired by Xamarin, which was then acquired by Microsoft. The end of development and distribution of that ahead-of-time (AOT) compiler and runtime library for Java was later announced on the RoboVM
Web site.
Gluon provides plug-ins for the leading Java IDEs (including, of course, NetBeans), that allow Java developers to build apps for Android and iOS using a single code base. In June, the company unveiled the Gluon VM, which it bills as a high-performance virtual machine that leverages the OpenJDK class libraries and supports Java 8 and 9 on Android and iOS. The Gluon VM can operate in three modes: interpreter, just-in-time (JIT) compilation and AOT compilation. The VM is the foundation of the company's Gluon Mobile and Gluon CloudLink products.
Gluon is run by serious Java Jocks, so I'd expect this to be a great session. Catch it and the other promising NetBeans sessions on Sunday, Sept. 18, in Rooms 102 and 104 in Moscone South.
Posted by John K. Waters on September 13, 20160 comments
In its ongoing effort to make its workings as transparent as possible, the Executive Committee (EC) of the Java Community Process (JCP) publishes the minutes of its meetings. The Aug. 9 minutes are online now, and though these kinds of documents tend to provide reliably dry reading, this one proved to be a real page turner for anyone interested in the future of Java EE. (Or would have been if it were, you know, printed on paper.)
A couple of things caught my eye: Anil Gaur, Oracle group vice president with responsibility for Java EE and WebLogic Server, reportedly gave a short presentation on Oracle's Java EE strategy. As recorded in the minutes, he talked about how enterprise programming styles are changing to focus on apps deployed in the Cloud via modular runtimes, and how "we," by which I'm presuming he meant Oracle, would like the future of Java EE to be "viable to the next generation of applications."
Elsewhere in the minutes, JCP Chair Patrick Curran reportedly talked about a meeting he'd had with Oracle execs "on the subject of relations between OpenJDK and the JCP." Curran reported that Mark Reinhold, chief architect of Oracle's Java Platform Group, "had argued that much of the process required by the JCP was duplicative and unnecessary, and that Mark had even suggested that Expert Groups added little value to OpenJDK's existing processes."
We've been hearing predictions like Gaur's that the future of enterprise Java is in the cloud for a while now, and I continue to hear about the uncertain future of the JCP. But felt the need for some elaboration, so I reached out to some Java EE mavens to see what they had to say.
EC member and London Java User Group leader Martijn Verburg attended that meeting (virtually). "I think Anil is echoing the overall market trend for cloud based applications and services, with a subset of that trend being microservices and serverless," he told me via e-mail. "That is, less and less applications will be developed for on premise, requiring the sort of transactions support and connectivity with traditional on-premise systems. For example, with today's Java EE you have standards for Batch processing, transactions, persistent messaging with JMS and so forth.... So that means Java EE needs to evolve and produce standards around service discovery, configuration, logging, JSON processing, and binding, etc., and be less about heavyweight messaging, transactions and so forth."
On the subject of the future of the JCP, he added that he expects it to be "alive and well for some time yet."
"I think the community at large wants to see standards around Java in order to make long terms plans based on the technology," he said, "so the JCP should remain, or some other standardization effort would, I think, naturally take its place."
I also heard from Mike Milinkovich, executive director of the Eclipse Foundation, another EC member listed among the attendees. "Java EE was originally designed for on-premise IT infrastructure," he said. "As more IT moves to public and private cloud infrastructures, Java EE needs to change. Enabling Java to support multi-vendor standards for elastic scalability and DevOps-style deployment models will be key to its future success."
He, too, felt the JCP had a few miles left on it. "I don't think the JCP is going anywhere," he said. "Open source is great, but OpenJDK only provides a single implementation. The team there is effectively building a single product, not a multi-vendor standard and an ecosystem. That may be inconvenient for some Java platform developers, but I am confident that Oracle's executive management understands how important the JCP is to the success of Java as a platform. Without the JCP there could be no WebSphere or JBoss or J9 or Zulu."
EC member Werner Keil, also on hand for the meeting, acknowledge the shift of Java EE 8 toward the Cloud, but argued that that change is not necessarily based on Oracle's recent interests. "Several members of the Java EE Umbrella [Expert Group] repeatedly asked for better support of what once was called 'multitenancy' (aka being able to serve multiple clients/tenants in the cloud more easily)," he said via e-mail. "It took until the Java EE 8 release train (or even beyond) to get those voices heard. Well, it also took till Java SE 8 to get lambdas and 9 to get modularity, first intended at least for Java SE 7."
On the JCP vs. OpenJDK question, Keil said: "Despite the 'Open' in its name, OpenJDK isn't more open than the Open Handset Alliance or .NET Foundation, while the JCP… is a vendor-neutral industry body…. To [paraphrase] Orwell, Oracle isn't 'more equal' than others in the JCP, while they're a lot more equal in OpenJDK. Not everything is rosy and efficient there, either. For example: Project Kona was announced during a BOF last year at JavaOne, and yet, as you can see from its repository, there has been no activity since before JavaOne, and some parts are even inactive for almost two years now."
I also touched base with Josh Juneau, a Chicago-based app developer, blogger and author. He wasn't at the EC meeting, but he's a thoughtful industry watcher who, like me, could read the minutes.
"The foundation of the JCP relies upon the community-centric approach that involves many different voices, and not just those of the big players," he said in an e-mail. "The community, including vendors, developers, and user groups alike, need to have the ability to help steer the direction of enterprise Java, because there are so many different pieces to the enterprise puzzle. One company cannot have all of the answers in this space, so if the JCP were taken out of the decision making and the evolution of Java EE in the future, I feel that it would make Java EE a less healthy platform for development. It would force the vendors and developers to change the way they did business based upon one company's idea of what the enterprise should look like. However, if Mark's statement was not addressing the removal of the JCP process, but rather a revision, then I could understand his position a bit more. Perhaps Mark has different ideas for how the process should be executed. That said, we need the JCP in place, whether in its current form or in a revised format, where the community still has just as much influence."
Surely everyone who reads this blog knows that the JCP is the group that certifies Java specifications, and the EC is charged with guiding "the evolution of Java." What might not be such common knowledge -- and what I want to acknowledge here -- is how hard the JCP has been working since Oracle acquired Sun Microsystems and took over the stewardship of Java to rework some of its knottier components. It started in late 2013 with Java Specification Request (JSR) 348, which was all about transparency, participation, agility, and governance. That JSR was approved without much fuss, and a year later, the JCP sought to merge two ECs -- the Java SE/Java EE committee and the ME committee -- under JSR 355. That plan was also approved.
Posted by John K. Waters on August 24, 20160 comments
In an earlier post I wrote about a new independent effort to support Enterprise Java, the MicroProfile.io project, which aims to create a baseline platform definition that optimizes Java EE for microservices architecture. I connected this week with Martijn Verburg, co-leader of the London Java Users Group (LJC), one of the initiative's founding organizations, to get some additional details on the project. Verburg is also the CEO of jClarity and a very knowledgeable Java maven.
(He lives in the UK and I'm in Silicon Valley, so our conversation took place over e-mail.)
JKW: The MicroProfile.io initiative is also sponsored by Red Hat, IBM, Payara and Tomitribe. How did these organizations come together?
Verburg: There has always been collaboration among these vendors on various open-source software projects, in particular around Java EE. For the MicroProfile initiative they'd been having separate discussions for two to three months leading up to the announcement. The first discussion was around the future of Enterprise Java and how it needed to adapt to the new world of Microservices, Cloud native and reactive, without losing the longevity, interoperability, and standards that the marketplace was used to having.
The second discussion was around the lack of progress on several key Java EE 8 specifications (about six to nine months of no movement from Oracle as it was figuring out its internal strategy for Java in this space). The LJC was involved in those early discussions, representing the Enterprise Java developer community and their myriad needs and wants.
(When I say "Enterprise Java developer," I broadly mean engineers that work primarily with some set of Java EE components at the core of their applications, such as Servlet or JAX-RS.)
JKW: Why is the project necessary?
Verburg: As a group we decided that there needed to be stronger and faster collaboration for working on new APIs and implementations that would make this new world of Microservices accessible to millions of Enterprise Java developers. It was important that this collaboration happened pre standardization, as it needed to be fast, throw away bad ideas, and provide the freedom to try new ideas! This is so that we can validate these ideas amongst the vendors and amongst the developers that will be using these new APIs.
JKW: The project goal of creating a baseline platform definition that optimizes Enterprise Java the for microservices architecture is pretty clear. Is there anything else you'd like to say about that?
Verburg: That [the initiative] is very much a partnership between the developer community and the vendors. In fact, I'd even say that it's leaning toward a relationship in which the developers are expressing their requirements in this space and the vendors are responding by rapidly prototyping ideas and getting feedback and refinement from the community.
JKW: Will the initiative become a JSR in the Java Community Process or an Oracle JEP, or is that even necessary?
Verburg: We'd like to see parts of the platform go through a standardization effort (when ready), yes. I guess you could see it as an incubator for potential standardization work. It's something that the JCP has actually always encouraged; they like to see multiple implementations of a technology, with a baseline of those competing implementations being standardized.
JKW: Have you all thought about how you'll manage the project -- organizational governance, that sort of thing?
Verburg: There's a mailing list thread that started today about the potential move to a Software Foundation. All of the partners agree that it would be a good step for the initiative and would help enshrine its neutrality and collaboration.
JKW: MicroProfile.io seems likely to put even more pressure on Oracle to pay attention to Java EE. Am I right about that? Have you heard anything from Oracle about the project?
Verburg: Oracle have started to shed some light on some of their ideas around this area, and we've invited them to join in the effort. They recently stated at the JCP EC meeting (minutes to be released shortly) that they'll look into doing that, as well as making their plans on Java EE 8 clearer going forward. We find that encouraging.
Posted by John K. Waters on August 12, 20160 comments
Oracle may have been neglecting Enterprise Java over the past few years, but it's sure paying attention now. The Java EE Guardians threw a spotlight on what they saw as a lack of core investments in the technology when the volunteer advocacy group went public in March, and they cranked up the intensity when they posted a petition on the change.org Web site aimed at Oracle executives. In July, Oracle seemed to be responding to the Guardians' charges in a statement about its commitment to Java EE 8, and a growing number of Oracle execs are actually talking to the press.
Now comes a new independent effort to support Enterprise Java: the MicroProfile.io project. Sponsored by Red Hat, IBM, Payara, Tomitribe and the London Java Community, the goal of the project is to create a baseline platform definition that optimizes Enterprise Java for microservices architecture.
"Enterprise Java technologies like Java EE have evolved with the industry for nearly two decades to support distributed application architectures based on RMI/IIOP, Web Services, and REST," the Web site explains. "The MicroProfile is the next step in that evolution."
Project contributor Antonio Goncalves, a Paris-based Java EE developer and architect, agrees that the MicroProfile represents another step in the evolution of Java EE, whose origins he traces to the Enterprise JavaBeans component model. "The EJB component model was a Micro component," he wrote in a blog post, "just embed the needed business code, as small as you can, package it as a unit in a single jar, link it with other components/EJBs via RMI/IIOP, and the container will look after the rest.... But since then, Java EE containers have evolved. They have been lighter, smaller, faster ... so it was time to have a MicroProfile: micro components running in a micro container."
The project is focused initially on providing a baseline for a group of specifications: JAX-RS, the Java API for RESTful Web Services, Contexts and Dependency Injection (CDI) and JSON-P (JSON "with padding"). The project's organizers are aiming to release a public version in September.
"We want to ensure, as we move forward into this new, containerized, cloud-native world, that we do it responsibly, and customers don't get left with some proprietary single vendor technology stack," said Rich Sharples, Red Hat's senior director of product management during an interview following the announcement of the project at the recent Red Hat Summit.
The project's organizers are emphasizing the need for community participation in developing the MicroProfile definition and project roadmap. "I think there's a real chance that we can bring the whole Enterprise Java community together around this," Sharples said.
Posted by John K. Waters on August 10, 20160 comments
Reddit's "Ask Me Anything" (AMA) forum has attracted some brave souls since the "I Am A" (IAmA) subreddit was established in 2009. Everyone from Snoop Dog to Donald Trump (set to host an AMA on July 27) has signed up for this unique, almost-anything-goes public Q&A. Last week Google's Android engineering team took the AMA plunge for the first time, just a few days after the release of the fifth and final developer preview of Android Nougat (v7.0).
My colleague, David Ramel, covered the event and pointed out to me the flood of questions about Java.
Android applications are developed in Java, so the high level of interest wasn't surprising. But we live in a polyglot world, and many of the questions about Java were actually about how (and whether) the Android team will support other languages in the future. A question from "mastroDani" was typical:
Java is a good programming language but [its] age is starting to feel, a modern language would make the development easier and faster. The community is creating many unofficial language supports for developing in Android: kotlin, groovy, scala, just to name a few. This shows there's a request for it. However, choosing one of those language comes with some level of risk or unexpected side effects because of its unofficial support. Is any of those language gonna become officially supported? Or is there any plan to move from Java to something else?
Anwar Ghuloum, engineering director for the Android Core Platform group, fielded that question: "We don't have any plans to move to a new language. Java has a lot of advantages to it and the versions 8, 9, and 10 have some pretty interesting stuff for developers. We are planning to track more closely in time to the Java language standard...."
Another questioner, "elkaramba," also wondered if the team might be at least considering support for Kotlin, a statically typed language similar to Scala developed by JetBrains. The question prompted a lively exchange among several participants. mastroDani observed: "Look at how many question [have] been asked about it. Someone even suggested we should use Swift to develop Android apps. I would be really surprised if Google kept ignoring all those voices and I don't want to jump on a language risking having to change it again in a few years."
Later "Inkprk114" brought the conversation back to the question of Android support for Kotlin: "... I personally doubt that Google will officially endorse any other language for a long while, but I would like to know how your team feels about some of the alternative languages that are popping up -- Kotlin being the one I'm most interested in. Do you feel it's in stable enough condition to use for production applications? Would you recommend using other languages, or do you feel sticking with Java is still the correct decision for developers? Have there been any discussions regarding Kotlin on the team, and are you guys in touch with any of the developers of the language over at Jebrains?"
Ghuloum's response: "We don't have any plans to officially support a new language in Android, so we'd encourage folks to continue to use Java :) That said, you should continue to use what works for you."
mastroDani wrapped up the discussion with this observation: "The community is creating many unofficial language supports for developing in Android: kotlin, groovy, scala, just to name a few. I believe the reason behind this is that those language [make] writing software easier, less tedious and more boilerplate-free. However, choosing one of those language comes with some level of risk or unexpected side effects because of [Google's lack of support].... "
It's clear from this conversation (which you'll want to read in its entirety) that Google is solidly wed to Java on Android and has no plans at the moment to support anything else. That's not surprising, either; the company has invested a lot in Java (in court costs alone). And earlier this year Google announced plans to replace its Apache Harmony implementation of the Java libraries in upcoming versions of the Android OS with Oracle's OpenJDK, effectively replacing the code that has been at issue in the long-standing legal dispute between the two companies.
I'm sure it's useful to a get clear, from-the-horse's-mouth answer to this question for Android developers, a growing number of whom are very interested in Kotlin, Groovy and Scala, "just to name a few." How long the company will be able to stick with this monolingual strategy remains to be seen.
Posted by John K. Waters on July 26, 20160 comments
Sonatype has just released its second annual report on managing open source components. The "2016 State of the Software Supply Chain" report is available now, and well worth reading.
Among the things I like about this report is that it's based on the analysis of 31 billion download requests of open source software components from the Central Repository, which Sonatype manages, and that it's the result of an analysis of the patterns and practices of more than 25,000 developers and 3,000 organizations.
The company started out as a core contributor to the Apache Maven project, which is now the largest public repository of open source Java components. That 31 billion figure represents an increase of 82 percent between 2014 and 2015, according to the company. Sonatype also introduced repository managers into the software supply chain with its Nexus products.
Easily the most disturbing revelation in this report is that defective components in the software supply chain are routinely making their way into applications, which is costing enterprises millions of dollars. In fact, 1 in 16 downloads from the repository had a known security defect, the report's authors found, and 6.8 percent of components in use among the 25,000 applications analyzed had a known security defect.
And it gets worse: "However, because a single component may contain multiple vulnerabilities, it's important to understand that an average application consisting of 106 components -- of which 6.8% are known bad -- could contain numerous unique vulnerabilities," the report stated.
The problem here is twofold: not all components are created equal -- as the report puts it, the "massive variety and volume of software components vary widely in terms of quality -- and components "age and grow stale quickly."
"Last year, the average enterprise downloaded 229,000 open source components," the report warned. "If properly sourced and managed, open source components are a tremendous source of energy for accelerating innovation. If not, they lead directly to security vulnerabilities, licensing risks, enormous rework, and waste."
I touched base about this particular finding via e-mail with John Matthew Holt, founder and CTO of Dublin-based Java security vendor Waratek.
"That's an overwhelming statistic when you consider that it represents about 2 billion components downloaded with a known vulnerability," he said. "Security risks are a fact of life and will always be with us in some form. What this statistic points to is the need to move beyond trying to 'fix the code' or 'just writing better code.' Those are not viable solutions to address all vulnerabilities."
Holt is an enthusiastic proponent of Runtime Application Self Protection (RASP), which Gartner has defined as "a security technology built in or linked to an application or app runtime environment, and capable of controlling app execution and detecting and preventing real-time attacks." Holt's company makes a containerized RASP product, called Locker, which provides security monitoring, policy enforcement, and attack blocking from within the Java Virtual Machine (JVM).
"The Sonatype report points to two major Java risks that can be mitigated by RASP delivered by virtualization: known (and unknown vulnerabilities) as well as legacy code," he said. "A RASP solution can virtually patch known vulnerabilities on a permanent basis or temporarily while you rewrite the risky code, without shutting down the app. RASP can also be used to bring out-of-date components, whether they represent a vulnerability or not, to current Java standards without having to change an app's code. That's important when you look at the Sonatype's finding that 10% of components in 1,000 repositories had not been updated in five years or longer."
I also wondered about the implications of these findings for Java SE 9 and Jigsaw (componentization), due later this year.
"There are problems throughout the entire app stack today," he said, "not just with components downloaded from repositories. You'll find problems in the business logic layer, open source components from libraries, and even the code that comes with the JVM platform. So in that sense, a new version of Java and Jigsaw won't expand the problem; they will only add more hay to the stack while we search for needles of vulnerability."
The Sonatype report looked at more than security vulnerabilities, of course. Its other key findings include:
- Developers are "gorging" on an ever expanding supply of open source components. The use of third-party, open-source components "exploded" last year, the report found, and the trend is accelerating.
- "Vast networks" of open source component suppliers are growing rapidly. These networks created 1,000 new projects and delivered 10,00 new versions per day, according to the report.
- Software supply chain management practices are gaining traction. Top performing enterprises, federal regulators, and industry associations have embraced the latest supply chain management best practices, which include things like using fewer and better component suppliers, procuring only the best parts from those suppliers, and continuously tracking and tracing the precise location of every component.
There's much more in this report, including tons of stats and some useful infographics. As far as I'm concerned, it's a must read.
Posted by John K. Waters on July 13, 20160 comments
Oracle has finally responded to my -- and I'm sure many others' -- requests for comment on the future of Java EE, on which the formation of the Java EE Guardians threw a spotlight a few months ago. A member of the Oracle PR team sent me an e-mail in which Mike Moeller, Oracle's vice president of marketing communications and global public relations, offered the following:
"Oracle is committed to Java and has a very well-defined proposal for the next version of the Java EE specification -- Java EE8 -- that will support developers as they seek to build new applications that are designed using micro-services on large-scale distributed computing and container-based environments on the cloud. Oracle is working closely with key partners in the Java community to finalize the proposal and will share the full details with the broader Java community at JavaOne in September."
The Guardians, a group of volunteers committed to supporting enterprise Java, has been making the case that Oracle has been "conspicuously neglecting" Java EE. I've been reaching out to Oracle for a reaction to that claim since the Guardians made its public debut in March, but it's been radio silence from the blue silos in Redwood Shores until now.
It would be easy to conclude that that silence was broken in response to a petition posted by the Guardians last month calling for Oracle "to cooperate with us as a responsible, community-focused steward to move Java EE forward." (More on the petition here).
According to Reza Rahman, a former Oracle enterprise Java evangelist and one of the founders of the Java EE Guardians, response to the petition has been strong and "is proving instrumental in getting Oracle to listen." More than 2,800 people have signed the petition so far, Rahman told me in an e-mail, and more are signing at an average rate of 20 to 25 per day.
"For a deeply technical issue, I think that's a very good response rate," he said. "Most technical surveys usually garner around 500-1,000 input points (and struggle even to get that). It is certainly enough to empower our allies within Oracle to renew the struggle to do the right thing for the community."
Although the Moeller quote is short on details, Oracle's response should be viewed as a positive development, Rahman said. "The community should treat the lack of detail as an opportunity to continue to constructively engage Oracle, while remaining vigilant," he said. "We all need to work together to continue to ensure the well-being of the Java and Java EE ecosystems. Hopefully the forward plans for Java EE will be developed collaboratively and with direct community input."
Rahman also reminded me that the Guardians has been attracting some high-profile support to its cause. The growing list of community movers and shakers that have joined the group now includes James Gosling (the father of Java) and Java User Groups from all over the world.
Posted by John K. Waters on July 8, 20160 comments
The Java EE Guardians launched their public Web site last week and simultaneously posted a petition on the change.org Web site aimed at Oracle executives.
The original core group of volunteers committed to securing the continuing evolution of enterprise Java founded the formal organization in March with a Google Group and a Twitter handle (@javaee_guardians). But the Web site provides what founding member Reza Rahman calls "the essential public face of our movement."
"It makes us public in a way that the Google Group and Twitter account do not," Rahman told me in an e-mail. "It basically gives our movement identity, structure and presence. It says, we are here, we are serious and we are persistent."
The Web site includes a home page that explains the group's purpose, an "Evidence" page that makes their case that Oracle is neglecting Java EE, a page that tracks the group's activities, and one that lists its growing membership, which currently includes James Gosling (the Father of Java) and Java User Groups from all over the world.
The Web site also links to the change.org petition page, which Rahman said the Guardians posted to provide a wider range of people who might be interested in this issue with a place to take some action. "It's a way to empower average people and engage them with our movement," he said.
The title of the petition reads: "Tell Oracle to Move Forward Java EE as a Critical Part of the Global IT Industry," and it's directed specifically at Oracle Executive Chairman and CTO Larry Ellison, co-CEOs Safra Catz and Mark Hurd, president of Product Development Thomas Kurian, EVP of Fusion Middleware Development Inderjeet Singh, and Group VP of the Microservices-Cloud group Anil Gaur.
The document lays out the case again that "Java EE is incredibly important to the long term health of the entire Java ecosystem," and that "Oracle is conspicuously neglecting" it. And it asks visitors to the site to sign up to petition Oracle to do three things:
- Clarify how it intends to preserve the best interests of the Java, Java EE, and servers-side computing ecosystems.
- Commit to delivering Java EE 8 in time with a reasonable feature set that satisfies the needs of the community and the industry.
- Effectively cooperate with the community and other vendors to either accept contributions or transfer ownership of Java EE 8 work.
"As committed as we are," the document states, "we still need Oracle to cooperate with us as a responsible, community focused steward to move Java EE forward."
Shortly after the Web site and petition went up, I chatted via e-mail with one of my favorite industry watchers about the Java EE Guardians and their efforts. Forrester principal analyst Jeffrey S. Hammond believes that they are sincere in their efforts, but also that, despite those efforts, the future of Java EE is uncertain.
"I take them at their word that they are concerned about the pace of Java innovation," Hammond said, "especially Java EE. For years it was a pretty basic choice in the dev world: Java or .NET. But the reality these days is that there are more options than ever when it comes to building modern systems, including full-stack JavaScript, PHP, Python, Go, Ruby and more. If a framework like Java EE doesn't adapt to the needs of modern developers, those who've built their careers on it have a different choice: shift gears, accept becoming legacy, or try to reinvigorate the technology. My sense is these folks are pursuing option three."
What about the charge that Oracle is neglecting enterprise Java?
"We see evidence that Oracle is investing in both its cloud capabilities and in JavaScript runtimes, and it's possible some of this is taking away from or slowing down the standards process," Hammond said. "That said . . . it's not clear whether the status quo with Java EE is even preservable any more. Hopefully [the Guardians'] genuine concerns will elicit a positive response, but I think I'd be inclined to also consider other alternatives in the event that Oracle continues its benign neglect."
Posted by John K. Waters on June 22, 20160 comments