James Gosling, the Father of Java, is on the move again. This time, according to a public post on Facebook, it's Amazon Web Services.
"It's time for a change," Gosling wrote. "I'm leaving Boeing Defense (nee Liquid Robotics), with many fond memories. Today I start a new Adventure at Amazon Web Services."
He also updated his LinkedIn profile with a generic AWS job title: "software engineer." He described his new gig this way: "Now I'm wandering around at Amazon Web Services."
Gosling, who was unavailable for comment as of this writing, has had a lively career since Oracle acquired his long-time employer, Sun Microsystems, back in 2010. The former Sun Fellow signed on briefly as CTO of Oracle's client software group, but left the company later that year for a short stint at Google. In 2011 he landed at Liquid Robots, a maker of "autonomous, ocean going platforms" acquired by Boeing last year. In 2014 he joined the platform development advisory team of Java/PHP Platform-as-a-Service provider Jelastic.
Gosling, who is credited with inventing the Java programming language in 1994, was one of the highest profile former Sun employees to leave Oracle following the $7.5 billion acquisition. CEO Jonathan Schwartz, chairman and co-founder Scott McNealy, director of Web technologies Tim Bray, and open source evangelist Simon Phipps never made the transition.
I asked around about Gosling's latest transition, and one Java watcher expressed what I found to be a consensus among those who care about such things: "Guys like Gosling will stay at a place only so long as they're able to do 'their work' (whatever that work is at the moment). When they start running into barriers -- orgs, funding, culture, etc. -- they find more welcoming venues and carry on." Another one put it this way: "The guy is semi-retired and jumping from one interesting thing to another."
From the company's point of view, Redmonk analyst Stephen O'Grady suggested, hiring Gosling could be about courting enterprise Java customers, leveraging his IoT expertise from Liquid Robotics, or just giving him room to experiment.
"Whatever the reality," he said in an e-mail, "it's an interesting and high-profile hire for AWS, one that will have PR benefits beyond whatever he can contribute technically."
Posted by John K. Waters on 05/23/2017 at 7:16 AM0 comments
When Wayne Citrin and his partners founded JNBridge back in 2001, Java was about five years old, .NET was still in beta, and the term "cross-platform interoperability" wasn't exactly rolling off the tongues of software vendors. But what seemed like irreconcilable differences at the start of the 21st century looked to Citrin and his partners like opportunity.
"We never had any doubt about this business," Citrin told me. "We'd go into the forums back when .NET was first introduced, and one of the most common questions we'd see was: Will I be able to use it with my existing Java? Microsoft was saying, Oh no, you'll want to take out that Java and rewrite it, or if you don't want to do that, we have something called J#, or we have these Java conversion tools. But there were all sorts of problems with those approaches. What was needed was a bridge between the two platforms, and that's what we provided."
JNBridge showed up on my radar nearly a decade ago at a JavaOne conference, and I've been talking with Citrin, who serves as CTO of the Boulder, Colo.-based company, regularly ever since. I covered his company's product announcements when they were newsworthy, of course, but I also found myself turning to him for his unique perspective on these important enterprise technologies. He's a thoughtful observer with a foot in two different worlds. (Sometimes downright hostile worlds: I think the year the company was founded Microsoft and Sun were suing each other.)
With anniversaries colliding this year -- both JNBridge (the product) and .NET turned 15, and Visual Studio turned 20 (Java turned 20 in 2015) -- it seemed a propitious moment to check in with the guy who spends his days getting Java and .NET to play nice.
Sixteen years is a respectable stretch for a niche tech company. How do you account for your continued success?
We recognized the value of that niche right away and focused on it exclusively. Then we went beyond the general-purpose bridge with the Adapters. And with our Labs, we're able to focus on the common and urgent scenarios people were tell us about.
Just to clarify, your namesake product, JNBridge, is a general purpose Java/.NET interoperability tool designed to bridge anything Java to .NET, and vice versa. Your Adapters connect the Java Message Service (JMS) with BizTalk Server and other .NET apps. And the Labs are free kits that showcase scenarios that bridge Java and .NET.
The JMS Adapters are a big part of our business, now. There's a lot of legacy JMS infrastructure out there. It's still one of the most common ways to connect components in an enterprise and pass data around.
What's the most significant change you've seen in Java in the past 15 years?
Most people would probably say it was the handoff of Java from Sun to Oracle. But I think the most significant change we've seen lately is the decline of Java EE and its replacement with a variety of open-source frameworks. Spring, the various Apache projects, the various web frameworks; I think this is probably a good thing. Java EE was too complicated and hard to use, there was a lot of ambiguity in the specs, and things were different from one app server to another. On the other hand, what you have now is a fragmentation with a whole lot of frameworks. The good news is, a lot of them are very good frameworks, easy to use, and supported by a committed community of users who actually like them.
We've talked about this before. You see a difference between Java EE and enterprise Java?
They're not the same thing, and they haven't been for a long time. Enterprise Java is not going away any time soon, and I think it's fair to call Java EE a subset that, in many ways, has had its day.
Looking specifically at the next versions of Java, which changes excite you the most?
I really like Jigsaw, the modularization coming in Java 9. A lot of people are worried about, but it's not such a big deal to us. They really did a good job of accommodating legacy code. If you have a non-modularized jar file, you can still use it in Java 9. You could use it in the crosspath or put it in the module path. You could do the same thing with a modularized jar file. You could also use it in an early version of Java; it just wouldn't be recognized it as a module. They put a lot of thought into this, and I applaud them for it.
But there's another great feature in Java 9 that hasn't gotten a lot of press. It's called multi-release jar files. The jar files in Java 9 have these nooks and crannies. There's a nook just for stuff Java 9 will know about; Java 8 doesn't know about this stuff and won't use it. Java 9 will look there first and override the general-purpose stuff in the jar file. I think is a very cool feature and we plan to use it going forward. We're just waiting for the tooling to catch up to make it easy.
While you've been watching the evolution of Java and .NET, you've also had a ringside seat for the evolution of the people using these platforms. How has the developer community changed over the past 15 years?
Fifteen years ago, developers had much more uniform characteristics. But there has been a noticeable bifurcation. With the rise of open source projects, we're seeing a large group of developers who are really interested in getting under the hood and understanding how things work. They're using lots of really cool tools to see what's happening at a much lower level, really getting their hands dirty and using those tools to solve problems. We're interacting with a lot of developer customers who are very sophisticated about this stuff in a way they weren't 15 years ago.
But we're also seeing a smaller group of developers who will go until they see a problem, and then stop and come to use for a solution. I'm not saying they're bad developers; they just have a different mindset. I think this group is the result of the rise of these frameworks I mentioned and a world of low-code development where things just work. Unless you really want to, there's no reason to look under the hood, and it's even kind of hard to do it. Plus, there's a lot of legacy software out there that just gets maintained, which we didn't see 15 years ago. Often people we're working with are not the original developers; they're just tasked with maintenance. And it might not even be their full-time job, just something they have to do on the side, and only when there's a problem or a new feature.
Speaking of mindsets, your company is now, and always has been, headquartered in Colorado, which is not exactly a high-tech hub. Why haven't you set up shop here in Silicon Valley?
I like it here in Colorado and don't see any reason to move. You don't need to be in Silicon Valley to run a successful tech business. And as expensive as office space is out there, it's cheaper just to get on a plane once in a while.
Posted by John K. Waters on 04/12/2017 at 10:08 AM0 comments
Mike Milinkovich, the executive director of the Eclipse Foundation, kicked off Eclipse Converge 2017 this week with an update for attendees on doings at the 13-year-old organization.
The Foundation grew over the past year to 331 projects, Milinkovich said, and the rate of increase seems to be accelerating. "In the past couple of quarters, we've had more new Eclipse project proposals than I can ever remember," he said. Milinkovich underscored the quality of the ongoing projects at the Foundation with a reminder of how vigorously his organization separates the wheat from the chaff. "We think it should be pretty easy to start an Eclipse project," he said, "but if it's not going well or there's not a lot of activity, we're going to garbage collect every summer."
More than 1,400 committers are currently involved in Eclipse project, he said. Many of the newer participants are drawn to the IoT projects and science group.
"We've worked really hard over the past few years to establish our Foundation as a community where both the biggest companies and the most interested individuals can collaborate successfully on projects," he said. He pointed to the Foundation's flagship Eclipse IDE as an example of a project that continues to draw "a mix and match" of companies and individuals.
Among the most popular of the Foundation's working groups is the Science Working Group, he said. The group's goal is to improve software for science -- things like biology and chemistry workbenches that make it easier for researchers to analyst as run experimental workflows. A founding member of that group, Tracy Miranda, co-founder of Kichwa Coders, a consultancy specializing in Eclipse tools for embedded and scientific software, became the first woman elected to the Eclipse Foundation board this year.
The relatively new Eclipse IoT group now accounts for 30 projects, he said, and for a significant percentage of the Foundation's growth. "We started with this about five and half years ago with a project called Eclipse M2M," he said. "The growth and evolution has been amazing to watch." Geospatial and automotive projects are popular areas of focus among Eclipse committers, he added. And he was especially proud of the work the Foundation has done to make the Eclipse Intellectual Property (IP) Policy more contributor friendly.
He also said that the 12th annual synchronized release of Eclipse projects known as the Release Train is on schedule for June. This year's release, codenamed "Oxygen," is expected to exceed last year's release by a few projects and a few lines of code. And he also promised that the Foundation will ship an Eclipse maintenance release the day Java 9 goes live.
I met with Milinkovich after his keynote to talk about what is arguably one of Foundation's most important but least sexy efforts: the new Eclipse IP Policy.
Approved last June, the new policy provides project owners with the option of foregoing the Foundation's traditionally intense code analysis for a more streamlined approach.
"Throughout the lifespan of a project, we do a deep analysis of all the dependencies," Milinkovich explained, "so that we can demonstrate that we know who wrote all the code that gets contributed at Eclipse. We look for third-party dependencies and check license capability. But we also check the code provenance. We scan their code, go through their email archives looking for conversations, analyze the code to see if any of it has ever been re-licensed. It's an enormous time investment, both for the Foundation and the committers."
When a new project comes to Eclipse, it can take weeks and even months to clear all the dependencies via this process.
"And boy, can that suck the air out of a room, "Milinkovich said. "I mean, you come to Eclipse with a project, and you're buzzing and excited to be there and you're ready to get going… and, oh yeah, you can't do crap for four months. Not a great thing for developers."
The alternative, called Type A, stops at checking license compatibility and does not check the provenance, which is similar to the approach used by the Apache Foundation, Milinkovich said.
"It gets projects off to a quick start," he said, "and we're finding that once the projects mature, the committers come back and ask for the Full Monty."
The one-day Eclipse Converge event is a new one for the Foundation. The idea was to provide an Eclipse-focused event during which North American developers could meet and share ideas. A range of Eclipse contributors, adopters, extenders, consumers, and researchers gathered at the San Jose Convention Center for the conference.
By design, the Converge event was held at the same venue and one day before the inaugural Devoxx US conference. The Devoxx program, launched in 2001, sponsors events in five countries (Belgium, UK, Morocco, France, Poland) and now the US. Event organizers bill the program as the provider of the largest vendor-independent developer events in the world, collectively. No EclipseCon North America conference is planned for 2017, due to the combined events of Eclipse Converge and Devoxx US. "We believe these two events will enable all members of the Eclipse community to come together and share new ideas, not just among other Eclipse community members," organizers said in a statement, "but also with some of the best and brightest in our industry."
Posted by John K. Waters on 03/22/2017 at 3:27 PM0 comments
I'm not sure what I expected when I finally connected with Gartner Vice President and Distinguished Analyst Anne Thomas last week to discuss a research note she co-authored that took heavy fire from critics in the enterprise Java community. But her chipper, glad-to-help-out response to my interview request shouldn't have surprised me; in the roughly two decades since we first met, I've found Thomas to be a responsive and thoughtful industry watcher with a relatively thick hide.
"It's my job to be controversial if that's what's needed," Thomas told me, "to make people take a step back and look at what's really going on."
What did surprise me was Thomas's contention that she and her critics are essentially on the same page.
Thomas wrote the report ("Market Guide for Application Platforms") with contributing analyst Aashish Gupta. In it the authors asserted, among other things, that Java EE has not kept pace with architectural trends and digital business initiatives, that Java developers are demonstrating a clear preference for lightweight frameworks over Java EE, and that Java EE is not an appropriate framework for building cloud-native applications. They also advised those responsible for modernizing an enterprise's application infrastructure to "develop a strategy to deal with the obsolescence of Java EE and other three-tier application frameworks."
Java EE community leaders called the Gartner analysts irresponsible and out of touch with the platform, and many blasted the report in blog posts and social media (and my inbox). I interviewed several of those critics for my January post, which includes links to some of the blogs.
Thomas was a bit surprised at the level of outrage over her and Gupta's observations on what she believes are obvious facts about Java EE and the evolving demands on enterprise developers.
"In the note I definitely acknowledged that Java is a tremendous platform for developing enterprise applications," she told me. "But Java EE is, by definition, this amalgam of this massive number of APIs, all of which the certification process says must be present in the platform. What I'm saying is, people don't need 90 percent of the stuff sitting in Java EE to build modern enterprise applications."
Some critics argued that Thomas and Gupta failed to recognize that Java EE has evolved since version 5 and the J2EE era, and that lighter-weight enterprise Java technologies, such as the Web Profile, IBM's WebSphere Liberty Profile, Red Hat's WildFly Swarm, Payara Micro and the new Eclipse MicroProfile, have emerged. Others insisted that the admittedly slower pace of Java EE's evolution is a strength of the platform; it's standards-based, which matters in the enterprise.
But the critics are, if inadvertently, helping to make Thomas's point, she said.
"I'm 100 percent in agreement with a lot of what these guys are saying," she said. "But they've got it in their heads that Java EE means all of Java. The new MicroProfile, for example, is just three Java APIs. That's great, but it's not Java EE."
Everyone understands that Java EE is overgrown, and none better than Thomas, who was working at Sun Microsystems when the platform was conceived and the seeds of that growth were planted.
"The original intention behind Java EE was to make sure that everything you could possibly want in the enterprise Java space was going to be available in any application server you decided to deploy it on," she recalled. "It was all about portability. If I'm building a Java application, I know I'll have this specific set of APIs and these specific versions, so that when I'm building an application I'll know it's there. That was a valuable proposition when Java EE was first created.
"The problem is it ended up becoming this incredibly bloated environment. Do I really need CORBA in applications that I'm building today? In the next version of Java EE, they are going to remove CORBA, so there is evolution happening. The Web Profile took out a bunch of things, and it's a much better environment for building application than a full-bore Java EE. But it's still very focused on three-tier, where the front-end tier is a Web environment. It's not designed to support multi-client-, multi-channel-type applications. It's not designed to support both Web and mobile, much less 20 or 30 other types of systems that are out there. It's not very well suited to support Internet of Things applications. And it's not designed to support microservices, which is why this independent group has gone off and said, we have to have a MicroProfile for Java EE."
One of the criticisms leveled against Thomas and Gupta's report was that they failed to differentiate between the Java EE standard and what Java EE vendors are building.
"Again, that supports my position," Thomas said. "What the vendors are building is not in conformance with the standard. They are building much smaller, much more focused implementations. They're not including everything but the kitchen sink in case somebody might need it.
"If you look at something like the Jetty Web server, for example, which a lot of people are using now to build their applications, I think it's now about 12MB in size. Compare that with the WebLogic platform, which is over 3GB in size. Why do I need such a big platform to host a microservice? It would be insane to use it. What I want is to embed Jetty, or Undertow, or Tomcat into my Spring Boot component, which is now an independently deployable component. I don't have to deploy it into an application server. I just put it into a container and deploy it directly onto my VM. That's what the new environment looks like."
Effectively, she went on to argue, Java EE and enterprise Java are no longer the same thing. And a modern enterprise Java platform for modern applications is emerging, not from Oracle or the older standards bodies, but from open source communities.
"Over the past five years, maybe longer, the open source communities have literally displaced the big standards bodies as a way of ensuring fast innovation and commonality across different systems," she said. It takes years for new standards to get produced through the Java Community Process (JCP). And that process is even slower now that Oracle is running the JCP. The fact is, open source in general is a much more effective way of creating community standards. Communities like Spring, CloudFoundry, Eclipse, Apache -- that's where innovation in Java in particular is happening."
Thomas also expressed her admiration for the work of groups like the Java EE Guardians and the MicroProfile.io initiative, but insisted that they aren't protecting Java EE, but enterprise Java.
"The MicroProfile is saying, this is the stuff that's important to us today," she said, "but Java EE does not give us what we need, so we have to build our own, because Oracle isn't doing that. And the Guardians recognize that Oracle isn't doing what is needed to maintain Java as a critical enterprise language and platform for the modern age."
Posted by John K. Waters on 02/16/2017 at 9:45 AM0 comments
Oracle's latest Critical Patch Update, the first of 2017, left Java security maven and Waratek CTO John Matthew Holt scratching his head about Big O's fix for a particular vulnerability: CVE 2017-3241, which affects Java SE, Java SE Embedded, and JRockit, and earned a CVSS score of 9.0 out of 10.0 (very bad).
Holt considers this CVE -- a deserialization vulnerability inside the core Java Remote Method Invocation (RMI) APIs -- especially serious, and he lamented Oracle's fix: a user-configurable whitelist/blacklist filter. He called deserialization an "application security nightmare," and Oracle's latest fix "easy, obvious and simple," but not especially effective.
"I'm really not knocking Oracle," he told me. "They did address the vulnerability, but it's a primitive form of defense, and far from what is considered to be the best way of dealing with it."
Serialization is the process of converting an object into a stream of bytes for transport and storage. Deserialization reverses the process when the data is received. Security researchers discovered that the RMI registry and DCG implementations in the RMI component of OpenJDK performed deserialization of untrusted inputs. A remote attacker could use this vulnerability to execute arbitrary code with the privileges of RMI registry or a Java RMI application.
In its security advisory, Oracle explained it this way: "This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator)."
High-profile attacks that exploit deserialization vulnerabilities abound, Holt said. To give me a local example, he cited last year's deserialization attack on the San Francisco Metropolitan Transit Agency's Municipal Rail (MUNI to locals). As security researcher Brian Krebs reported in November, the ransomware attack caused fare station terminals to carry the message, "You are Hacked. ALL Data Encrypted," and fare payment machines to read, "OUT OF SERVICE" in red LED letters. An SFMTA Web-facing server was probably compromised by the deserialization attack after it was identified by a vulnerability scan. A similar vulnerability was exploited to attack Med Star, the Maryland health system, last spring, and deprive multiple hospitals of access to critical systems.
The problem with the Oracle fix, Holt said, is fourfold:
- Any heuristic or "hands-on" security technique based on whitelists/blacklists almost always requires intricate manual configuration and tuning to operate correctly.
- Anything requiring manual human configuration and tuning requires special domain-specific and app-specific knowledge to configure, is expensive to test and validate, and prone to mistakes and human errors.
- Incomplete or incorrect configuration/tuning virtually guarantees false-positive results, which will break application operation and service.
- Most security professionals know nothing about the serialization mechanics or dependencies of the applications they're tasked with securing, making the job of configuring whitelists/blacklists virtually impossible.
"The consequences of requiring an application owner to know everything about the application -- to be God -- which this approach does, is that you are essentially putting the entire burden of the effectiveness of that security system on the end user, instead of the system," Holt said. "If an attack is successful, it's not the system's fault, but the user's. And that's just not an effective approach."
Waratek has found a way to circumvent this heuristic approach, and in the process, established a niche in a market overflowing with large enterprises that continue to run custom-developed, mission-critical applications on out-of-date versions. The Dublin-based company's virtualization-based AppSecurity product is designed to protect the Java Platform attack surface from known and unknown vulnerabilities by virtually applying critical patch updates and security policies at runtime. Waratek uses a proprietary Smart Compartment to process deserialization without relying on black or white lists.
"Walk into any really large organization and ask them how many Java applications they've got, and they'll tell you, oh we have 500 server-side applications, or 1,000 or 5,000," Holt said. "This is something we hear regularly. No human being is going to sit down in those organizations and manually create individual deserialization lists for those applications."
One of the knottier challenges facing organizations when it comes to application security -- and one Oracle can't solve with a CPU -- is the typical skill sets of the people charged with it, Holt said. "If you look at the security team in any major organization," he said, "most of the people have backgrounds in network security or systems administration. That's traditional. But application security, which is a relatively new problem space, involves thinking about the security inside the application, and these skill sets are inherently outside the application."
Adding to that challenge: App security can be frustratingly language-specific, he said. "The way deserialization vulnerabilities work and are exploitable on Java are entirely different from the way serialization vulnerabilities are exploitable on .NET or Ruby."
Posted by John K. Waters on 01/24/2017 at 11:47 AM0 comments
Talking with Siddhartha Agarwal, Oracle's VP of product management and strategy, about the trends his company expects to impact developers in the coming year, I couldn't resist the obvious pun.
"So, you're Oracle's oracle?"
"You could say that, I guess," he said. "But these predictions are based not on my thinking, but on many conversations we've had with our customers, mostly large enterprises. Not many people tell us, for example, that they are currently using containers in development and production. But many people tell us that they want to use containers and they are starting down that path."
Agarwal is responsible for product management and strategy across Oracle's PaaS portfolio. His job, he said, is about "taking this rich portfolio and coming up with the solutions people want and ways to getting them to market."
Those customer conversations have led Oracle, "which has always been very good with IT," to a new focus on delivering "an open, modern, easy platform for developers," he said. "Developers are a very important constituency for us."
Readers should feel free, of course, to take these prognostications with a grain of salt (as we should all industry augury). But keep in mind that Big O is betting big on these trends with investments in products and services with which it fully expects to exploit them.
1. New application development and deployment on containers will become more popular than dev-and-deploy on virtual machines toward the end of 2017 and into 2018.
"We all know the benefits of containers in improving the DevOps lifecycle," Agarwal said, "but when the containers go into production there's a lot more stuff for the developers to manage. They need to manage orchestration tools, such as Kubernetes, for example, and they might need to manage scheduling paradigms, like Marathon, or they might need to manage Etcd, which is the open source distributed key-value store that Kubernetes uses.
"As this trend evolves, developers are going to want a comprehensive cloud-based Container-as-a-Service platform," he added, "something that provides a quick way to create an enterprise-grade container infrastructure."
Not surprisingly, Agarwal pointed to Oracle's Container Cloud Service as one of the solutions that will meet this demand. Announced at last year's Oracle OpenWorld conference, the service provides tools for composing, deploying, orchestrating and managing Docker container-based applications on the Oracle Cloud for Dev, Dev/Test, DevOps and Cloud Native use cases.
2. The number of application releases from typical businesses will double over the coming year.
Oracle believes this accelerated pace will be driven by a burgeoning crowd of line-of-business (LOB) people amid digital transformations who want to experiment, to try a lot of applications or initiatives, with the expectation that only a few of them will succeed. This pace is going to put a lot of pressure on developers, Agarwal said.
"We're finding that the LOB folks just want to try a bunch of things," he said. "They want to get 15 apps out the door, knowing that maybe 13 will fail. They want to test them quickly and get feedback from the users and then they know that the two that succeeded are the ones that will give them the best chance in the competitive marketplace."
3. All new devtest will be done in the cloud by 2020. A bold prediction, but a logical one, Agarwal said, given customer feedback.
"There are obvious benefits for developers from leveraging the cloud," he said. "One is the agility it provides for spinning up resources to build apps. More importantly, the technology or innovation they want to use is all being delivered in the cloud these days -- which means they use the latest and greatest tools to deliver the best apps in the shortest possible time."
Among the drivers of this trend: challenging CIO budgets. "If you think about it, CIOs are spending about 30 percent of their budgets on running, operating, spinning up and managing development environments," Agarwal said. "Now they can free up a significant part of that budget, because devs can manage the process themselves in the cloud."
Exceptions to this trend are likely to be found in organizations with significant compliance requirements, data residency restrictions, or security demands, he added. For those organizations, the devtest is still going to happen in the public cloud, he said, but the apps will need to be flexible and portable, so developers can test them in the public cloud, but then easily move them to the on-premises environment.
4. Everyone is going to want to leverage artificial intelligence (AI) capabilities in their applications.
4a. Chatbot apps with natural language processing will become the norm by 2018.
"AI is going to become the new user interface," Agarwal said. "Over the next year, we're going to see developers looking for ways to get AI capabilities into their applications. But data will be king. You can write as many phenomenal algorithms as you want, but until you have the data and a significant amount of it that the AI-based apps can leverage and deliver smart insight from, that's not going to be very useful."
Along these same lines, Agarwal expects a growing number of developers to begin serious efforts around chatbots and natural language processing. "We're already seeing lots of companies putting out chatbots," he said. Oracle surprised attendees at the OpenWorld event with news that it would be getting into the chatbot business, joining companies like Facebook, Microsoft and Slack. The company plans to deliver a chatbot platform that will enable its customers to build a mobile engagement platform, Agarwal said, that will work seamlessly across mobile, Web and multiple messaging platforms.
5. By 2020 more than 20 percent of the developer community will be made up of non-traditional developers.
The number of so-called low-code developers has been growing steadily for years, so this isn't a particularly bold prediction. The trend is being powered by the same driver as No. 2: a new generation of LOB people who want to develop a Web or mobile app and quickly get it out the door.
Oracle is embracing this trend with its Application Builder Cloud Service, Agarwal pointed out. The low-code coder environment provides a drag-and-drop interface that allows users to "Rapidly create and host engaging business applications with a visual development environment right from the comfort of your browser," the Web site states.
More of these kinds of tools will be coming in the next year or so, Agarwal said, because the demand is growing. "People within marketing, customer service and HR will be able to use these low-code platforms to experiment, or to actually have real applications in production. As they drag and drop and build these apps, they'll be able to expose them as real-life applications. But a lot of it isn't necessarily about building strategic applications, but tactical apps that just help them to get things done."
6. Finally, 60 percent of IT organizations will move their critical systems management to the cloud by 2020.
Oracle is betting big on this one with the Oracle Management Cloud, a suite of integrated monitoring, management and analytics cloud services. "We've built a unified data platform," Agarwal said, "where the performance data across the Web tier, app tier and database tier and the log data being product on the servers by the VMs and the real-time user experience data -- all of it is being aggregated into one platform. And we put predictive machine learning algorithms into the infrastructure."
Posted by John K. Waters on 01/12/2017 at 6:30 PM0 comments
Researchers at Gartner dropped something of a bomb on the enterprise Java community just before the holidays in the form of a new report in which analysts claim, among other things, that Java EE is fading from relevance and those responsible for modernizing enterprise application infrastructure should "develop a strategy to deal with the obsolescence of Java EE and other three-tier application frameworks."
Entitled "Market Guide for Application Platforms," the report was authored by veteran industry watcher Anne Thomas and contributing analyst Aashish Gupta. As Gartner defines them, application platforms provide runtime environments for app logic and manage the life cycle of an app or app component. And they typically come with development, monitoring, management, and admin tools.
In their report, Thomas and Gupta allege that Java EE has not kept pace with architectural trends and digital business initiatives requiring new features and capabilities in application platforms. Those responsible for modernizing app infrastructure, they advise, should "retain Java EE servers for existing legacy applications, but use lighter-weight Java frameworks for digital business application development projects or evaluate other language platforms."
The analysts point to a decline in commercial Java EE platform revenues in 2015 as evidence of "a clear shift in the application platform market." They expect fewer than 35 percent of all new business applications to be deployed in Java EE app servers by 2019.
The report's authors do allow that Java continues to be the industry's most popular programming language, but claim that Java developers are demonstrating a clear preference for lightweight frameworks over Java EE. They also acknowledge Oracle's effort to produce a new version of Java EE with "long-overdue features," but argue that, by the time Java EE 8 is released in late 2017, it will already be two or three years behind the times.
"Java EE is not an appropriate framework for building cloud-native applications," they conclude. "Even Oracle and IBM recognize this fact. Both vendors have shifted their strategic application platform investments to PaaS and specialized platform technologies."
I heard from a lot of people in the enterprise Java community about this report. Reza Rahman, the former Oracle Java EE evangelist now leading the Java EE Guardians, said he found the quality of the research and analysis in the report "shocking."
"The most shocking is just how out of date Gartner's views of Java EE are," he told me. "They are clearly talking about technology from the J2EE era, old-school WebLogic and WebSphere, and ignoring everything that has happened in the evolution of Java EE since version 5. For years now, people have been demonstrating at conferences in front of thousands of people how Java EE is one of the most productive platforms out there. But Gartner seems to have decided to brush aside all that, ignoring all the work vendors have put into the platform. The WebSphere Liberty Profile, for example, is vastly different from the WebSphere of the J2EE days; you couldn't get a more lightweight runtime if you tried."
Rahman reminded me that the Java EE Guardians curate "surveys from trusted sources" on their Web site that track Java EE trends. "Those surveys show that Java EE and its APIs continue to be the most widely used in the industry," he said. "The claims that Gartner is making are actually contrary to the known data that we have."
Simon Maple, developer advocate at Java toolmaker ZeroTurnaround, sent me an e-mail in which he addressed several of the report's assertions. The claim that "Java EE has not kept pace with modern architectural trends," for example, is relatively meaningless, he said, when you understand that a standards-based ecosystem like the one supporting Java EE will never be as fast-changing as the non-standard alternatives. And for many people, that's a good thing.
"A standards-based approach means they are able to pick from a number of vendors who use the same model, with limited migration pain," Maple said. "Standards can also provide a sustainable future for a technology as many major organizations adopt and support them."
It's also true that Oracle's "one year of silence on the future of Java EE" was a significant, non-technical contributor to the platform's recent snail-pace evolution, he said. But that silence has been broken (thanks in no small part to the Guardians), and the technical gap between Java EE 7 and Java EE 8 is closing. More importantly, Oracle has strengthened the future of Java EE by committing to the delivery of both microservices and cloud capabilities in Java 8 and Java 9, and by unveiling the roadmap to delivery of Java EE 8 in 2017 and Java EE 9 a year later.
"This refocus to modern architectural trends and faster paced delivery will put Java EE in a much stronger position with modern needs," Maple said, "particularly when paired with standards. The delivery of individual JSRs which comprise the full Java EE version can easily be added to application servers, such as the modular IBM Liberty Profile, without the need to wait for the full umbrella version of Java EE 8 or 9. As a result, it's much faster for application servers to bring this value to market than ever before.
For what it's worth, internal sources at Oracle tell me that the company is really (no really) going to deliver the often-delayed Java EE 8 later this year, and, in fact, is putting the necessary resources behind a 2018 release of Java EE 9. If the latter happens, it would be a record for any steward of enterprise Java, past and present.
Chicago-based developer, blogger, and author Josh Juneau also thought the report missed the marked when it referred to "the obsolescence of Java EE."
"The opposite is actually happening," he said in an e-mail. "Although Oracle took a year off and delayed Java EE 8, things are coming back on track now, and we should be seeing real progress towards Java EE 8 soon. Moreover, the report leads one to believe that Java EE is not positioned very well for developing microservices or for the cloud. That is not accurate, as there are a number of great solutions for developing Java EE microservices. The key is that these APIs are not yet standardized and made part of Java EE proper. That's okay though, because in time we will work through the kinks of developing microservices and standardize on a great API. The same goes for cloud and configuration.
"Java EE moves at a slower pace than solutions from vendors such as Pivotal," Juneau added, "as it should. The point behind Java EE is not to be on the bleeding edge of technology. Rather, it is to be using solid, tried-and-true standard solutions."
Maple admits that the Gartner analysts' statement that "Java EE is not an appropriate framework for building cloud-native applications" is "a reasonable evaluation of the current Java EE position."
"However, the future releases of Java EE do consider this a key area of its future direction," he added. "Unfortunately, the report doesn't go into any depth on this future path, nor the increased pace at which Oracle aims to deliver it. I think it's irresponsible not to mention these, or take them into account when using terms like 'the obsolescence of Java EE.'"
Ondrej Mihályi, a Java EE trainer, consultant, and Senior Services Engineer at Payara Services in the Czech Republic, sent me an e-mail just before Christmas with his reaction, which started with "Wow!" and ended with his observation that the Gartner analysts "irresponsibly provide obsolete information about the Java EE platform."
"They base most of their statements on a very traditional and old-school way of building and running Java EE applications in 3-tier architecture, using Oracle WebLogic and IBM WebSphere servers as a reference," he said. "There is clearly much more in Java EE than these two, and even IBM offers another, highly modular WebSphere Liberty Profile server as an alternative to their flagship product. Other vendors and projects, like WildFly Swarm, sponsored by Red Hat, or Payara Micro, derived from Oracle-sponsored GlassFish Server, prove that Gartner's claim that 'Java EE is a framework for building three-tier client/server applications' no longer reflects the reality."
Mihályi expands his argument on his blog. He concludes it with this paragraph:
"Rather than listening to Gartner, ask architects or experts whom you trust for recommendations based on their experience -- or, simply see for yourself and compare. If you explore beyond the 'traditional' Java EE servers mentioned by Gartner, you will realize that Java EE is already suitable for designing cloud-native applications. The Java EE platform, with its full ecosystem, provides flexible ways to run applications and is easily extensible for any current trends, as well as any future trends to come."
Others have blogged about this report, including Red Hat product manager John Clingan on his "Middle-Me" blog. He offers a detailed analysis of the report, and concludes: "My primary issue with the Gartner report is that it seems to completely ignore the advancements that Java EE vendors have made beyond the traditional Java EE APIs and runtimes, nor mention the MicroProfile efforts to develop microservices APIs for traditional Java EE developers."
Prague-based Java developer Pavel Pscheidl offers "A quick reaction to hate on Java EE in Gartner report" on his blog. (It's actually not all that quick, which is good.) In his conclusion, he invites the Gartner analysts to join him for a "quick online talk." "In a matter of minutes, I can create a microservice-architecture-driven application deployable and easily scalable in the cloud," he writes. "The very thing you claim Java EE is not capable of."
I also invited Thomas and Gupta to respond to all this, but have not yet heard from them. When/if I do, I'll let you know what they have to say.
UPDATE (1/4/17): Mark Little, vice president of engineering at Red Hat and JBoss CTO, has posted a thoughtful and unique take on the Gartner report on his blog. Little allows that Java EE will likely "pass into history" eventually, but in the short-to-medium term, "it will evolve and continue to influence the next generation of technologies, just as the dinosaurs became the birds and aspects of CORBA evolved into J2EE." But he criticizes the report's lack of evidence for its assertions and failure of insight. Its authors offer "one subjective statement after another, with no real attempt to justify them," he writes. And the report "fails miserably to differentiate between Java EE as a standard and the various implementations." Another must read on this issue.
Posted by John K. Waters on 01/03/2017 at 12:30 PM0 comments
Reza Rahman delivered the opening keynote at App Dev Trends 2016 (part of Live 360!) Tuesday morning, giving attendees a deep, contextual history of enterprise Java and issuing something of a call to arms.
"If we are going to ensure the future of enterprise Java, we must remain alert, stay engaged, and participate in the community. You have to do these things anyway, of course, but it's more important now than ever. Java EE is a maturing technology. If we don't reenergize it now, as a community, the investment in this technology we have made over the years will go away."
Rahman emerged as a pivotal figure in the enterprise Java world earlier this year, starting with his departure from Oracle, where he had served as Java EE Evangelist, over concerns about what he perceived to be the company's neglect of enterprise Java. Shortly after resuming his consulting work for CapTech, a national IT management consulting firm, Rahman and a group of concerned Java community members launched the Java EE Guardians, and promptly published a petition aimed at Oracle executives.
Rahman's keynote, entitled "You Are the Future of Enterprise Java!" was an apt exploration of a dynamic technology evolution presented within the context of recent developments. It focused on what's inside Java EE 8 and how it got there, and explored the critical role Java EE and APIs currently play in maintaining the health of the entire Java and IT ecosystem.
But at a fundamental level, his presentation was about a community. "The process of defining the scope of Java EE 8 was the most community-opinion-driven process in the history of the platform," he told me in an earlier interview. "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."
To a question from a skeptical audience member about how important the Java community really is to the future of Java EE, Rahman offered a hypothetical scenario with the largely Microsoft-centric conference in mind.
"In a worst-case scenario, we -- the Java EE community -- could say, forget about Oracle and let's all just stand behind the MicroProfile project and move the technology ahead together," he said. "But imagine this happening in the Microsoft world. If Microsoft were ever to decide to divest itself from .NET -- and I'm not saying they ever would—you would have no one to respond, no one who could leverage the strength of a community to get them to change their minds.
"All of what has happened in the past year -- the founding of the Java EE Guardians and the MicroProfile, Oracle's response to our actions, etc. -- to me, is a validation that the Java ecosystem works. In fact, I'd say that this is the worst fire drill that we could have gone through, proving out what differentiates us from all the other technologies out there; that this is not an autocracy, but a dynamic system with multiple layers of control. Even with all our recent belly aching and strife, we are still fundamentally one of the strongest ecosystems around."
AppDevTrends is part of the popular Live! 360 uberconference, underway this week at Loews Royal Pacific Resort at Universal Orlando. We're running side-by-side with Visual Studio Live!, SQL Server Live!, Office/SharePoint Live!, Modern Apps Live!, and TechMentor. Videos of some of the other keynotes from the show are available here.
Be sure to say "hi" if you see me at the show, and follow the latest updates on my twitter.
Posted on 12/06/2016 at 4:13 PM0 comments
The election results are in! No, not that election. I'm talking about the 2016 Fall Executive Committee (EC) election of the Java Community Process (JCP).
Each year roughly half the seats of the 24-member EC are up for ratification/election. The EC oversees the work of the Expert Groups that define Java specifications, essentially guiding the evolution of Java. The committee picks the JSRs that will be developed, approves draft specs and final specs, approves Technology Compatibility Kit (TCK) licenses, approves maintenance revisions and occasionally defers features to new JSRs, approves transfer of maintenance duties between members, and provides guidance to the Program Management Office (PMO).
In other words, who sits on this committee matters.
"This was the strongest slate of candidates since I've been in the job," JCP chair Patrick Curran told me when I caught up with him at the Devoxx Belgium Conference last week. (Thank you, Skype.) "It was really competitive this year."
This is also the first election held under the new JCP 2.10 rules, which, among other things, created two new seats on the committee for unaffiliated individuals. The new Associate Member seats are part of an ongoing effort by the JCP to get more Java jocks involved in the process. The JCP recently introduced Associate Membership, again, aimed at individuals who want to contribute to a Java Specification Request (JSR). There's no employer approval required and Associate Members get to vote for the two new Associate EC seats.
There are now three JCP membership levels: the new Associate level; the Partner level, which is for Java User Groups and other non-profit organizations; and Full Membership, which is for "legal entities who wish to join Expert Groups, lead JSRs, and/or vote or serve on the Executive Committee."
Curran says the JCP's recent recruitment effort has drawn several hundred new members in the past few months, largely in the Associate category. Although Associate membership doesn't include full JCP benefits, it does provide developers with an opportunity to build their reputations, Curran said.
"Previously the only way to participate in the JCP and get public recognition was to be on an Expert Group," he said. "Now, Associate members who participate, say, through the Adopt-a-JSR program or their local Java User Group, can get formal recognition for their work."
The JCP, of course, is the standards-development organization for Java. The organization has been making some serious changes over the past few years through a project called JCP.Next, and the new seats were part of that effort. JCP 2.10 reclassified two the existing Elected seats to provide for this new type of EC membership. The current EC was formed through JSR 355, which merged the SE/EE EC and the ME EC. The JCP continues to wrestle with the challenge of revising the Java Specification Participation Agreement (JSPA), which Curran has called "big and scary."
Today, the EC comprises 16 Ratified Seats, 6 Elected Seats, and the 2 new Associate Seats, as well as a permanent seat held by Oracle America, the official steward of Java. The Ratified Seats are filled by Full Members nominated by the PMO; the Elected and Associate Seats are filled by members nominated by Full and Partner Members.
So who got elected this time around?
The first two Associate Members of the EC are Java champion and enterprise software architect Ivar Grimstad, who is a member of the Expert Group for JSR 368 and JSR 372, and a member of the NetBeans dream team; and software architect and designer Werner Keil, who serves as senior test automation engineer at ING-DiBa, and who has contributed his insights to this blog more than once.
I reached out to EC member and London Java User Group leader Martijn Verburg, whose organization was also re-elected this year. I asked him about the EC's goals for the coming year, and he got back to me via e-mail.
"Our next immediate goal is to work with Oracle and OpenJDK to better align the open source model of development that is Java today (where everything is out in the open) with the requirements of the standards body (needing point in time specifications for purposes of IP flow as much as anything else)," he said. "There have already been some useful early stage discussions, but we'll have to wait for a few weeks before we can publicly comment. This will be an important step to helping Java get released more often."
The complete election results are available online here.
Last year I talked with Patrick Curran about the JCP, and one of his comments bears repeating here:
"The strength of the JCP is the fundamentally simple model of a group of interested experts defining specifications through a formal process that includes public review and oversight by an Executive Committee (EC). The process has always been flexible enough not to define exactly how the Expert Groups should do their work. This has permitted a natural evolution (with a little help and direction from the EC in the form of revisions to the Process) from the early days of relatively private deliberations by representatives of large corporations to the current, much more open and collaborative model. It's a Community Process, and that's its strength."
Posted by John K. Waters on 11/15/2016 at 3:52 PM0 comments