DZone/Java EE Guardians Survey Results: Standards and Innovation
As some of you are aware, the Java EE Guardians and DZone jointly conducted a community survey to help determine Java EE 8 features prior to JavaOne 2016. You may also be aware that we shared the results of that survey with Oracle before the details of the renewed Java EE 8 scope was announced. Now is a great time to start analyzing those results a bit more. I've already done a high level summary of the results. I've also done a deeper dive into the responses for HTTP/2 and Servlet 4, Java SE 8 alignment as well as Java EE security.
Besides simply asking about Java EE 8 features, we asked a number of fundamental questions towards the end of the survey that go to the core of Java EE itself. In this entry and a subsequent few others I am going to take a closer look at some of these questions. I'll then return back to looking at the more mundane Java EE 8 feature specific questions. It will be clear in a few weeks why this change of order is important at the moment.
The Question
One of the most important fundamental questions we asked is around the complex relationship between standards and innovation. This question and its responses deserve a particularly in-depth look.
Here is how we phrased the question:
"Innovation and standardization is a tricky balance. Standards are pervasive, heavily relied upon and often strongly backwards compatible. For these reasons standards generally only include clearly proven ideas and avoid unproven ones. One can argue EJB 2 Entity Beans were an unproven innovation that was standardized too quickly. The Java EE ecosystem can always innovate ideas that are later standardized when proven.
That being said, standardization is an engineering activity and inevitably includes some level of innovation. It may also be the case that Java EE is different in terms of an open standard as it heavily competes with non-standard technologies.
How should Java EE approach innovation?".
The Results
The following graphic shows how the community responded. It's not realistic to think there would be a simple answer to a pretty complex question, but there are clear patterns. The most number of respondents (43%) essentially agreed with long-standing Java EE expert group consensus. Specifically this means taking a relatively conservative, organic approach to standardization. A further 14% favored a very conservative approach to standardization, forming a significant but not overwhelming majority. About 21% respondents had essentially the opposite view, equating Java EE with non-standard products. For context, this would basically mean standardizing features in products that are rarely used even by their own users. A further 23% favored a slightly more conservative approach that is still OK with standardizing ideas that are yet unproven. For context, these are most concepts that would very likely be considered Hype-Driven Development (HDD) by most ordinary developers in the blue collar enterprise (the very readable, extremely unassuming and sensible HDD write-up tellingly includes microservices and reactive programming as prominent examples; if you haven't done so already, I highly recommend reading the linked article).
People that put in comments for the most part supported the existing Java EE approach to standardization. Here is a representative sample:
To understand the real significance of the current implicitly conservative approach to Java EE standardization, it is important to have some context.
I don't think it surprises ordinary enterprise developers that technology vendors do not behave very responsibly when it comes to hype. Although there are a few brave souls, many do not have the correct incentives to self-regulate responsibly against hype. Even the ones that actually do have some good intentions are often slaves to their own egos, groupthink and isolation from down-to-earth blue collar enterprise development. Indeed grossly exaggerating the real world applicability (and consequent profitability) for startup(ish) ideas has become a such a habitual problem in Silicon Valley in recent years that it has long been hard to find companies that don't do it (if you haven't read the book "Disrupted" I highly recommend you do it soon). Quite frankly typical conference speakers, self-declared "industry analysts/thought leaders/opinion makers" and a certain class of consultants aren't any better at any of this either.
As the Hype-Driven Development writeup author correctly points out, the ultimate safeguard against hype is ethical, responsible, business-value-focused developers that see the wasted effort, inflated costs, ongoing maintenance complexity and outright project failures that constantly chasing hype causes. Open standards, as an insulator between end-users and vendors have an important role to play as well. Indeed the many non-vendor independents in Java EE JSRs that I've had the honor to work alongside for years have long guarded carefully against hype. They understand well that guarding against hype and promoting long-term stability/simplicity is one of the most valuable things open standards can uniquely provide by encouraging direct early participation from real end-users as key stakeholders in Java EE expert groups. It is no coincidence that the worst standardization mistakes in Java occurred in the J2EE era when expert groups were almost exclusively vendor dominated. EJB 2 Entity Beans and an overzealous emphasis on EJB remoting/distributed objects were the key HDD ingredients of their day (indeed there are far too many stark parallels between distributed objects and microservices - it's almost as though our industry is choosing to stubbornly forget the hard-earned lessons of the past :-)).
Often the only real way of getting things right is taking the lessons of past mistakes to heart. I think for many years now that has been true of Java EE. Most of the key changes in Java EE 5, Java EE 6 and Java EE 7 have been about standardizing ideas that have already been reasonably established. This includes standardizing JPA based on Hibernate, TopLink and JDO, standardizing CDI based on Seam, standardizing Bean Validation based on Hibernate Validator and standardizing JSF features based on RichFaces, PrimeFaces, OmniFaces, Seam Faces and DeltaSpike. The great lesson Rails had to teach Java EE is that it is OK to be a highly opinionated framework that wholeheartedly embraces the integrated platform concept and convention-over-configuration. Java EE 5 took those lessons to heart and frankly the Java EE community still enjoys the real benefits of those changes in a way few other communities do even today (and as many of us understood from the start neither Ruby nor Rails "took over the world" but instead found their own comfortable space for success; many of us in the Java EE community view Node.js in the same light today despite the tiresome hype now).
There have of course been some well-vetted organic innovations in Java EE as well. Examples include using annotations as metadata in EJB 3, declarative style service endpoints in JAX-WS, JAX-RS and WebSocket, CDI @Observer, @Stereotype, @Decorator and InjectionPoints as well as EJB 3 @Asynchronous and @Schedule. Some of us find it more than a bit ironic that many of these changes are actually quietly adopted later by frameworks that position themselves as rivals of Java EE but simultaneously claim a veritable monopoly on innovation in server-side Java...
By contrast there has been hype that the Java EE expert group has chosen to bypass, I think for the better. SOA is a fairly clear example. Even at the height of SOA hype, Java EE essentially kept SOA specific features at arm's length, limiting it to the basic ability to publish SOAP endpoints using JAX-WS. Thankfully Java EE never over-reached into the inevitable quagmire of ESBs, enterprise integration frameworks or the WS-* family of specifications. The only small step in this misguided direction ended relatively expeditiously with the pruning of JAXR in Java EE 6.
I know my saying so will not sit well with some of my fellow Java EE expert group members, but another good example is Java EE largely bypassing OSGi hype. It was obvious from the start that the complexity of the OSGi model/runtimes coupled with the complexity/needlessness of trying to modularize most real world applications was bound for failure in the blue collar enterprise (does anyone still even remember Spring Dynamic Modules or SpringSource dm Server?). Java EE ended up making no changes to try to accommodate feverish OSGi hype of the day. What happened was far more pragmatic. With the notable (and unfortunate) exception of WebLogic, Java EE vendors modularized their runtimes instead - performing a very difficult ground-up rewrite few other non-trivial software projects would have likely survived. I think a particularly brave shining examples of this is WebSphere Liberty. IBM could have just stopped at embracing the Web Profile via WebSphere Classic. Instead they chose to simultaneously embrace the Web Profile, a total rewrite and ground-up modularity via WebSphere Liberty.
This complex and nuanced context is why some of us raised an eyebrow when we saw some of Oracle's Java EE 9 ideas. Frankly it is the reason the question on innovation and standardization showed up in the survey at all. Some of the Java EE 9 proposals look more along the lines of the past mistakes made in the name of vendor-driven innovation/time-to-market concerns of the J2EE era than the more measured, community-driven standardization of the Java EE era. Conversely, this is also why most Java EE folks see the critical value in the MicroProfile effort and projects like WildFly Swarm that innovate with Java EE and serve as pipelines for standardization of proven concepts.
Java EE as an Enabler of Innovation
This discussion will not be complete without some understanding of the fact that Java EE does far more than simply passively standardize proven changes. Java EE actually seeks to enable innovation in more fundamental ways than most seem to know or wish to acknowledge.
There is a curious charge out there that Java EE somehow discourages innovation by insisting that developers only use standard APIs and only the platform. At best this is a grossly outdated idea that persists from the J2EE era fueled by ignorance. At worst it is a bit of deliberately designed anti-competitive propaganda.
The reality is that Java EE has long done it's best to promote innovations through plug-ins, extensions and conservative standardization. Every expert group in virtually every Java EE JSR works hard to make sure Java EE APIs have ample extension points that both the community and vendors can use. Some obvious examples include the CDI portable extensions API, CDI interceptors, Servlet filters/listeners, JAX-RS interceptors/filters, JPA unwrap methods, the JSF component model, the WebSocket programmatic API, WebSocket encoders/decoders, Bean Validation custom constraints, JCA connectors and many more. The clearest message of the active encouragement of ecosystem innovation that builds on the platform comes from the very charter of Java EE from years past now:
"It would not be appropriate for the Java EE platform to grow without bound to include all the interesting and useful technologies desired by web and enterprise application developers. Instead, we believe it is desirable to enable more of these technologies to cleanly layer on or plug in to Java EE application servers. By adding more extensibility points and more service provider interfaces, these other technologies can plug in to platform implementations cleanly and efficiently, and be just as easy to use for developers as the facilities that are built into the platform".
These are the capabilities and underlying philosophy that powers projects like Seam, Arquillian, DeltaSpike, PrimeFaces, OmniFaces and so many more. Indeed these capabilities power the very products that aim to position themselves as alternatives to Java EE.
The Java EE platform goes farther than simply provide extensions. It has long been the case that almost every Java EE API is also available outside the platform in a standalone fashion. This is the case despite the fact that these APIs target Java EE in their JSR charter, closely integrate with other Java EE APIs, coordinate heavily with the Java EE expert group both in terms of schedule as well as content and are often directly funded/staffed by product teams that provide commercial implementations of the Java EE platform rather than an individual API. These standalone parts of Java EE can be used basically in any way anyone can imagine. This takes substantive hard work and real investments that even the most aggressive competitors to Java EE can and do routinely take advantage of. A good friend and fellow Java EE expert group member once asked me "why do we do this to ourselves?". The answer is that it is the right thing to do in order to promote innovation and extend the value of Java EE to the ecosystem far beyond the boundaries of just those folks that embrace Java EE as a cohesive platform. The hope of course is that some of the resulting innovation would make it's way back to the platform. There is no other platform, standard or otherwise, that goes to such lengths to empower innovation in a very broad ecosystem. Failing to properly acknowledge these facts does serious disfavors to the very ecosystem that benefits from Java EE.
I do hope this post serves as food for thought in the complex topic of Java EE, standards and innovation. Please do stay tuned as I further look at a few more similarly fundamental topics in the survey. In addition to my write-up, I would encourage you to look at the survey results yourself and get involved in Java EE. You can certainly do so by becoming a part of the Java EE Guardians.
Besides simply asking about Java EE 8 features, we asked a number of fundamental questions towards the end of the survey that go to the core of Java EE itself. In this entry and a subsequent few others I am going to take a closer look at some of these questions. I'll then return back to looking at the more mundane Java EE 8 feature specific questions. It will be clear in a few weeks why this change of order is important at the moment.
The Question
One of the most important fundamental questions we asked is around the complex relationship between standards and innovation. This question and its responses deserve a particularly in-depth look.
Here is how we phrased the question:
"Innovation and standardization is a tricky balance. Standards are pervasive, heavily relied upon and often strongly backwards compatible. For these reasons standards generally only include clearly proven ideas and avoid unproven ones. One can argue EJB 2 Entity Beans were an unproven innovation that was standardized too quickly. The Java EE ecosystem can always innovate ideas that are later standardized when proven.
That being said, standardization is an engineering activity and inevitably includes some level of innovation. It may also be the case that Java EE is different in terms of an open standard as it heavily competes with non-standard technologies.
How should Java EE approach innovation?".
The Results
The following graphic shows how the community responded. It's not realistic to think there would be a simple answer to a pretty complex question, but there are clear patterns. The most number of respondents (43%) essentially agreed with long-standing Java EE expert group consensus. Specifically this means taking a relatively conservative, organic approach to standardization. A further 14% favored a very conservative approach to standardization, forming a significant but not overwhelming majority. About 21% respondents had essentially the opposite view, equating Java EE with non-standard products. For context, this would basically mean standardizing features in products that are rarely used even by their own users. A further 23% favored a slightly more conservative approach that is still OK with standardizing ideas that are yet unproven. For context, these are most concepts that would very likely be considered Hype-Driven Development (HDD) by most ordinary developers in the blue collar enterprise (the very readable, extremely unassuming and sensible HDD write-up tellingly includes microservices and reactive programming as prominent examples; if you haven't done so already, I highly recommend reading the linked article).
- "Focus on reliability and long-term planning, Java is the backbone of many enterprises"
- "I do not believe that Java EE should introduce any wildly new concepts or approaches"
- "Stability is way more important than college kids' untested and unproven ideas"
- "Considering the purpose of Java EE in the first place, only those innovations should be considered that reduce bugs, increase stability, keep backward compatibility and reduce cost"
- "The most valuable thing about Java is that it's backwards compatible, so innovations should be standardized very carefully. Innovations are to be provided by libraries, frameworks, etc"
- "I firmly believe in Java EE as a robust, reliable, base stack upon which to build the rest of your tech stack. As such, I don't really think innovation should be seen much in it's purvey. Let third party libraries, frameworks, and vendor-specific features take charge of innovation. Meanwhile, the Java EE specs should keep making sure to standardize as much of the proven ideas as possible to allow communities to disengage from specific implementations as much as possible"
- "I see standardization as a final step of a lengthy engineering process. Changing a standard after it gets established is always difficult and if it is frequently required, it'll be quite counterproductive"
- "Since standards are there to last at least for a few years, I prefer a more conservative approach"
- "It is important for Java EE to try to limit it's scope only to proven ideas and make them standards. For all other ideas there is always the possibility to evolve as open projects and once they prove they are good Java EE can adopt them"
- "Our industry is full of hype, it is a decease. Java EE should be free from it"
- "Let the industry innovate...then standardize later. Don't discourage the use of non-standard libraries"
- "For me, standardization is a refining activity, which means to take the best approaches and bind them together in a way that makes sense and eases developers' work. Innovation for innovation's sake is not worth the effort since it takes resources away from other areas that need improvement"
- "Java EE should be conservative"
- "Innovations may be provided by vendors, no need to standardize them"
- "One of the selling points for Java EE is the stability and robustness. If we start to introduce the innovation-of-the-day into Java EE, then we will threaten that stability"
- "There can be innovation on top of Java EE. Once they are proven - and if found necessary - they can be included as standards later on"
- "I'm all for new ideas, but if they're going to make it into Java EE, the reason needs to be that people actually need them. Not just because X is the latest buzzword"
To understand the real significance of the current implicitly conservative approach to Java EE standardization, it is important to have some context.
I don't think it surprises ordinary enterprise developers that technology vendors do not behave very responsibly when it comes to hype. Although there are a few brave souls, many do not have the correct incentives to self-regulate responsibly against hype. Even the ones that actually do have some good intentions are often slaves to their own egos, groupthink and isolation from down-to-earth blue collar enterprise development. Indeed grossly exaggerating the real world applicability (and consequent profitability) for startup(ish) ideas has become a such a habitual problem in Silicon Valley in recent years that it has long been hard to find companies that don't do it (if you haven't read the book "Disrupted" I highly recommend you do it soon). Quite frankly typical conference speakers, self-declared "industry analysts/thought leaders/opinion makers" and a certain class of consultants aren't any better at any of this either.
As the Hype-Driven Development writeup author correctly points out, the ultimate safeguard against hype is ethical, responsible, business-value-focused developers that see the wasted effort, inflated costs, ongoing maintenance complexity and outright project failures that constantly chasing hype causes. Open standards, as an insulator between end-users and vendors have an important role to play as well. Indeed the many non-vendor independents in Java EE JSRs that I've had the honor to work alongside for years have long guarded carefully against hype. They understand well that guarding against hype and promoting long-term stability/simplicity is one of the most valuable things open standards can uniquely provide by encouraging direct early participation from real end-users as key stakeholders in Java EE expert groups. It is no coincidence that the worst standardization mistakes in Java occurred in the J2EE era when expert groups were almost exclusively vendor dominated. EJB 2 Entity Beans and an overzealous emphasis on EJB remoting/distributed objects were the key HDD ingredients of their day (indeed there are far too many stark parallels between distributed objects and microservices - it's almost as though our industry is choosing to stubbornly forget the hard-earned lessons of the past :-)).
Often the only real way of getting things right is taking the lessons of past mistakes to heart. I think for many years now that has been true of Java EE. Most of the key changes in Java EE 5, Java EE 6 and Java EE 7 have been about standardizing ideas that have already been reasonably established. This includes standardizing JPA based on Hibernate, TopLink and JDO, standardizing CDI based on Seam, standardizing Bean Validation based on Hibernate Validator and standardizing JSF features based on RichFaces, PrimeFaces, OmniFaces, Seam Faces and DeltaSpike. The great lesson Rails had to teach Java EE is that it is OK to be a highly opinionated framework that wholeheartedly embraces the integrated platform concept and convention-over-configuration. Java EE 5 took those lessons to heart and frankly the Java EE community still enjoys the real benefits of those changes in a way few other communities do even today (and as many of us understood from the start neither Ruby nor Rails "took over the world" but instead found their own comfortable space for success; many of us in the Java EE community view Node.js in the same light today despite the tiresome hype now).
There have of course been some well-vetted organic innovations in Java EE as well. Examples include using annotations as metadata in EJB 3, declarative style service endpoints in JAX-WS, JAX-RS and WebSocket, CDI @Observer, @Stereotype, @Decorator and InjectionPoints as well as EJB 3 @Asynchronous and @Schedule. Some of us find it more than a bit ironic that many of these changes are actually quietly adopted later by frameworks that position themselves as rivals of Java EE but simultaneously claim a veritable monopoly on innovation in server-side Java...
By contrast there has been hype that the Java EE expert group has chosen to bypass, I think for the better. SOA is a fairly clear example. Even at the height of SOA hype, Java EE essentially kept SOA specific features at arm's length, limiting it to the basic ability to publish SOAP endpoints using JAX-WS. Thankfully Java EE never over-reached into the inevitable quagmire of ESBs, enterprise integration frameworks or the WS-* family of specifications. The only small step in this misguided direction ended relatively expeditiously with the pruning of JAXR in Java EE 6.
I know my saying so will not sit well with some of my fellow Java EE expert group members, but another good example is Java EE largely bypassing OSGi hype. It was obvious from the start that the complexity of the OSGi model/runtimes coupled with the complexity/needlessness of trying to modularize most real world applications was bound for failure in the blue collar enterprise (does anyone still even remember Spring Dynamic Modules or SpringSource dm Server?). Java EE ended up making no changes to try to accommodate feverish OSGi hype of the day. What happened was far more pragmatic. With the notable (and unfortunate) exception of WebLogic, Java EE vendors modularized their runtimes instead - performing a very difficult ground-up rewrite few other non-trivial software projects would have likely survived. I think a particularly brave shining examples of this is WebSphere Liberty. IBM could have just stopped at embracing the Web Profile via WebSphere Classic. Instead they chose to simultaneously embrace the Web Profile, a total rewrite and ground-up modularity via WebSphere Liberty.
This complex and nuanced context is why some of us raised an eyebrow when we saw some of Oracle's Java EE 9 ideas. Frankly it is the reason the question on innovation and standardization showed up in the survey at all. Some of the Java EE 9 proposals look more along the lines of the past mistakes made in the name of vendor-driven innovation/time-to-market concerns of the J2EE era than the more measured, community-driven standardization of the Java EE era. Conversely, this is also why most Java EE folks see the critical value in the MicroProfile effort and projects like WildFly Swarm that innovate with Java EE and serve as pipelines for standardization of proven concepts.
Java EE as an Enabler of Innovation
This discussion will not be complete without some understanding of the fact that Java EE does far more than simply passively standardize proven changes. Java EE actually seeks to enable innovation in more fundamental ways than most seem to know or wish to acknowledge.
There is a curious charge out there that Java EE somehow discourages innovation by insisting that developers only use standard APIs and only the platform. At best this is a grossly outdated idea that persists from the J2EE era fueled by ignorance. At worst it is a bit of deliberately designed anti-competitive propaganda.
The reality is that Java EE has long done it's best to promote innovations through plug-ins, extensions and conservative standardization. Every expert group in virtually every Java EE JSR works hard to make sure Java EE APIs have ample extension points that both the community and vendors can use. Some obvious examples include the CDI portable extensions API, CDI interceptors, Servlet filters/listeners, JAX-RS interceptors/filters, JPA unwrap methods, the JSF component model, the WebSocket programmatic API, WebSocket encoders/decoders, Bean Validation custom constraints, JCA connectors and many more. The clearest message of the active encouragement of ecosystem innovation that builds on the platform comes from the very charter of Java EE from years past now:
"It would not be appropriate for the Java EE platform to grow without bound to include all the interesting and useful technologies desired by web and enterprise application developers. Instead, we believe it is desirable to enable more of these technologies to cleanly layer on or plug in to Java EE application servers. By adding more extensibility points and more service provider interfaces, these other technologies can plug in to platform implementations cleanly and efficiently, and be just as easy to use for developers as the facilities that are built into the platform".
These are the capabilities and underlying philosophy that powers projects like Seam, Arquillian, DeltaSpike, PrimeFaces, OmniFaces and so many more. Indeed these capabilities power the very products that aim to position themselves as alternatives to Java EE.
The Java EE platform goes farther than simply provide extensions. It has long been the case that almost every Java EE API is also available outside the platform in a standalone fashion. This is the case despite the fact that these APIs target Java EE in their JSR charter, closely integrate with other Java EE APIs, coordinate heavily with the Java EE expert group both in terms of schedule as well as content and are often directly funded/staffed by product teams that provide commercial implementations of the Java EE platform rather than an individual API. These standalone parts of Java EE can be used basically in any way anyone can imagine. This takes substantive hard work and real investments that even the most aggressive competitors to Java EE can and do routinely take advantage of. A good friend and fellow Java EE expert group member once asked me "why do we do this to ourselves?". The answer is that it is the right thing to do in order to promote innovation and extend the value of Java EE to the ecosystem far beyond the boundaries of just those folks that embrace Java EE as a cohesive platform. The hope of course is that some of the resulting innovation would make it's way back to the platform. There is no other platform, standard or otherwise, that goes to such lengths to empower innovation in a very broad ecosystem. Failing to properly acknowledge these facts does serious disfavors to the very ecosystem that benefits from Java EE.
I do hope this post serves as food for thought in the complex topic of Java EE, standards and innovation. Please do stay tuned as I further look at a few more similarly fundamental topics in the survey. In addition to my write-up, I would encourage you to look at the survey results yourself and get involved in Java EE. You can certainly do so by becoming a part of the Java EE Guardians.
Posted by Reza Rahman
at 6:04 PM
0 Comments:
Post a Comment
<< Home