Country,"How important is it to bring HTTP/2 support to Java EE?:HTTP/2 Support The much awaited HTTP/2 standard is now complete, was fifteen years in the making and promises to radically speed up the entire web through a series of fundamental protocol optimizations. Servlet 4 is the primary vehicle to bring HTTP/2 to server-side Java. Beyond Servlet 4, higher level server-side Java web frameworks like JSF can also take advantage of HTTP/2 to significantly improve performance.","Comments::HTTP/2 Support The much awaited HTTP/2 standard is now complete, was fifteen years in the making and promises to radically speed up the entire web through a series of fundamental protocol optimizations. Servlet 4 is the primary vehicle to bring HTTP/2 to server-side Java. Beyond Servlet 4, higher level server-side Java web frameworks like JSF can also take advantage of HTTP/2 to significantly improve performance.","How important is it to fully align Java EE with Java SE 8?:Java SE 8 Alignment Java SE 8 brings a bounty of improvements - lambda expressions, the new date/time API, completable futures, streams and the fork/join common pool. Many of these features can be used with Java EE 7, but there remains many important missing pieces. In particular Java EE APIs like JPA, JMS, JSF and JAX-RS need to be adapted to make full use of repeatable annotations, the date/time API and completable futures. In addition the fork/join common pool and streams currently cannot be safely used in Java EE environments.  ","Comments::Java SE 8 Alignment Java SE 8 brings a bounty of improvements - lambda expressions, the new date/time API, completable futures, streams and the fork/join common pool. Many of these features can be used with Java EE 7, but there remains many important missing pieces. In particular Java EE APIs like JPA, JMS, JSF and JAX-RS need to be adapted to make full use of repeatable annotations, the date/time API and completable futures. In addition the fork/join common pool and streams currently cannot be safely used in Java EE environments.  ","How important is it to revamp the Java EE security API?:Security Java EE security is one of the last areas left to be revamped in the way most other APIs such as EJB have been changed radically. As a result Java EE security is still very highly dependent on things like vendor specific GUI console wizards. Pluggability, extensibility and customization is also currently very difficult when the security features that come with the application server prove insufficient. This situation is the primary driver for the proliferation of third-party security frameworks in server-side Java. The Java EE Security API has been slated to solve these issues in Java EE 8. As an example securing a Java EE application could be as simple as writing the following annotation:    @DataBaseIdentityStore(      lookup=""java:app/MyDB"",       userQuery=""SELECT password FROM principals WHERE username=?"",       rolesQuery=""SELECT role FROM roles where username=?"", ...)","Comments::Security Java EE security is one of the last areas left to be revamped in the way most other APIs such as EJB have been changed radically. As a result Java EE security is still very highly dependent on things like vendor specific GUI console wizards. Pluggability, extensibility and customization is also currently very difficult when the security features that come with the application server prove insufficient. This situation is the primary driver for the proliferation of third-party security frameworks in server-side Java. The Java EE Security API has been slated to solve these issues in Java EE 8. As an example securing a Java EE application could be as simple as writing the following annotation:    @DataBaseIdentityStore(      lookup=""java:app/MyDB"",       userQuery=""SELECT password FROM principals WHERE username=?"",       rolesQuery=""SELECT role FROM roles where username=?"", ...)","How important is it to completely eliminate EJB in favor of CDI based services?:Eliminating EJB Java EE currently has two principal component models - EJB and CDI. CDI is newer and focuses on dependency injection. EJB is older and focuses on services such as transactions, role based security, asynchronous processing, scheduling and JMS message processing. It is possible to eliminate the EJB API and rewrite these services using CDI inside more specialized Java EE APIs such as JMS, Java EE Security and the Java EE Concurrency Utilities. In the process these services could also be modernized at least in terms of syntax if not features. This was done with the @Transactional annotation in JTA 1.1 but many services still remain inside the older EJB API as of Java EE 7","Comments::Eliminating EJB Java EE currently has two principal component models - EJB and CDI. CDI is newer and focuses on dependency injection. EJB is older and focuses on services such as transactions, role based security, asynchronous processing, scheduling and JMS message processing. It is possible to eliminate the EJB API and rewrite these services using CDI inside more specialized Java EE APIs such as JMS, Java EE Security and the Java EE Concurrency Utilities. In the process these services could also be modernized at least in terms of syntax if not features. This was done with the @Transactional annotation in JTA 1.1 but many services still remain inside the older EJB API as of Java EE 7",How important is it to strengthen JSON support in Java EE?:JSON Support JSON has replaced XML as the de-facto data interchange format. Java EE has long had excellent support for XML through JAXP and JAXB. On the other hand Java EE 7 includes only a very basic programmatic API similar to JAXP named JSON-P. Java EE 8 has been slated to include a minor update to JSON-P that incorporates the latest JSON standards such as JSON Pointer. In addition a higher level annotation based API similar to JAXB named JSON-B has been targeted for Java EE 8.,Comments::JSON Support JSON has replaced XML as the de-facto data interchange format. Java EE has long had excellent support for XML through JAXP and JAXB. On the other hand Java EE 7 includes only a very basic programmatic API similar to JAXP named JSON-P. Java EE 8 has been slated to include a minor update to JSON-P that incorporates the latest JSON standards such as JSON Pointer. In addition a higher level annotation based API similar to JAXB named JSON-B has been targeted for Java EE 8.,"How important is it to include JCache in Java EE?:JCache JCache is a long awaited Java standard for distributed caching. Including JCache in Java EE will mean the platform will come with distributed caching solutions built-in, with pluggability options much like JPA providers as well as CDI based ease of use integrations into Java EE. Other Java EE APIs like JPA can also fully integrate JCache, for example for second-level caching.","Comments::JCache JCache is a long awaited Java standard for distributed caching. Including JCache in Java EE will mean the platform will come with distributed caching solutions built-in, with pluggability options much like JPA providers as well as CDI based ease of use integrations into Java EE. Other Java EE APIs like JPA can also fully integrate JCache, for example for second-level caching.",Comments::A New MVC Framework A new MVC framework is targeted for Java EE 8. Unlike JSF this framework is action-oriented. One key benefit of action-oriented frameworks is that they are easier to integrate with JavaScript tools such as AngularJS and jQuery. On the other hand action-oriented frameworks tend to be lower-level and do not naturally support component libraries like PrimeFaces.,How important is it to add a new action-oriented MVC framework to Java EE?:A New MVC Framework A new MVC framework is targeted for Java EE 8. Unlike JSF this framework is action-oriented. One key benefit of action-oriented frameworks is that they are easier to integrate with JavaScript tools such as AngularJS and jQuery. On the other hand action-oriented frameworks tend to be lower-level and do not naturally support component libraries like PrimeFaces.,"How important is it to enable dynamic configuration in Java EE applications?:Dynamic Configuration The configuration of Java EE applications (such as data source configuration, application properties and DI wiring) are largely static. This means that configuration does not change after the application is built and deployed. It is possible to enable dynamic configuration in Java EE applications in addition to this existing model. Keep in mind features such as Maven profiles and property substitution are intended to change Java EE application configuration at build time. In addition it is possible to use CDI based tools such as DeltaSpike to enable dynamic configuration in Java EE applications when really needed.","Comments::Dynamic Configuration The configuration of Java EE applications (such as data source configuration, application properties and DI wiring) are largely static. This means that configuration does not change after the application is built and deployed. It is possible to enable dynamic configuration in Java EE applications in addition to this existing model. Keep in mind features such as Maven profiles and property substitution are intended to change Java EE application configuration at build time. In addition it is possible to use CDI based tools such as DeltaSpike to enable dynamic configuration in Java EE applications when really needed.",Comments::NoSQL JPA and Java EE are focused on relational databases. It is possible to attempt to standardize access to NoSQL databases in Java EE. Keep in mind tools such as Hibernate OGM enable access to some NoSQL databases using the JPA API. Because of the highly divergent nature of NoSQL databases it may also be very difficult to arrive at a standard data access API.,How important is it to standardize NoSQL database access in Java EE applications?:NoSQL JPA and Java EE are focused on relational databases. It is possible to attempt to standardize access to NoSQL databases in Java EE. Keep in mind tools such as Hibernate OGM enable access to some NoSQL databases using the JPA API. Because of the highly divergent nature of NoSQL databases it may also be very difficult to arrive at a standard data access API.,"How should Java EE approach reactive programming?:Reactive Reactive is a very broad term. It can be interpreted to mean asynchronous, event/message-driven, non-blocking programming. Although there are clear gaps, Java EE addresses these concerns at the level of each API, in an ad-hoc fashion. On the other hand there are frameworks that dedicate significant parts of their specialized API specifically to the reactive programming. It may make sense to explore such an option for Java EE. It is important to keep in mind reactive programming may not be needed for many applications and is a significantly more complex paradigm as compared with synchronous, blocking code.","Comments::Reactive Reactive is a very broad term. It can be interpreted to mean asynchronous, event/message-driven, non-blocking programming. Although there are clear gaps, Java EE addresses these concerns at the level of each API, in an ad-hoc fashion. On the other hand there are frameworks that dedicate significant parts of their specialized API specifically to the reactive programming. It may make sense to explore such an option for Java EE. It is important to keep in mind reactive programming may not be needed for many applications and is a significantly more complex paradigm as compared with synchronous, blocking code.","How should Java EE approach microservices?:Microservices Microservices is another very broad term. It can be interpreted to mean decomposing a larger logical application into smaller independently deployable subsystems. There are frameworks that claim to specialize in microservices and include features such as custom configured, self-contained executable jars (also known as “fat jars” or “uber jars”), metrics, discovery, circuit breakers and bulkheads. Java EE currently does not include such features but it may make sense to add them. It should be noted however that Java EE centric tools such as WildFly Swarm, Paraya Micro, TomEE Embedded and KumuluzEE do offer these features. Keep in mind, there are many industry thinkers like Martin Fowler that have expressed doubt whether microservices make sense for most applications. Some other industry thinkers such as Adam Bien believe Java EE is already well suited to building practical microservices.","Comments::Microservices Microservices is another very broad term. It can be interpreted to mean decomposing a larger logical application into smaller independently deployable subsystems. There are frameworks that claim to specialize in microservices and include features such as custom configured, self-contained executable jars (also known as “fat jars” or “uber jars”), metrics, discovery, circuit breakers and bulkheads. Java EE currently does not include such features but it may make sense to add them. It should be noted however that Java EE centric tools such as WildFly Swarm, Paraya Micro, TomEE Embedded and KumuluzEE do offer these features. Keep in mind, there are many industry thinkers like Martin Fowler that have expressed doubt whether microservices make sense for most applications. Some other industry thinkers such as Adam Bien believe Java EE is already well suited to building practical microservices.","How should Java EE approach innovation?:Innovation and Standards 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.","Comments::Innovation and Standards 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.","What should the release frequency for Java EE be?:Java EE Release Frequency The velocity of standards is a delicate balance. Standards involve broad collaboration through an open process, which takes time. Pervasive standards are also heavily relied upon, widely implemented and need to avoid premature standardization. For these reasons it often makes practical sense for standards to have a slower pace. That said many developers have long expressed dissatisfaction with the pace of Java EE. It is difficult to claim this feedback does not have merit in the age of products that are released early and often.","Comments::Java EE Release Frequency The velocity of standards is a delicate balance. Standards involve broad collaboration through an open process, which takes time. Pervasive standards are also heavily relied upon, widely implemented and need to avoid premature standardization. For these reasons it often makes practical sense for standards to have a slower pace. That said many developers have long expressed dissatisfaction with the pace of Java EE. It is difficult to claim this feedback does not have merit in the age of products that are released early and often.",Comments Did we forget something important? Are you missing any features not mentioned in previous questions? Please feel free to enter any comments you would like to be heard.
India,Very important,,Very important,"Java SE 8 improves readability and performance of code in many ways, this will improve performance of java ee if aligned with SE 8 properly.",Very important,We certainly need a standard API for security.,Somewhat important,,Very important,,Very important,,,Very important,Very important,,,Important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",Micro-services offer scalabilty and other benefits. standardising these features will help new developers in getting started with it. ,"Java EE should innovate, but only very carefully.",,1-2 years,,
Kazakhstan,Important,,Not important,,Important,,I don't think we should eliminate EJB,,Very important,,Very important,,,Very important,Important,,,Somewhat important,"Reactive is merely hype, nothing should be done",,Java EE is already well suited to building practical microservices.,,"Java EE should innovate, but only very carefully.",,4-5 years,,
Germany,Very important,,Very important,,Very important,,I don't think we should eliminate EJB,,Important,,Somewhat important,,,Not important,Somewhat important,,,Somewhat important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Java EE is already well suited to building practical microservices.,,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,,
India,Very important,,Important,,Important,,Important,,Important,,Very important,,,Important,,,,Not important,"Reactive is merely hype, nothing should be done",,"Microservices is merely hype, nothing should be done.",,"Java EE should innovate, but only very carefully.",,3-4 years,,
Slovakia,Very important,,Somewhat important,,Important,,Very important,,Somewhat important,,Somewhat important,,,Not important,Not important,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,Java EE is already well suited to building practical microservices.,,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,,
Germany,Very important,,Important,,Somewhat important,,Very important,,Very important,,Very important,,,Important,Somewhat important,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,2-3 years,,
Italy,Important,,Very important,,Very important,,I don't think we should eliminate EJB,,Important,,Important,,,Important,Somewhat important,,,Somewhat important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Java EE is already well suited to building practical microservices.,,"Java EE should innovate, but only very carefully.",,3-4 years,,
Slovenia,Important,,Not important,,Not important,,I don't think we should eliminate EJB,,Important,,Very important,,,Not important,Somewhat important,,,Not important,Wait to see how well reactive is adopted in practical enterprise environments,,Java EE is already well suited to building practical microservices.,,"Java EE should innovate, but only very carefully.",,4-5 years,,
United Kingdom,Very important,,Very important,,Important,,Not important,,Very important,,Somewhat important,,,Not important,Very important,,,Somewhat important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Java EE is already well suited to building practical microservices.,,"Java EE should innovate, but only very carefully.",,2-3 years,,
Europe,Important,,Very important,,Important,,Not important,,Very important,,Important,,,Very important,Important,,,Somewhat important,"Reactive is merely hype, nothing should be done",,Java EE is already well suited to building practical microservices.,,"Java EE should innovate, but only very carefully.",,2-3 years,,
Poland,Very important,,Very important,,Important,,Not important,,Very important,,Somewhat important,,,Not important,Somewhat important,,,Important,Wait to see how well reactive is adopted in practical enterprise environments,,Java EE is already well suited to building practical microservices.,,It is OK for Java EE to standardize unproven ideas that seem promising.,,2-3 years,,
Austria,Very important,,Somewhat important,The date/time API is already supported by providers. The other Java 8 features aren't that important to be integrated for me.,Somewhat important,"I am not using Java EE Security because it's not flexible enough for my needs and I don't think the new API will be either. Since I tried using it once and knowing how complex it is, I thinks it's important to update/replace the API.",Very important,Being able to execute automated tests with just a CDI container is very nice. EJBs require a full EJB container which ships with stuff I barely need. Making EJB stuff CDI extensions is like modularizing the model which is very important. This also comes with the benefit that we can replace or adapt the behavior of aspects by binding custom interceptors.,Very important,,Very important,Long overdue,,Somewhat important,Very important,I am using proprietary features like property replacement to get configurability right now. Would be cool if dynamic reconfiguration is also supported but that's not on my list of important stuff.,I think JPA should be extended to support NoSQL. Hibernate OGM shows that this is possible and it also feels very natural.,Very important,"Reactive is merely hype, nothing should be done",Let's look at that again when Java has continuations a.k.a. fibers. When the blocking APIs can be fiberfied there might not even be a need for custom APIs anymore or at least not the same.,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.","Stop the nonsense with uber jars and let a Java EE server have ""configurations"" that let the application define what modules/specs are needed and drop the Java EE profiles. Apart from that I think it is very important to standardize things like metrics, discovery and circuit breakers as these things aren't specific to microservices but to dynamic clustered applicationso in general. Maybe it's time clustering was standardized in general.",Java EE should innovate in the same way that non-standard products do.,"I don't mind if some innovation is done within Java EE as long as everything(TCKs, RI) is opensource and individuals are able to participate.",1-2 years,I'd rather have less features released in shorter cycles than a lot released in big cycles.,
Russian Federation,Somewhat important,,Important,,Not important,,Important,,Very important,,Important,,,Very important,Somewhat important,,,Not important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,It is OK for Java EE to standardize unproven ideas that seem promising.,,3-4 years,,
Denmark,Important,,Very important,,Important,,I don't think we should eliminate EJB,,Very important,,Important,,,Important,Somewhat important,,,Important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,2-3 years,,
France,Important,,Important,,Important,,I don't think we should eliminate EJB,,Important,,Important,,,Somewhat important,Somewhat important,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,3-4 years,,
United States,Important,,Very important,,Very important,,Somewhat important,,Very important,,Somewhat important,,,Somewhat important,,,,Not important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Java EE is already well suited to building practical microservices.,"The success of the Java EE centric tools will dictate the need, or lack thereof, for standardization. ",Java EE should not standardize ideas that are not clearly proven.,,1-2 years
Spain,Important,,Very important,,Very important,,Very important,,Very important,,Important,,,Important,Not important,,,Not important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Wait to see how well microservices is adopted in practical enterprise environments.,,Java EE should not standardize ideas that are not clearly proven.,,1-2 years
Germany,Very important,,Important,,Somewhat important,,I don't think we should eliminate EJB,,Very important,,Very important,,,Very important,Somewhat important,,,Very important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years
Pakistan,Important,,Very important,,Very important,,Very important,,Very important,,Very important,,,Very important,Somewhat important,,,Important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,Java EE should not standardize ideas that are not clearly proven.,,4-5 years
Netherlands,Very important,,Very important,,Somewhat important,The most annoying thing about the current security API is using Strings to identify roles - repeating the same names all over the place is error prone. I hope they replace it with something that can be checked at compile time.,Somewhat important,Replacing EJB 3.x with CDI completely will take some time - but that API is fairly modern. Finally actually taking out EJB 2.x crap like CMP should have a higer priority.,Very important,A JAXB equivalent for JSON is sorely needed.,Not important,,,Not important,Somewhat important,"We already roll our own solution for dynamic configuration, but a built-in standard would be a nice to have.",,Not important,Wait to see how well reactive is adopted in practical enterprise environments,,Java EE is already well suited to building practical microservices.,Java EE should remove support for legacy crap like EJB 2.x/CMP from the specs so implementations can be more lightweight. Or maybe introduce a new medium sized profile; the current web profile unfortunately lacks some things we need.,"Java EE should innovate, but only very carefully.",,3-4 years
Netherlands,Very important,,Important,,Very important,One can not stress the importance of security!,Important,,Very important,,Important,,,Important,Important,,,Not important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should not standardize ideas that are not clearly proven.,,1-2 years
Macedonia,Very important,,Somewhat important,,Important,,Somewhat important,,Somewhat important,,Very important,,,Somewhat important,Very important,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,3-4 years
Algeria,Very important,,Important,,Very important,,Somewhat important,,Important,,Important,,,Very important,Very important,,,Very important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,2-3 years
Spain,Important,,Important,,Very important,,Important,,Very important,,Very important,,,Important,Somewhat important,,,Very important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,It is OK for Java EE to standardize unproven ideas that seem promising.,,2-3 years
Greece,Very important,,Very important,,Very important,,Very important,,Very important,,Somewhat important,,,Important,Very important,,,Somewhat important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,1-2 years
Sweden,Very important,,Very important,,Important,,Very important,,Important,,Somewhat important,,,Very important,Important,,,Important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,2-3 years
Hungary,Somewhat important,,Important,,Very important,,Very important,,Somewhat important,,Very important,,,Important,Very important,,,Very important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,2-3 years
Spain,Very important,,Somewhat important,,Very important,,I don't think we should eliminate EJB,,Important,,Important,,,Very important,Somewhat important,,,Very important,Introduce significantly specialized Java EE APIs for reactive programming,,Java EE is already well suited to building practical microservices.,,"Java EE should innovate, but only very carefully.",,2-3 years
Israel,Important,,Important,,Somewhat important,,Somewhat important,,Very important,,Very important,,,Very important,Somewhat important,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,,,Java EE should innovate in the same way that non-standard products do.,,2-3 years
Italy,Very important,,Very important,,Important,,I don't think we should eliminate EJB,,Important,,Important,,,Somewhat important,Somewhat important,,,Important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,2-3 years
Norway,Important,,Very important,,Very important,,Not important,,Very important,,Very important,,,Very important,Somewhat important,,,Very important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",It is VERY important to improve microservices support.,Java EE should innovate in the same way that non-standard products do.,,2-3 years
Germany,Very important,,Very important,,Somewhat important,"Based on that example alone, it looks like it will be way too much in one package. An annotation that takes SQL queries to configure authentication and authorization sources? This style is why many people complain about JPA or even annotations in general. It's such a complete break of the single responsibility principle (security, database access, everything in-between) that you could use it as a textbook example.",Important,"This is a pretty fundamental decision. There should really be no mixed state because then the different EE APIs might not work well together then. Everything EJB or everything CDI, but please no incoherent transitional state.",Not important,There are already established solutions to this. Why not for once make the Java APIs configurable and let me choose the way JSON is created and parsed? Spring proves that with CDI this is a matter of creating two beans for injection.,Important,,,Somewhat important,Very important,,,Important,Introduce significantly specialized Java EE APIs for reactive programming,The Reactive Streams API is scheduled for Java 9 and should be compatible to EE APIs. It is already adopted by most reactive frameworks and would allow for great interoperability.,Wait to see how well microservices is adopted in practical enterprise environments.,"As the development goes right now, it might make sense to develop Java EE into a PaaS API standard for EE 9 or 10. This would turn metrics, discovery, etc. into intermediary technologies that can be skipped for now, concentrating on other pressing matters.","Java EE should innovate, but only very carefully.","With the current process, innovation is difficult. If EE were to be split up into different profiles, one or more could be used for innovating on new ideas and receive updates between the main releases for the fully standardized ""standard EE"" profiles.",2-3 years,"As said before in 13, I believe it makes sense to split this up. Different profiles means that companies can use new, exciting technologies on new projects for fast innovation or proven concepts that are guaranteed to be stable for large, long-running projects. Furthermore, they can switch during a project's lifetime while remaining in the EE world. This is again one of the fields where Spring excels with modularity and a choice between release trains.",
Ukraine,Important,,Very important,,Somewhat important,,Important,,Very important,,Somewhat important,,,Very important,Important,,,Not important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,,
"Iran, Islamic Republic of",Very important,,Very important,,Somewhat important,,Very important,,Important,,Very important,,,Very important,Not important,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,,,2-3 years,,
Philippines,Important,,Very important,Java SE 8 APIs are great,Very important,Should also provide @JpaBaseIdentityStore,Somewhat important,This should be done gradually or at least give developers enough time to migrate their code bases,Important,,Somewhat important,,Front-end using JavaScript frameworks can use JAXRS as back-end.,Not important,Somewhat important,,"If possible, please align with JPA",Important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,1-2 years,Have more restrictions on what can be considered as a standard. Then focus on a limited set of standards/features per release.,
Belgium,Very important,"Everyone has to migrate soon or now in HTTP/2, it's our future..",Somewhat important,,Very important,The security is a core characteristic of JAVA ,Important,"For many reason (like to run my app on a light server app like Tomcat), I have abandonned EJB to Dependecy Injection of Spring (@Autowired in place of @Inject). For me EJB architecture is a revolution, but it force us to use a EE server app.",Very important,Eg. for a REST communication...,Not important,Because there are somes very good tools out there like EhCache,"I wish a better integretion of all my templates (HTML, JSP,..) and my .js files (and after minimified et uglify process) inside the war.",Important,Important,"A dynamic class loader (on demand load and reload), containers, ...",,Important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,1-2 years,The waiting is sooo long...,"- CLOUD !! - More tutorial, free books, ..."
Asia/Pacific Region,Very important,,Very important,JPA revamp is long pending JSF revamp need and has lost much of the following to React/Angular,Very important,,I don't think we should eliminate EJB,EJB should continue as deprecated to support legacy code,Very important,,Very important,,long pending but hope its easy to use,Very important,Very important,,"NoSQL is an emerging space and every vendor has a different spec, having api's for that would be good but feasibility is a quesiton",Not important,Introduce significantly specialized Java EE APIs for reactive programming,"reactive non-blocking programing is vital, look at the growth of nodejs","Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.","instead of using a multitude of third party projects, standard spec would be good for enterprises",Java EE should not standardize ideas that are not clearly proven.,"Take reliability and long term planning, java is the back bone for may enterprises",2-3 years,"reliable and stabe api needs longer thought process and planning, dont jump in with poor specs",better session management for WebSocket API
,Very important,It's important to stay up-to-date with the latest standards,Very important,"JPA should support persistence of the nre date/time API types.  I wish JPA Criteria API to be enhanced to harness lambda expressions and streams, to give Java developers an experience similar to that of LINQ + Entity Framework.",Not important,There are already nice third party libraries and CDI extensions.,I don't think we should eliminate EJB,Retrocompatibility is paramount,Somewhat important,,Important,I would like to use a distributed cahe as Web Session store.,,Somewhat important,Somewhat important,,,Not important,Wait to see how well reactive is adopted in practical enterprise environments,,Java EE is already well suited to building practical microservices.,,Java EE should not standardize ideas that are not clearly proven.,,1-2 years,,
Brazil,Important,,Somewhat important,,Very important,,Important,,Very important,,Important,,,Important,Important,,,Important,,,Wait to see how well microservices is adopted in practical enterprise environments.,,,,,,
Brazil,Very important,,Very important,,Very important,,I don't think we should eliminate EJB,,Somewhat important,We already have other libraries for JSON that are more popular.,Very important,,,Important,Important,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,2-3 years,,
Brazil,Somewhat important,,Important,,Important,,Important,,Very important,,Very important,,,Very important,Somewhat important,,,Very important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,It is OK for Java EE to standardize unproven ideas that seem promising.,,2-3 years,,
Indonesia,Very important,,Important,,Very important,,I don't think we should eliminate EJB,we've choose ejb for its speed. JMS is no match for EJB speed.,Very important,,Very important,,,Very important,Very important,,,Very important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Java EE is already well suited to building practical microservices.,,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
Switzerland,Somewhat important,,Somewhat important,,Not important,,Not important,,Important,,Very important,,,Not important,Somewhat important,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,2-3 years,,
Brazil,Very important,,Very important,,Important,,Somewhat important,,Very important,,Important,,,Very important,Very important,,,Very important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,,
Uruguay,Very important,,Very important,,Very important,,Not important,,Very important,,Important,,,Very important,Very important,,,Important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should not standardize ideas that are not clearly proven.,,2-3 years,,
Ireland,Very important,Must be usable outside of servlet api,Very important,,Very important,Hopefully the SPI and mimimal classes / interfaces being offered by jsr 375 will enable exiting open source players to build upon a robust core in an extensible standardized manner.,Very important,Ther should be only one way of doing things in platform,Very important,What about Yaml?,Very important,,,Important,Very important,JMX needs a serious revamp. Operations / managability are not defined / mandated by Java EE in a  manner that can be leveraged in real world.,,Somewhat important,Introduce significantly specialized Java EE APIs for reactive programming,Probably requires Java SE updates as well. ,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,1-2 years,,"How is modularity from java 9 going to impact EE? Appers that versioning is being left to build tools / ides and is a run time problem and not being addressed. More functional prog concepts. Less boilerplate e.g. autovalue / lombok. Testability support baked in, this is are where spring excels. Full community involvement to drive JSR and fully open tck / licenses. No mention of cloud  / container apis. Must be multi tenant aware.  Improving efficency of Java SE / EE within containers. Adoption of ICU4J? More regular unicode updates. TLS / cipher and related updates."
Germany,Important,,Very important,,Important,,Somewhat important,,Very important,,Very important,,,Somewhat important,Somewhat important,,,Not important,Wait to see how well reactive is adopted in practical enterprise environments,,Java EE is already well suited to building practical microservices.,,"Java EE should innovate, but only very carefully.",,2-3 years,,
Italy,Important,,Important,Many users syill use a Java 6 Runtime even if it is not supported.,Very important,,Somewhat important,,Somewhat important,,Somewhat important,,,Somewhat important,Somewhat important,,,Very important,Wait to see how well reactive is adopted in practical enterprise environments,Enterprise in general is not yet ready to adopt this kind of paradigm.,Java EE is already well suited to building practical microservices.,,It is OK for Java EE to standardize unproven ideas that seem promising.,,2-3 years,,
United States,Very important,,Very important,,Very important,,Very important,,Important,,Not important,,,Important,Not important,,,Not important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,1-2 years,,
Germany,Very important,,Very important,,Very important,,Somewhat important,,Very important,,Not important,"JCache is still missing features like transaction support to qualify it for Java EE. If that's accomplished, it could be ""Somewhat important"".",,Important,Very important,,"Hibernate OGM shows this can be done leveraging existing standards like JPA, JDO, etc.",Not important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,2-3 years,"Maybe smaller pieces should be loaded under the EE ""umbrella"", but even then a 1 year release cycle would overwhelm any real use cases having to bring it in production. Java EE still stands for ""Enterprise"" and that's where its biggest value lies. A personal homepage or small project may find other technologies more effective.",
Brazil,Very important,,Important,,Important,,Somewhat important,,Very important,,Very important,,,Somewhat important,Very important,,,Important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,Java EE should not standardize ideas that are not clearly proven.,,2-3 years,,
United States,Very important,,Very important,,Very important,,Very important,,Important,,Very important,,,Very important,Somewhat important,,,Somewhat important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,1-2 years,1 year is ok,
Turkey,Very important,,Very important,,Very important,,Very important,Java EE should have no dependency to any heavy-weight application servers.,Very important,,Very important,,,Very important,Very important,,,Very important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Microservices is merely hype, nothing should be done.","I think the main barrier for Java EE is dependency to complex application servers. It could be perfect If we can do it more modular and thin, and runnable on any simple container. However, I don't know how it conflicts with Oracle and other gamer's business plans.","Java EE should innovate, but only very carefully.",,3-4 years,,
United States,Very important,,Very important,,Very important,,Very important,,Somewhat important,,Very important,,,Not important,Important,,,Not important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,,"I'm just a Joe programmer, so my idea might be stupid. I would like to have a way to manually create servlet instances so that I can give them all the services they need via constructor (I don't want to see @Inject at the property level). In general, I don't want to have property-level @Inject."
Belgium,Somewhat important,,Important,,Very important,One of the areas where no real standardization is done yet because you always need to have Application server specific configuration,I don't think we should eliminate EJB,"EJB3 works fine for the moment, there are much more important things to do.",Important,,Important,,,Important,Somewhat important,,,Not important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Microservices is merely hype, nothing should be done.",,Java EE should not standardize ideas that are not clearly proven.,,2-3 years,,
United States,Very important,,Important,,Very important,,Somewhat important,,Very important,,Somewhat important,,,Important,Important,,,Important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,1-2 years,,
Germany,Important,,Important,,Somewhat important,,Somewhat important,,Very important,,Important,,,Somewhat important,Somewhat important,,,Very important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,2-3 years,,
Indonesia,Very important,,Somewhat important,,Somewhat important,,Very important,,Very important,,Very important,,,Somewhat important,Not important,,,Very important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,1-2 years,,
United States,Very important,"HTTP/2 is detrimental to the future of web applications, so it cannot be overlooked.",Very important,"To ease the development of Java Web Applications, it makes sense to fully align with the most current release of Java SE so all of the latest features in SE can be utilized.",Very important,,Somewhat important,"Although it is important to move forward with CDI, I do not believe EJB needs to be completely eliminated.  Both models have their own merit.",Important,"It is important to make JSON easy to utilize from Java EE, so JSON-B is an important addition to the platform.  The enhancements to JSON-P would be nice to have since they are part of the JSON standards.",Important,Including JCache in the platform would ease the burden of requiring developers to choose or implement another caching strategy.,"Although the new MVC framework brings a fresh alternative to JSF and other existing frameworks, I do not believe it is detrimental to the platform.  Since it utilizes JAX-RS as the foundation, it is very easy to learn, especially to those familiar with JAX-RS.  It is also nice to have a more flexible alternative than JSF available out of the box.",Somewhat important,Somewhat important,,"NoSQL is by all means very important to the ecosystem, but just like the MVC framework, there are alternatives available.  Therefore, I do not believe this to be detrimental to the future of Java EE, although it would be a nice feature to have standardized.",Somewhat important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Java EE is already well suited to building practical microservices.,"I believe Microservices hype will eventually die down.  However, there are some very good lessons to learn from the approach.  I believe Java EE is already well suited, but incremental improvements to help in some areas may be nice to have as time goes on.","Java EE should innovate, but only very carefully.","Tricky call to make.  In some cases it makes sense to innovate, especially if that innovation means bringing forth a significant improvement to an existing approach.  However, I do not believe that Java EE should introduce any wildly new concepts or approaches.",1-2 years,"I believe a two year release cycle seems about right, given how fast paced the technology sector moves.  ",
United States,Very important,,Very important,,Very important,,Important,,Very important,,Very important,,,Somewhat important,Somewhat important,,,Somewhat important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Java EE is already well suited to building practical microservices.,,"Java EE should innovate, but only very carefully.",,2-3 years,,Continuing to improve JSF is critical as well.
United States,Somewhat important,,Very important,,Very important,,Very important,,Very important,,Very important,,,Very important,Important,,,Important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,,
Saudi Arabia,Very important,,Very important,,Very important,,Somewhat important,,Very important,,Very important,,,Very important,Somewhat important,,,Important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,1-2 years,,
,Very important,,Very important,,Very important,,Somewhat important,,Very important,,Very important,,,Very important,Important,,,Very important,Introduce significantly specialized Java EE APIs for reactive programming,,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,2-3 years,,
Netherlands,Very important,,Important,,Important,,Somewhat important,,Important,,Important,,,Important,Somewhat important,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,2-3 years,,
,Important,,Very important,,Very important,,Important,,Very important,,Very important,,,Somewhat important,Somewhat important,,,Important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,2-3 years,,
Brazil,Important,,Somewhat important,,Not important,It's easy to implement custom and better fit solutions with CDI interceptors and decorators.,Very important,"EJB requires a full java ee container, while cdi do not. Modular is always better than monolitic.",Important,Especially for jax-rs,Somewhat important,,,Not important,Not important,"Looks like just  complexity and trouble, and such requirement is still rare to worth pay that price.",No standart in NoSQL. Doesn't worth the trouble.,Not important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,Microservices ,Java EE should not standardize ideas that are not clearly proven.,Estability is way more important than college kids untested and unproven ideas.,2-3 years,,
Brazil,Important,,Very important,,Somewhat important,,Important,,Somewhat important,,Important,,,Important,Very important,,,Somewhat important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Java EE is already well suited to building practical microservices.,,"Java EE should innovate, but only very carefully.",,1-2 years,,
Germany,Very important,Jsf is bloated,Very important,"The main problem is that JDBC drivers (even from Oracle DB) till this moment don't implement the latest version, e.g. to be able to use the new time API. This is not even an EE problem.",Very important,"the example you provide is very bad. a standard is very important, but the best solution so far is Apache Shiro : this should be the standard, not some crappy annotations.",I don't think we should eliminate EJB,,Important,,Not important,caching will never be good enough in standard implementations,"compoent oriented is better than action based, but please not the bloated and slow JSFs. something like revived Apache Click or Wicket wold be better. For JS intensive work, they have ""partials"".",Not important,Not important,"more important would be to have dynamic configuration of the Application Servers in a standard way, instead of the applications.",JPA should focus on relational and on JDBC based only. It should do this thing right however: see Grails Gorm.,Not important,"Reactive is merely hype, nothing should be done",reactive does not reduce the number of bugs in most project that adopted it.,"Microservices is merely hype, nothing should be done.","the hype it's already fading. wait a little and will be replaced with the ""next bi thing"".","Java EE should innovate, but only very carefully.","it's often hard to see what's innovation and what is just hype. considering what is the purpose of JEE in first place, only those ""innovations"" should be considered that reduce the bugs, increade the stability of the applications, keep the backward compatibility and reduce the TCO.",1-2 years,more releases with less breaking updates would be better,"the access of jvm based languages to jee would be a good innovation. many companies use already scala, clojure, groovy, etc. but only as an alternative to jee, not together inside the same jee application."
Belgium,Somewhat important,,Very important,,Somewhat important,,I don't think we should eliminate EJB,,Very important,,Very important,,,Somewhat important,Somewhat important,,,Somewhat important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Java EE is already well suited to building practical microservices.,,It is OK for Java EE to standardize unproven ideas that seem promising.,,2-3 years,,
Germany,Very important,,Very important,,Very important,,Somewhat important,,Very important,,Very important,,,Very important,Very important,,,Important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,2-3 years,,
Slovakia,Very important,,Important,,Somewhat important,,Somewhat important,,Very important,,Somewhat important,,,Very important,Not important,,,Important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,1-2 years,,
Germany,Very important,,Very important,,Important,,Somewhat important,,Very important,,Important,,,Very important,Important,,,Somewhat important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Java EE is already well suited to building practical microservices.,,"Java EE should innovate, but only very carefully.",,2-3 years,,
Spain,Very important,,Very important,,Somewhat important,,Important,,Important,,Important,"I know it's not related to JCache, but it would be very nice to plug any JCache implementation as JPA second level cache in a standard way",,Somewhat important,Not important,,"As pointed out, it might be a worthless effort.",Somewhat important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,1-2 years,Vendor implementations of new java EE versions are also very slow.,I would prefer early pruning of old features if this can speed up vendor releases
France,Important,,Very important,,Very important,,Not important,JSP should be eliminate first it is too old and ambigious for new users. ,Very important,JSON is the new standard so...,Important,,"There are already too many way to do web in Java EE, Servlet, JSF, Jax-RS... If a new framework is added, completely remove JSF before, or it will be to complicated for a new user to choose.",Not important,Somewhat important,,,Important,"Reactive is merely hype, nothing should be done",,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,It is OK for Java EE to standardize unproven ideas that seem promising.,,2-3 years,,"There are too many suff in Java EE (SE also) Before adding new features, stuffs needs to be completely removed first. When I have to deal with date, which API should I use? java.util.Date ? java.sql.Date ? Calendar? the new API ?"
Greece,Very important,,Very important,,Very important,,Somewhat important,,Important,,Very important,,,Very important,Very important,,,Important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,1-2 years,,
United States,Very important,Servlet 4 and HTTP2 are probably the most important parts of Java EE 8 for me.  Apache 2.4 and Nginx already support this.  Jetty already is including support ahead of the specification.  It is important to have this standardized.,Important,Taking full advantage of modern language features in Java SE 8 is important to me especially since other frameworks are in the process of adding full support for it now.,Very important,The role or permission assignment and  authorization Interceptors features are the most important parts of this for me.  It is painful to have to try to create different configurations or even custom code to deal with LDAP group to application roles for different scontainer I use.,Somewhat important,"Not as important to me, but it would lead to less confusion and a more streamlined specification.",Important,This is definitely a nice to have item.  It would help bring some order to the zoo of libraries for JSON in Java like Jackson and GSON.  Anything that would help standardize the behaviors of those implementations would be a good thing. ,Important,This is a common need in may deployments.  Clustered configuration is too difficult in may cases and standardizing JCache would ensure all implementations include basic support for distributed application deployment. ,"Pure Javascript on the client side like Angular, Backbone Ember and Knockout mean that for me (and many others) a new MVC framework that is HTML UI agnostic is fairly important.  However, much of this can be achieved today by simply creating a set of RESTful interfaces using JAX-RS, so this is not as critical. ",Somewhat important,Not important,,"MongoDB, Cassandra and others are becoming more prevalent.  I would like to see some standardization of what Hibernate and DataNucleus have already done in this area.",Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,The release frequency needs to be high to keep pace with new standards like HTTP2 and new developing technologies like noSQL storage.,
Brazil,Somewhat important,,Very important,,Very important,,Somewhat important,,Important,,Important,,,Very important,Very important,,,Not important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,1-2 years,,
India,Very important,,Very important,,Very important,,Not important,,Very important,,Important,,,Very important,Important,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,"Microservices is merely hype, nothing should be done.",,It is OK for Java EE to standardize unproven ideas that seem promising.,,2-3 years,,
Brazil,Very important,,Important,,Important,,I don't think we should eliminate EJB,,Important,,Very important,,,Very important,Important,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,"Microservices is merely hype, nothing should be done.",,"Java EE should innovate, but only very carefully.",,3-4 years,,
Kazakhstan,Somewhat important,,Important,,Somewhat important,,Not important,,Important,,Somewhat important,,,Very important,Somewhat important,,,Important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,1-2 years,,
Mexico,Very important,,Very important,,Important,,Somewhat important,,Important,,Important,,,Very important,Very important,,,Very important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,1-2 years,,
Turkey,Important,,Somewhat important,,Very important,,Important,,Not important,,Somewhat important,,,Very important,Important,,,Not important,Wait to see how well reactive is adopted in practical enterprise environments,,Java EE is already well suited to building practical microservices.,,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
United States,Very important,,Very important,,Important,"Libraries/Frameworks like Shiro make this far more usable, building off of those would be more useful than providing annotations around existing (threadbare) functionality.",Very important,"Related - improving the CDI functionality within JAX-RS would be *extremely* useful - being unable to inject a persistent unit into an object mapper is frustrating at times, it leads to an extra layer of processing (UI object to Server-side object) that is frequently not necessary.",Somewhat important,,Very important,,"It is *painful* to see javascript frameworks like angularjs, react, knockout, etc. reinvent the wheel (poorly at times) when it comes to the processing pipeline provided by JSF (validation, binding, etc.), frankly, adding another framework into the mix seems likely to stretch already thin resources to provide functionality that very few people would use - the vast majority of user-facing applications I build use a RESTful interface (provided by JEE) coupled with some sort of UI (angular, react, knockout, whatever the framework-du-jour happens to be - there is a distinct lack of maturity in this space, and the most outspoken voices in the JavaScript/HTML5 community seem to be the least educated when it comes to historical approaches, good software engineering practices, and sensible architectures).",Not important,Very important,"It would be *lovely* to be able to inject a dynamic data sources for container-managed JPA persistence units - this seems to frequently fails as it appears that data sources are created in more than a few app servers *after* persistence units, resulting in all sorts of entertaining null pointer exceptions... (consistency in CDI injection / ordering by app servers would be nice).",I think it's important for EclipseLink and Hibernate to continue to work on this support (and perhaps work together where appropriate) but it seems to early to try to unify this work.,Somewhat important,"Reactive is merely hype, nothing should be done","Reactive programming appears to be a way of building ESB-lite applications, without any of the standard tools to provide sensible plumbing (Apache Camel would be a vast improvement over the mess that is orchestrating RxJava-based functionality).  Simply put: it's a mess.",Java EE is already well suited to building practical microservices.,"Java EE is well suited to providing microservices, I am not at all convinced that Wildfly Swarm's approach to service discovery, for example, is something that should be standardized - it makes sense in some use cases, but not others, and seems a bit clunky (a good step in the right direction, but not something ready for greater use, I think).",It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,"2 Years would probably be good, slightly faster, better?",
Germany,Very important,,Very important,,Very important,,Somewhat important,,Important,,Important,,,Important,Very important,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,Java EE is already well suited to building practical microservices.,,Java EE should not standardize ideas that are not clearly proven.,,1-2 years,,
Serbia,Very important,,Important,,Very important,,Very important,,Very important,,Very important,,,Important,Very important,,,Not important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,2-3 years,,
Morocco,Very important,,Very important,,Very important,,Somewhat important,,Very important,,Very important,,,Very important,Very important,,,Important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,2-3 years,,
Germany,Very important,,Very important,,Somewhat important,,I don't think we should eliminate EJB,,Not important,,Somewhat important,,,Somewhat important,Very important,,,Somewhat important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Microservices is merely hype, nothing should be done.",,Java EE should not standardize ideas that are not clearly proven.,,2-3 years,,For me incremental and hot deployments like JRebel or OSGI hot replacement are important. This is the biggest Problem of Java EE from my point of view.
Bulgaria,Very important,,Very important,,Important,,Not important,It is more important for server vendors that have to implement both specs. For Java EE developers that want to use CDI will still use CDI no matter if EJB [lite] is there or not,Somewhat important,,Somewhat important,,,Somewhat important,Somewhat important,,"It will be really hard to create a standard on such a broad space as NoSQL. If you want to standardize it at the moment, it's going to take years to come to a common approach",Not important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Java EE is already well suited to building practical microservices.,"I would have picked standardizing uber jars from the first point. The others are just design patterns or good practices. Apart from discovery, where we had some bad experience with UDDI",It is OK for Java EE to standardize unproven ideas that seem promising.,"It is time now to start innovating based on solid specs like JPA, CDI and JAX-RS rather than wait for other frameworks or products",1-2 years,"Sounds really optimistic with the amount of resources that companies spend on putting people in standardization bodies (JCP). But still, specs like CDI prove that it is possible",
United States,Somewhat important,,Very important,,Very important,,Somewhat important,,Very important,,Important,,,Important,Somewhat important,,,Important,Introduce significantly specialized Java EE APIs for reactive programming,,Java EE is already well suited to building practical microservices.,,"Java EE should innovate, but only very carefully.",,2-3 years,,
Switzerland,Somewhat important,,Very important,,Somewhat important,,Very important,,Very important,,Very important,,,Very important,Important,,,Important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,,
United States,Very important,,Important,,Very important,,I don't think we should eliminate EJB,,Important,,Important,,,Not important,Somewhat important,,,Somewhat important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Java EE is already well suited to building practical microservices.,,"Java EE should innovate, but only very carefully.",,2-3 years,,
Uruguay,Somewhat important,"New standards adoption by enterprise companies is even slower than Oracle, so it's not very important.",Somewhat important,"Many companies use micro-services served by Tomcat or Jetty with Java 8, so JPA, JMS, JSF and JAX-RS (among others) are seldom used. If they are aligned to Java SE 8, it will be better than today, but it's not very important.",Important,"Security has been always underestimated, so the fact that it's going to be considered from now is important.",Very important,"EJB is a museum piece, while CDI goes behind Spring. That's the way to go.",Very important,It's ridiculous that Java doesn't provide native support for json yet...,Not important,"Not important at all, there are a lot of caching technologies out there, all with excellent results. Caching is something that should be done externally or specifically, not as part of a standard.",This is ridiculous. Just expose REST services in a well-defined API and consume these services from Angular or jQuery or whatever.,Not important,Not important,"Not important at all. Java would need to be based on conventions, and would need to provide a static  mechanism to override these defaults. If something needs to be dynamic, then it must be coded.","Not important at all, just use the excellent clients these NoSQL databases offer instead of trying to standardize something so heterogeneous.",Not important,Introduce significantly specialized Java EE APIs for reactive programming,It would be good to see reactive being taken as the standard and common way to develop enterprise & web applications.,Wait to see how well microservices is adopted in practical enterprise environments.,"Micro-services are well served by Tomcat, Jetty and other embedded containers, and can be perfectly implemented with Java SE and reactive libraries. No work should be done by now.","Java EE should innovate, but only very carefully.","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.",1-2 years,"One year only. Java EE release frequency (even Java SE one) is too low. Releases should be more frequent, one year at most. Just small, minimal, incremental additions, to keep pace with the requirements of the industry. After all, this is software, and software evolves very quickly.",
Argentina,Very important,"EE is a set of robust specs that will drive Java for years to come (As we know from EE's history that every version takes between 3 and 5 years to be published). As such, ensuring from the get go that the new HTTP/2 standard is well supported now will allow us to keep ahead of the curve.  This is even a valid point no matter if EE8 stays on track, or it follows the new Oracle idea.",Very important,"I've always believed that keeping EE on track with the corresponding SE release should be a very important element of every version.  Many of the new features from SE8 will be invaluable for EE8.   While some of this issues could just be faced on a basic level for now, not having them all relatively available for EE8 would just as well mean EE8 is only truly compatible with SE7 code.",Important,"On the enterprise ecosystem, security is one of the most important factors that could break a product.  I might even say more important than robustness or correctness. A system that fails or breaks can (relatively) easily be designed to take into account such problems, and can be fixed and/or brought back online. Meanwhile, security problems could just destroy any faith in a project.",Not important,"While I actually would celebrate such a move from EJB to CDI for all the APIs, between more important aspects of EE8, and some of the more interesting details that might come out of Oracle's shift, such work could just as well be advanced on the more important APIs, and left to be completed on a further release of EE",Somewhat important,"A more mature JSON-P, and the inclussion of JSON-B, are godsends for any java code that needs to work with JSON data.  Even so, as stated in the previous question, there are many crucial functionalities for EE8 that have a lot more weight",Important,"While my work has never had need of this API, I can recognize the high priority such a spec will be on current (and future) systems.  Between the surge of microservices, and the very current leveraging of distributed systems, containers, and such, a built-in distributed caching solution is crucial.",,Not important,Somewhat important,"While not crucial, this feature would be very useful for systems that may need regular hotswapping of service providers, modules, or even just some basic configuration variables.",,Not important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Java EE is already well suited to building practical microservices.,"While I actually believe some of the elements currently pseudo-standarized for microservices might actually be very welcome to EE, I also believe that EE is also currently very capable of implementing all of them with some extr effort from the design and implementation teams.","Java EE should innovate, but only very carefully.","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. That allows for the ecosystem to grow and evolve as the community shifts and takes interest on specific details. Meanwhile, the EE specs should keep making sure to standarize as much of the proven ideas as possible to allow said community to disengage from their implementation as much as possible.  This way, EE keeps a very robust base that can alsmot completely be ignored by the designers/engineers/programmers, allowing for all that saved effort to be poured into advancing, bettering, evolving, and proving/disproving all the innovative ideas.  The current release frequency (next point in the survey) will give said ideas all the time needed to be incubated and matured.  The IT scene is already fraught with 80% design SNAFUs that we've kept dragging for up to half a century just to comply with the ""current/latest"" fad/idea",1-2 years,"I'm a bit divided on this issue:  I consider the current half decade-ish frequency to be ideal for the way EE is currently handled. We work with standards that have been heavily proven, matured and optimized. Then, we even dedicate a couple more years to make sure the specs are up to par.  When every EE release includes so much evolution on the specs, such a frequency is best.   That said, if anybody can derive anything from our environment, it is that we accelerate through technologies and ideas at a staggering speed.  With the upcoming advent of Jigsaw, we can finally see the reality of hundreds of EE profiles that would allow for changes as small as the adoption of one single JSR into a server.  Such a future gives us a new way of working with EE: Very high frequency releases (on 1 year rates) could be made possible if each release were to only focus on a very small handfull of specs. One release could just be made to introduce an update to two existing specs, as much as being about intoducing a new spec or two.  This way, a mechanism could be implemented where any innovative idea can be relegated to a JSR, then given the current 3-5 years time to wait for incubation, maturity, etc. Then, every year or so, a new release could be made with all the JSRs that have reached the required level of maturity and acceptance.","I'm eagerly awaiting for JavaOne. I really want to see what Oracle has been coocking all this time they've been absent from the EE scene.  Sadly, I really believe this will probably delay EE8 for at least a full year to 2018. Mainly, because any paradigm shift they might introduce will pretty much require the addition of new JSRs (or adoption of discarded ones) that would need for a full process to be completed.  That said, I really hope that a few gold nuggets can be taken from their reveal of their new outlook.  The main feature I'd love to tackle for EE is the fact that we even NEED something like uber-jars for microservices to work, a legacy of the monolithic server paradigm that affects not only distributed systems and microservices. That said, this feautre is something I believe will be taken care of in EE9 (or 10 at most) with the advent of Jigsaw's modularity paradigm, so I can table that one for a few years"
Australia,Very important,,Important,,Very important,,Somewhat important,,Very important,,Very important,,,Somewhat important,Very important,,,Important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,3-4 years,,
Morocco,Very important,,Very important,,Important,,I don't think we should eliminate EJB,,Very important,,Very important,,,Very important,Somewhat important,,,Not important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,1-2 years,,
Sweden,Important,,Very important,,Very important,,Important,,Somewhat important,,Important,,,Important,Somewhat important,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
Poland,Somewhat important,,Important,,Somewhat important,,Very important,,Important,,Very important,,,Very important,Very important,,,Somewhat important,Introduce significantly specialized Java EE APIs for reactive programming,,Wait to see how well microservices is adopted in practical enterprise environments.,,It is OK for Java EE to standardize unproven ideas that seem promising.,,3-4 years,,
Mexico,Important,,Important,,Very important,,Somewhat important,,Important,,Important,,,Somewhat important,Somewhat important,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,1-2 years,,
Spain,Very important,,Very important,,Very important,,Very important,,Important,,Important,,,Not important,Somewhat important,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,It is OK for Java EE to standardize unproven ideas that seem promising.,,2-3 years,,
Ecuador,Very important,,Important,,Very important,,Important,,Very important,,Very important,,"I think that it is too late for java front end technologies. I think they should focus on the field that Java has advantages, this field is backend technologies. ",Somewhat important,Very important,,,Important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,They should wait to Java EE 9 or 10 to introduce significantly specialized Java EE APIs for reactive programming,Java EE is already well suited to building practical microservices.,,Java EE should innovate in the same way that non-standard products do.,,2-3 years,2 years,
Greece,Important,,Important,,Very important,,I don't think we should eliminate EJB,,Important,,Not important,,,Somewhat important,Somewhat important,,,Important,Wait to see how well reactive is adopted in practical enterprise environments,,Java EE is already well suited to building practical microservices.,,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
Australia,Important,,Not important,"I don't use JEE (apart from servlet indirectly) but we are moving away from that now, so it's not important at all if JEE gets lamda et al make over.",Not important,"We haven't use JEE security for ages, so it's not really important to us if it gets improved or not. We aren't going to just switch just because there's an improvement to JEE security, it's just too risky besides our alternatives work fine.",Not important,"We don't use EJB we used JOOQ for querying, moving away even from JPA, so it's not important to us.",Not important,We used GSON for parsing and client side are done in javascript. So it's not really important at all. AFAIK GSON don't implement the standard of JEE JSON support anyways.,Not important,"We dont' use distributed cache, just in-process cache like those from Guava, so it is not important to us.","Our backend are really just REST microservices. Communications with front-end are through json and token. So we have ditched MVC framework for a long time (in the sense of those that generate html and send back to browser), Front end are pure javascript like backbone and react",Not important,Not important,We don't really rely much of injection (some from Spring boot). Try to keep em to the minimum so CDI is not of much value to us.,"We do use Solr, Spark and considering Cassandra but i think those APIs are good enough on it's own and it doesn't warrant another generic abstraction that is too general when we need more specific use cases we fall back to vendor's respective APIs anyways. Plus these days APIs are pretty much well documented and the code are mostly open source, resource available in abundance, so there aren't any benefits of over standardising i guess.",Not important,Wait to see how well reactive is adopted in practical enterprise environments,"i think reactive would be more suited added to JSE eg. what Guava has done or stuff done to CompletableFuture, Stream etc. ",Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,1-2 years,,"I think JEE should be slim. Perhaps take advantage of jigsaw modularity that can be plug in and out. Profiles sucks. Should start in fast and minimalistic like in a single command line cause everthing is in cloud now and if it is heavy i'm just paying for thins i don't use. cpu, memory etc. cost money .... :-)"
,Important,,Important,,Very important,"The biggest mistake ever was to let security to actual JEE implementors. A crucial part is therefore not portable at all and many features aren't available, e.g. SNI.",Somewhat important,we shouldn't forget about JSF that has yet another CDI mechanism. ,Somewhat important,,Not important,,,Not important,Very important,,,Not important,Wait to see how well reactive is adopted in practical enterprise environments,sounds like a hype to me,Java EE is already well suited to building practical microservices.,"Injecting an EJB that may or may not be deployed isn't covered by the @Inject annotation, which means a manual look-up is necessary to cope with a missing bean (aka micro service). It would be a nice improvement if that could be handled as a normal use case rather than an exception.",Java EE should not standardize ideas that are not clearly proven.,"I see standardization as a final step of a lengthy engineering process. Changing a standard after it got established is always difficult and if it is frequently required, it'll be quite counterproductive.",1-2 years,,"As I mentioned above, security should be part of the standard and not just let to server implementors. E.g. how realms are handled and set-up is different on every product and really a nuisance. How to enable PFS is different on every product as well and SNI (server name indication) is supported only for Tomcat (which isn't a JEE server). "
United States,Very important,,Very important,,Important,,Somewhat important,,Very important,,Somewhat important,,,Very important,Somewhat important,,,Somewhat important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Java EE is already well suited to building practical microservices.,,Java EE should innovate in the same way that non-standard products do.,,2-3 years,,
China,Very important,,Very important,,Very important,,Very important,,Very important,,Very important,,,Very important,Very important,,,Very important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
Saudi Arabia,Very important,,Important,,Very important,,I don't think we should eliminate EJB,,Very important,,Important,,,Very important,Somewhat important,,,Somewhat important,Introduce significantly specialized Java EE APIs for reactive programming,,Wait to see how well microservices is adopted in practical enterprise environments.,,Java EE should innovate in the same way that non-standard products do.,"Why not make Java EE a plugable modular framework that allows bits and pieces to be glued together with support of certain minimum features (JSRs) instead of having it being the same way it is right now, a set of specific and fixed JSRs.  let's say Java EE 10 is that plugable modular framework that must at least support Servlet 5.0, EJB 5.0, JPA 5.0.  But I can upgrade to Servlet 6.0 (when it's released) in the same Java-EE 10 server. (That is of course, if we still have servers.. :)).  The idea in a nutshell is to have a Java EE Framework that is plugable and upgradable. At least for certain APIs. And if we included a concept similar to Linux LTS versions and latest releases; we can have a certain API's version be included in a Java EE after a while of stability. It's like giving the community a new version for test (although the API is actually a release) and if it's good enough; we can have it included in Java EE. If not; it will either get thrown away (EJB 2.x - CMP) or fixed in another release (Session Beans) and so on.  If my idea is not clear, it's like having Java EE built on top of Java 9 Modularity in a way that enables upgrade of certain modules.",1-2 years,If we did incorporate the concept of Java EE LTS and Java EE Release; I believe we can have much faster release cycles. May be 2 or 3 releases per year.,
Colombia,Very important,,Very important,,Very important,,Somewhat important,,Very important,,Important,,,Somewhat important,Somewhat important,,,Very important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,2-3 years,,
Portugal,Important,,Very important,,Very important,,Not important,,Very important,,Important,,,Somewhat important,Important,,,Important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,2-3 years,,
Colombia,Very important,,Very important,Java 8 date/time API aligned with JPA and JSF (validators and converters).,Somewhat important,,Important,,Very important,,Somewhat important,,,Very important,Important,,,Important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,,
United States,Very important,,Important,,Important,,Somewhat important,,Very important,,Somewhat important,,,Not important,Important,beats rebuilding for different configs,,Not important,"Reactive is merely hype, nothing should be done",,Wait to see how well microservices is adopted in practical enterprise environments.,,It is OK for Java EE to standardize unproven ideas that seem promising.,,2-3 years,,Polymer
United States,Very important,,Very important,,Somewhat important,,Important,,Important,,Very important,,,Somewhat important,Important,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,Please don't forget to not go back to Windows 2-like cooperative multitasking. A lot of reactive stuff is just that. This needs to be avoided ,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,2-3 years,,Thank you !
Paraguay,Very important,,Very important,,Important,,Not important,,Very important,,Very important,,,Somewhat important,Important,,,Important,Wait to see how well reactive is adopted in practical enterprise environments,,Java EE is already well suited to building practical microservices.,,Java EE should not standardize ideas that are not clearly proven.,,2-3 years,,
Taiwan,Very important,,Important,,Very important,,Not important,,Very important,,Somewhat important,,,Very important,Somewhat important,,,Important,Wait to see how well reactive is adopted in practical enterprise environments,,Java EE is already well suited to building practical microservices.,,It is OK for Java EE to standardize unproven ideas that seem promising.,,2-3 years,,
United States,Important,,Very important,,Important,,Important,,Important,,Somewhat important,,,Very important,Important,,,Somewhat important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,2-3 years,,
Brazil,Very important,,Very important,,Very important,,Very important,,Very important,,Very important,,,Very important,Important,,,Somewhat important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,1-2 years,,
United States,Very important,,Important,,Somewhat important,,Not important,,Very important,,Somewhat important,,,Not important,Not important,,,Not important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Java EE is already well suited to building practical microservices.,,"Java EE should innovate, but only very carefully.",,1-2 years,,
United States,Very important,,Very important,,Very important,,Not important,,Very important,,Important,,,Not important,Somewhat important,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,Java EE is already well suited to building practical microservices.,,"Java EE should innovate, but only very carefully.",,1-2 years,,
Hong Kong,Very important,,Very important,Aligning with JavaSE8 allows developers to write consistent and clean code. Design of JavaEE part can also be benefited by JavaSE8 features.,Somewhat important,I agree with a highly secured JavaEE. But I am not familiar with security issue especially in API design.,Not important,,Very important,,Important,,,Somewhat important,Important,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,2-3 years,,
United States,Very important,,Somewhat important,,Somewhat important,,Very important,,Somewhat important,,Very important,,"As for me, I would completely eliminate JSF. It is 2016, multi-channel delivery era. Component frameworks are dead. For God's sake stop wasting your time on that crap and focus on reactive frameworks/ libraries like vert.x",Important,Very important,,,Very important,Introduce significantly specialized Java EE APIs for reactive programming,Reactive is the future. At least once let Java EE be proactive about important trends,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.","Martin Fowler, Adam Bien have very subjective views. Instead of listening to pundits take a look at humangous success stories at companies like Google, Netflix, Amazon etc who actually are doing more for Java than jcp which by the time comes up with something the train was already long gone.",Java EE should innovate in the same way that non-standard products do.,"Just standardizing proven ideas is the main reason why Java EE is losing developers. Android is the only reason why Java still matters not your standards process. If you don't want to become next cobol please innovate faster. Otherwise you will become grandfather's Oldsmobile. Node js is constantly improving, Golang and server side Swift gaining speed. No time to wait for mature ideas. Don't make yourself more irrelevant than it already is.",1-2 years,Otherwise suffer irrelevance ,Add as more cloud ready features as possible. If for that Java EE 8 is delayed so be it 
Brazil,Very important,,Very important,,Important,,Very important,,Somewhat important,,Very important,,,Not important,Not important,,,Very important,"Reactive is merely hype, nothing should be done",,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,1-2 years,,
Brazil,Very important,,Very important,,Very important,,Not important,"""rewrite these services using CDI inside more specialized Java EE APIs such as JMS, Java EE Security and the Java EE Concurrency Utilities""  Replicate the functionality? No way!",Very important,,Very important,,,Important,Very important,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,1-2 years,,
Germany,Very important,,Very important,,Somewhat important,,I don't think we should eliminate EJB,,Very important,,Important,,,Somewhat important,Somewhat important,,,Very important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Java EE is already well suited to building practical microservices.,,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,,
United States,Important,,Very important,,Important,,Very important,,Very important,,Important,,,Not important,Very important,,,Important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,Cloud native application
,Very important,MS and Google won't procrastinate...,Important,"Correct. If you don't want to see forks sprouting all over the place, it's better to have the mainstream implementations leverage all the ee7/ee8 goodies.",Very important,"Poor security is one of the things that killed windows in the data centre.  Security is what grabs the headlines.  Security is what killed java in the browser. If you want to kill java in the data centre, neglect security.",I don't think we should eliminate EJB,"If it ain't broken, don't fix it.",Very important,"People use GSon Google stuff or a host of other more or less well baked libs. What would it be like if java did not have jaxb,jaxp?",Somewhat important,,",net are constantly upgrading their MVC framework.",Very important,Important,,,Very important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Java EE is already well suited to building practical microservices.,,Java EE should not standardize ideas that are not clearly proven.,,2-3 years,,
Canada,Very important,,Very important,,Very important,,I don't think we should eliminate EJB,Both models have benefits and can be used together,Very important,,Very important,,"JSF should be modernized and should allow the pages to easily be adapted to all kind of support, from small smartphones to computers. Moreover, an alternative similar to Vaadin could be implemented, relying on the experience and the benefits of simple desktop applications like in the days of Swing, with modern features like ajax, reactive design, MVC layers, ...",Important,Very important,A lot of work could be done with Spring in order to standardize this technology and make it available inside JavaEE,,Very important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,3-4 years,,
United States,Very important,,Somewhat important,,Important,,Somewhat important,,Important,,Not important,,,Somewhat important,Important,,,Very important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,1-2 years,,
Nepal,Very important,,Very important,,,,,,Very important,,,,,Very important,,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,,,,,,,
United States,Very important,,Somewhat important,Many of the EE level calls supercede or are superceded by the SE calls. While i agree tgat the EE implementations should focus on becoming SE 8 compliabt i dont feel thats necessary except on a case by case basis for the APIs,Not important,"Security is ALWAYS going to lag behind the times, its better for EE to simply define some entity annotations and leave detailed implementations to the groups who are doing this already. Someone os always going to need X feature thats beyond the scope if the reference impl.",I don't think we should eliminate EJB,Compatibility.,Very important,,Important,"Not familiar with the spec but as someone who often implememts distributed cache, yes please.  If ypur going to do it make sure there are multilevel cache recognition formats abd support for 0 level caches (Akamai,  etc.)",Another one? Pls god no. We can spend our time better elsewhere.,Not important,Somewhat important,Netflix oss does this already and does it well...,"Unless your going to make a distinction between KV, document, and hierarchical document stores theres no point, and if you do it limits thier utility.",Not important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Java EE is already well suited to building practical microservices.,"Netflix oss.  If you must have it, there it is ",Java EE should not standardize ideas that are not clearly proven.,"Im on the fence with this but given the difficulty in getting a java ee8 release at all, perhaps we shpuld shift the onus of innovation to the community and use the ee apis to standardize only when a clear winner emerges, as with the time apis",2-3 years,,"I think a strong conversation should be had about the place and role of standards like jsf, jsp, and other front end standards in a way that emphasizes the client server divide and the role of templated pages interacting with service requests, especially through http2. While this will be a painful conversation, i believe its necessary to allow innovation to drive those spaces separately to thier destiny while allowing the uses of library functionality to hide the tying of service requests to pages. "
United States,Very important,,Very important,,Very important,,Important,,Very important,,Very important,,,Important,Very important,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,2-3 years,,
Brazil,Important,,Very important,,Very important,,Somewhat important,,Very important,,Very important,,,Very important,Somewhat important,,,Not important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,2-3 years,,
Canada,Important,,Very important,,Important,,Very important,,Very important,,Somewhat important,,,Not important,Somewhat important,,,Somewhat important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Microservices is merely hype, nothing should be done.",,"Java EE should innovate, but only very carefully.",,2-3 years,,
India,Important,,Very important,,Very important,,Very important,,Very important,,Very important,,,Very important,Important,,,Very important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,"Bring in a component supporting EIP like messages, adapter, gateway, service activator, filter and transformer.   Better HATEOAS support in JAXRS.   Improve JPARS. "
United States,Important,,Important,,Important,,Important,,Somewhat important,,Important,,,Somewhat important,Very important,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,,,
Paraguay,Very important,,Important,,Very important,,Very important,,Very important,,Somewhat important,,,Very important,Very important,,,Very important,,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,1-2 years,,
Belarus,Very important,,Important,,Important,,Somewhat important,,Important,,Important,,,Not important,Important,,At list support for Mongo and Casandra,Important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should not standardize ideas that are not clearly proven.,,1-2 years,,
India,Very important,,Very important,,Very important,,Very important,,Very important,,Very important,,,Very important,Very important,,,Very important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should not standardize ideas that are not clearly proven.,,1-2 years,,
Vietnam,Not important,,Somewhat important,,Important,,Important,,Important,,Somewhat important,,,Very important,Very important,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
India,Very important,,Important,,Very important,,Important,,Very important,,Very important,,,Somewhat important,Very important,,,Not important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Java EE is already well suited to building practical microservices.,,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,No
Kazakhstan,Very important,,Important,,Very important,,Somewhat important,,Very important,,Very important,,,Important,Very important,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,3-4 years,,
Hong Kong,Very important,,Important,,Very important,,Important,,Very important,,Very important,,,Very important,Important,,,Very important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,1-2 years,,
Costa Rica,Very important,,Very important,,Very important,,Very important,Less is more,Very important,,Important,,,Somewhat important,Not important,"Its not really safe to play around with Production environments. Its a nice to have feature, but not a must have.",Not important at all. The difficult to come to a standard may give a chance to a weak and/or  useless feature.,Not important,"Reactive is merely hype, nothing should be done",,"Microservices is merely hype, nothing should be done.",,Java EE should innovate in the same way that non-standard products do.,,4-5 years,"Releases should be performed at a slow pace, so update efforts pay off for more time.  If there are more often releases there is a chance that some versions will be skipped by customers, and if that gap gets to two or more versions it may generate some anxiety and unneeded pressure. ",
United States,Very important,,Very important,,Very important,,Very important,,Very important,,Very important,,,Very important,Very important,,,Very important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,"I think that as Java moves forward its aim among other things should be to focus on ease of development and become more functional oriented in some ways. While its true that its strength is being objective oriented, many developers such as myself, are looking for ease of development with Java. Perhaps in an attempt to be very precise in structure its caused Java to be overly verbose and in many ways not a very straight forward way of problem solving. I think Java should become more of a straight forward functional language that instead focusing on just classes,methods, to even do a simple problem, Java should address problems more directly. A lot of time and attention is used when a developer has to think of classes, methods, even perhaps inflexible syntax that adds more boilerplate to a task even before a developer can start to address the actual application or program. A example is just ""hello world"". Before one can even print this to the screen one has to address: what are classes?is the class public? What does static mean? What is void? And how one structures there method within its given scope. This can be a lot for one to think about and one hasn't even printed "" hello world"" yet to the display. I think that if Java were to become more concise in syntax and be more direct and function oriented this could not only help keep current developers interested in Java but also help attract new ones as well by becoming a more developer friendly language. "
United States,Very important,,Somewhat important,,Somewhat important,,Somewhat important,,Important,,Somewhat important,,,Somewhat important,Somewhat important,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,Java EE is already well suited to building practical microservices.,"I use this concept in a big big way, but it was all built from scratch 13+ years ago.  It would be nice to have it built into the language but not necessary for me.",Java EE should not standardize ideas that are not clearly proven.,,2-3 years,,
India,Very important,,Very important,,Important,,Very important,,Very important,,Important,,,Very important,Very important,,,Very important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
India,Very important,,Important,,Very important,,Somewhat important,,Very important,,Somewhat important,,,Important,Very important,,,Very important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Java EE is already well suited to building practical microservices.,,"Java EE should innovate, but only very carefully.",,2-3 years,,
India,Very important,,Somewhat important,,Very important,,Not important,,Very important,,Somewhat important,,,Important,Very important,,,Very important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,2-3 years,,
Morocco,Important,,Very important,,Very important,,Important,,Very important,,Very important,,,Somewhat important,Very important,,,Important,Wait to see how well reactive is adopted in practical enterprise environments,,Java EE is already well suited to building practical microservices.,,"Java EE should innovate, but only very carefully.",,2-3 years,,
Germany,Important,,Very important,,Very important,,Important,,Very important,,Very important,,,Not important,Important,,,Very important,Introduce significantly specialized Java EE APIs for reactive programming,,Java EE is already well suited to building practical microservices.,,It is OK for Java EE to standardize unproven ideas that seem promising.,,2-3 years,,
Germany,Important,,Important,,Very important,,I don't think we should eliminate EJB,,Important,,Somewhat important,,,Somewhat important,Important,,,Not important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,2-3 years,,"Even in 2016, one meets opinions that Java EE is an old, big, slow and ugly guy. The best way to swipe away these opinions is by showing examples. Adam is often talking about capabilities of Java EE in terms of performance and easyness of setting everything up, but there need to be a good examples which do some real world stuff (more than hello world) delivered together with Java EE. "
Paraguay,Very important,,Very important,,Very important,,I don't think we should eliminate EJB,EJB should continue to exist as a CDI stereotype,Very important,,Very important,,The same can be achieved with JAX-RS,Not important,Not important,,"unlike SQL, NoSQL itself is not standardized yet. I think there will be little interest by the different vendors to do it.",Not important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Java EE is already well suited to building practical microservices.,99% of apps wont need this. Only very large companies need Microservices. Java EE is mostly used for corporate internal web apps (at least in my experience).,Java EE should not standardize ideas that are not clearly proven.,,4-5 years,"No need to rush. As Adam Bien said ""the revolution already happened"". Every change from now on should be evolutionary and only incorporate proven technologies or necessities, such as HTTP/2, JCache, security.",
Hong Kong,Important,,Very important,,Important,,I don't think we should eliminate EJB,,Very important,,Somewhat important,,,Somewhat important,Important,,,Important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,It is OK for Java EE to standardize unproven ideas that seem promising.,,2-3 years,,
South Africa,Very important,,Very important,,Very important,,Somewhat important,,Important,,Important,,"I think this is a cool idea. If it is a realistic goal fit all of this in the next JEE release I'll support it, otherwise, if it might put unnecessary strain on development, I'll let this feature be the first to be excluded and brought in in subsequent releases.",Somewhat important,Somewhat important,"This sounds like a helpful feature, however, it is not the worst thing in the world to do if CI is in place.",,Important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Java EE is already well suited to building practical microservices.,,"Java EE should innovate, but only very carefully.",,2-3 years,,Thank you for representing the community.
Germany,Important,,Important,,Very important,,Very important,,Very important,,Important,,,Important,Somewhat important,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,2-3 years,,
"Iran, Islamic Republic of",Important,"JSF has many design flaw, add more features of JBoss Seam in it.",Not important,"Java 8 is BS and imitated from Scala, it only added more classes to JDK ",Somewhat important,third-party has more flexibility than Java EE security for more information visit JBoss Seam security.,I don't think we should eliminate EJB,,Important,"most Java applications don't need a simple Json support, it is gonna be supported, you should considered all posiible situation of converting an entity to JSon for example it should be possible to convert an Entity that refference to itself and prevent loop",Very important,,,Not important,Very important,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,2-3 years,,
India,Very important,,Somewhat important,,Important,,I don't think we should eliminate EJB,,Very important,,Very important,,There are already 10s of such frameworks available in JAVA. No need to standardize one.,Not important,Not important,This depends how you build your architecture. I don't think this is of a problem of any sort.,Very important if JAVA wants to stay relevant in lets say 3-5 years from now.,Very important,Introduce significantly specialized Java EE APIs for reactive programming,,Wait to see how well microservices is adopted in practical enterprise environments.,,Java EE should innovate in the same way that non-standard products do.,,1-2 years,i believe they should adopt release cycle like .net if not nodejs like.,
Bolivia,Very important,,Important,,Important,,I don't think we should eliminate EJB,,Very important,,Very important,,,Somewhat important,Very important,,,Somewhat important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Wait to see how well microservices is adopted in practical enterprise environments.,,,,1-2 years,,
Denmark,Very important,,Very important,,Very important,,I don't think we should eliminate EJB,,Important,,Important,,,Somewhat important,Important,,,Important,Introduce significantly specialized Java EE APIs for reactive programming,,"Microservices is merely hype, nothing should be done.",,"Java EE should innovate, but only very carefully.",,1-2 years,,
Romania,Very important,,Important,,Important,,Very important,,Very important,,Very important,,,Somewhat important,Very important,,,Somewhat important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Wait to see how well microservices is adopted in practical enterprise environments.,,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
Spain,Very important,,Very important,,Important,,Important,,Very important,,Somewhat important,,,Very important,Important,,,Important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
Sri Lanka,Very important,,Very important,,Very important,,Somewhat important,,Very important,,Important,,,Important,Important,,,Very important,Wait to see how well reactive is adopted in practical enterprise environments,,Java EE is already well suited to building practical microservices.,,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,,
Germany,Very important,,Important,,Very important,,Somewhat important,,Important,,Somewhat important,,,Very important,Not important,,,Not important,"Reactive is merely hype, nothing should be done",,Java EE is already well suited to building practical microservices.,,It is OK for Java EE to standardize unproven ideas that seem promising.,,2-3 years,,
Belarus,Very important,,Very important,,Somewhat important,,Important,,Very important,,Important,,,Somewhat important,Important,,,Not important,Wait to see how well reactive is adopted in practical enterprise environments,,Java EE is already well suited to building practical microservices.,,"Java EE should innovate, but only very carefully.",,1-2 years,,
India,Important,,Important,,Very important,,I don't think we should eliminate EJB,,Very important,,Very important,,,Very important,Important,,,Very important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,,
Mozambique,Very important,,Very important,,Very important,,Somewhat important,,Very important,,Very important,,,Very important,Important,,,Very important,Introduce significantly specialized Java EE APIs for reactive programming,,Java EE is already well suited to building practical microservices.,,"Java EE should innovate, but only very carefully.",,1-2 years,,
Denmark,Important,,Very important,,Important,Spring is prefered as of now.,Not important,,Important,,Somewhat important,,It would strengthen the JEE,Important,Somewhat important,,,Somewhat important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Java EE is already well suited to building practical microservices.,,Java EE should not standardize ideas that are not clearly proven.,,1-2 years,,
Austria,Somewhat important,,Very important,,Very important,,I don't think we should eliminate EJB,,Very important,,Not important,,,Not important,Not important,,,Important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Java EE is already well suited to building practical microservices.,,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,"JSF with more features, modernized."
Turkey,Somewhat important,,Important,,Important,,Somewhat important,,Important,,Somewhat important,,,Important,Somewhat important,,,Important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,,You should put a native HTTP client inside Java EE. This is a very basic functionality and we need third party jars to just make HTTP GET. You should also make release frequency maximum 6 months.
Switzerland,Important,,Very important,,Very important,,Important,,Very important,,Important,,,Important,Important,,,Important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,2-3 years,,
Spain,Very important,,Somewhat important,,Not important,,Important,,Somewhat important,,Very important,,,Not important,Somewhat important,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,Java EE is already well suited to building practical microservices.,,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,,
Russian Federation,Important,,Very important,,Somewhat important,,Very important,,Important,,Somewhat important,,,Somewhat important,Important,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,1-2 years,,
Germany,Very important,,Very important,,Important,,Somewhat important,,Important,,Important,,,Important,Somewhat important,,,Very important,Introduce significantly specialized Java EE APIs for reactive programming,,Java EE is already well suited to building practical microservices.,,Java EE should not standardize ideas that are not clearly proven.,,2-3 years,,
South Africa,Very important,There is simply no reason to not include it,Important,"It would be great and would allow us to remove some help/wrapper code, but in general not critical for our application as it is now",Important,"Some aspects of this may be useful, others not so much",Not important,,Very important,"The current JSON support is clunky and a pain to use and understand, especially when compared to how simple it is in other languages to intereact with JSON structures",Very important,"This is key to being able to run services across a distributed platform, irrespective of whether it is on multiple dedicated servers or cloud infrastructure",,Not important,Somewhat important,,"Some applications will be able to benefit from a more standardised NoSQL access, but this is entirely application dependent",Important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,1-2 years,,
South Africa,Very important,,Very important,,Very important,,Somewhat important,,Very important,,Important,,,Important,Very important,,,Somewhat important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,,
India,Very important,,Very important,,Important,,Very important,,Very important,,Very important,,,Very important,Important,,,Somewhat important,Introduce significantly specialized Java EE APIs for reactive programming,,Java EE is already well suited to building practical microservices.,,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
Netherlands,Very important,,Very important,,Important,,Somewhat important,,Important,,Very important,,,Not important,Important,,,Important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,Technology is moving fast. In order to keep up with the latest a frequent release is required. ,
Spain,Very important,,Very important,,Very important,,Somewhat important,,Very important,,Very important,,,Important,Somewhat important,,,Not important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,2-3 years,,
United States,Very important,,Very important,,Important,,Important,,Very important,,Somewhat important,,,Somewhat important,Very important,,,Important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,,
Germany,Very important,,Important,I am not sure about fork/join pools in general. I think the default implementation is seriously flawed in design.,Somewhat important,"With Spring Security at hand, other sources and OAuth I don't see that much need for more security in JEE.",Very important,EJB have been a bad idea for over 10 years now. Let's finally bury them.,Very important,,Somewhat important,,"We got JAX-RS, that should be enough for modern web applications. I see no benefit in yet another framework.",Not important,Very important,Cool ;-),I think it is not desireable to have common APIs for all kind of datastores. Even JPA never worked truly vendor indepedent.,Not important,Introduce significantly specialized Java EE APIs for reactive programming,,Java EE is already well suited to building practical microservices.,,Java EE should not standardize ideas that are not clearly proven.,"Since Standards are there to ""last"" at least for a few year, I prefer a more conservative approach.",2-3 years,,
Ukraine,Important,,Very important,,Very important,,Somewhat important,,Somewhat important,,Important,,,Somewhat important,Important,,,Important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,It is OK for Java EE to standardize unproven ideas that seem promising.,,2-3 years,,
India,Somewhat important,,Very important,,Important,,Somewhat important,,Very important,,Very important,,,Very important,Very important,,,Very important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,2-3 years,,
Netherlands,Important,,Very important,The changes in SE 8 are a huge improvement for the language. EE 8 users should also benefit from these improvements.,Somewhat important,,I don't think we should eliminate EJB,,Very important,"Current frameworks, such as Jackson and GSON lack standardization, making them hard to work with. Moreover, JSON produced by one often cannot be understood automatically by the other.",Important,,,Not important,Important,,NoSQL isn't even a standard. I don't see how exposing NoSQL databases through a standard would help. I think it would only limit your ability to fully use the underlying database.,Not important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",A clearly proven idea is difficult to standardize. You force people to rewrite large portions of their codebase to conform to the new standard (this is what happened with the Hibernate criteria API).,1-2 years,,
Austria,Important,,Important,,Somewhat important,,Not important,,Important,,Important,,,Important,Somewhat important,,,Not important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,I prefer smaller releases in less time instead of huge releases within years.,
Bulgaria,Very important,,Very important,,Important,,Not important,I think that EJB still has it's usage area and keeping it for at least few more Java EE versions is vital.,Important,,Very important,,,Important,Important,,,Somewhat important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Java EE is already well suited to building practical microservices.,,Java EE should not standardize ideas that are not clearly proven.,It is important Java EE to try to limit it's scope only to proven ideas and make them standards. For all other ideas there is always possibility to evolve as open projects and once they prove thy are good Java EE can adopt them. Another option is to have Java EE experimental profile that will include these unproven innovative ideas but they should be developed as open projects without the burden of JCP. ,1-2 years,Try to keep changes as frequently as possible. Make small changes more often. This way Java EE can adopt proven ideas in it's next version.,
Ethiopia,Very important,,Very important,,Very important,,Very important,,Very important,,Very important,,,Very important,Very important,,,Very important,Introduce significantly specialized Java EE APIs for reactive programming,,Wait to see how well microservices is adopted in practical enterprise environments.,,Java EE should innovate in the same way that non-standard products do.,,2-3 years,,
Australia,Not important,,Very important,,Important,,Very important,,Very important,,Somewhat important,,,Very important,Not important,,,Not important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Java EE is already well suited to building practical microservices.,,"Java EE should innovate, but only very carefully.",,3-4 years,,
Russian Federation,Very important,,Very important,,Important,,Not important,,Very important,,Very important,,,Important,Somewhat important,,,Very important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,Java EE should not standardize ideas that are not clearly proven.,,2-3 years,,
Sweden,Very important,,Very important,Alignment and usage of the concurrency API's are most important.,Important,,Important,The very name Enterprise Java Beans is one of the reasons developers are scared away from Java EE with the perception that it is something heavy. Migrating to CDI could be the start of a rebranding of the API's and act as a showcase that EE is not heavyweight at all.,Very important,JSON rules the world when it comes to interchange formats. Java EE should make it a first class citizen.,Important,,Web UI's will still be built using Javascript client-side frameworks. Don't waste energy on yet another substandard Java view framework. Instead focus on making Java EE the best backend there is.,Not important,Not important,,Do not try to shoehorn all NoSQL API's into a common denominator standard when they in fact does not have anything in common.,Not important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,"It is difficult to be reactive without having all the API's in the chain fully async. We would need some guarantee that the libraries we use indeed are fully reactive and not cheating by using threadpools etc, merely pushing the problem to the boundraries. Something like XA-compliance forces the vendor to guarantee support. Perhaps call it RX-compliant drivers? The runtime should then be able to warn you when you're using blocking api's instead of the reactive ones.","Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",Spring Boot's success is not in it's API's or the way it packages the runtime. To me it's about that first 5 minutes to get something up and running that can be deployed instantly. If it takes more than a few seconds from having a hack idea to have a project with an http-server up and running (without IDE help) most developers just fires up Node instead.,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,"Smaller relase sets, more frequently. The same way as all software projects should be released.",
Netherlands,Very important,,Very important,,Important,,,,Somewhat important,,Somewhat important,,,Not important,Somewhat important,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,,,1-2 years,,
Hungary,Important,,Very important,,Somewhat important,,Very important,,Very important,,Not important,,,Not important,Very important,,,Very important,"Reactive is merely hype, nothing should be done",,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,1-2 years,,
Greece,Very important,,Somewhat important,,Very important,,Very important,,Not important,,Very important,,,Not important,Very important,,,Not important,Wait to see how well reactive is adopted in practical enterprise environments,,Java EE is already well suited to building practical microservices.,,Java EE should not standardize ideas that are not clearly proven.,,1-2 years,,
Hungary,Very important,,Important,,Very important,"Security itself is obviously extremely important, ease of use also, but please keep the API's nicely separated and don't force people to use parts of J2EE they don't want because of the bloated overhead. ",I don't think we should eliminate EJB,"I don't like either, never did, it would be interesting tot see oracle come with a better component model. ",Very important,"JSON schould be fullgrown part of J2EE, like XML, if posible: better.  ",Somewhat important,,"Ofcourse it all depends on the details, but this is exactly what J2EE needs. This is what I have always missed (actually I rolled my own already back in 2002 that i've used ever since). So I'm extremily interested.",Very important,Very important,There you have  one of the issues i don't like about EJB and CDI: By desigb they tend to get in the way of these sort of less staric more dynamic features.,"Is they manage to coin  a good and very usable standard, that would be absolutely fantastic. ",Important,"Reactive is merely hype, nothing should be done","Maybe 'merely hype' is a bit to strongly frased, but it comes closed to what I think it is: it is a hype and definately is currently much overated.","Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.","J2EE Is very much about standardization and this is definitely a very good candidate for standarisation. I find it dificult though how it will work out. If it's done, ten years from now looking back we might say this was the one of tje best things that happend to J2EE, or it was a conplete wast of time and effort. There is a good chance it's the latter, but still think Oracle should strive to make the first a reality.","Java EE should innovate, but only very carefully.","Our industry is full of hypes, it is a sickness. J2EE should be free from it.",2-3 years,,"SMAC is the future (that has already arived) Ease Of Use is King. Java is fantastic, but Java and especialy J2EE has always had a strong tendency to over complicate everything (the Servlet API wich is fantastic is one exception and JDBC a close second). That is the problem with J2EE that should be overcome/avoided. The more helpfull J2EE is to enable us to build in short notice fast, secure and reliable standard bases SMAC applications the more J2EE will thrive."
,Very important,,Important,,Somewhat important,,I don't think we should eliminate EJB,,Very important,,Somewhat important,,"The name ""MVC"" for JSR-371 is very unfortunate. There will be a component-based MVC framework called JSF and an action-based MVC framework called MVC. This is bound to caused misconceptions. Both are MVC frameworks. We should find a better name for JSR 371.",Very important,Somewhat important,,,Not important,Wait to see how well reactive is adopted in practical enterprise environments,,Java EE is already well suited to building practical microservices.,,"Java EE should innovate, but only very carefully.",,1-2 years,,"The Java EE platform needs more sophisticated monitoring capabilites and metrics. A lot can be done with JMX, but it is too basic and requires too much manual work."
Croatia,Important,,Very important,,Very important,,Important,,Very important,,Important,,,Very important,Very important,,,Somewhat important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Java EE is already well suited to building practical microservices.,,Java EE should innovate in the same way that non-standard products do.,,2-3 years,,
Zimbabwe,Very important,,Very important,,Very important,,Very important,,Very important,,Very important,,,Very important,Very important,,,Very important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,,
United Kingdom,Very important,"Very important as there are a lot of improvements in HTTP/2, it is the future.",Very important,EE should always be aligned with SE,Very important,,Important,,Very important,,Important,,,Important,Important,,,Somewhat important,Introduce significantly specialized Java EE APIs for reactive programming,I have used RX Java a lot and it would be useful if we could take advantage of it in EE,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,It is OK for Java EE to standardize unproven ideas that seem promising.,Standardisation tends to depend on the best idea and who is using it the most. You can't have that without innovating first.,1-2 years,,
Australia,Important,,Important,,Important,,Somewhat important,,Somewhat important,,Somewhat important,,,Somewhat important,Not important,,,Not important,"Reactive is merely hype, nothing should be done",,"Microservices is merely hype, nothing should be done.",,"Java EE should innovate, but only very carefully.",,1-2 years,,
Netherlands,Very important,I cannot imagine the next iteration of any serious web-based standard or framework not to take (full) advantage of this advance in the underlying technology.,Very important,The very reason for the addition of such features to Java SE 8 - keeping the language up-to-date and relevant - applies to the enterprise APIs as well.,Very important,"The currently available security features in Java EE don't comprise a full end-to-end solution, to really secure an application one has to rely on vendor specific features.",I don't think we should eliminate EJB,"The implicit transactional nature of the EJB programming model cannot simply be replaced with a CDI based solution (emphasis on simply) at this moment. Perhaps it is even best to keep this API around for such purposes, and not try to overload the CDI specification to become a jack-of-all-trades.  That said, I think the old (pre-EJB 3) API should be deprecated (or eliminated altogether).",Very important,"JSON is the defacto standard data format for RESTful web services. JAX-RS is barely usable without better support, one usually has to rely on some 3rd party library for any serious JSON handling.",Important,"With the advent of micro services architectures, there are plenty of use cases that require some 'shared brain' solution (which is not a shared data source).","It's another paradigm, and Java EE should cater for all relevant manners of web development. It fills a space between the component based approach (JSF) and the one where (Javascript) frontends only use (RESTful) backend web services.  Given the popularity of Spring-MVC (see e.g. here: https://dzone.com/articles/java-survey-results-part-ii-web-frameworks), I'd say there is enough 'market share' to support the inclusion.",Important,Somewhat important,,"As said, there is no NOSQL standard. Trying to abstract all these approaches behind a single API would be silly.",Not important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,"The effort should be coordinated centrally, though, to ensure a common and consistent approach.","Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.","I think this calls for a significantly different approach than what some 'industry thinkers' claim - also see the struggling that is going on in the microprofile.io google group discussions.  Having 'micro' services that are deployed with a complete applications server (and a what-not more of containers) will prove to be too heavy and to contain too much overhead. A succinct deployment strategy that allows for the bare minimum, on top of an infrastructure which allows for minimal overhead for communication between services, may well require an additional (alternative) chapter on ""Application Assembly and Deployment"" in the spec.","Java EE should innovate, but only very carefully.","Timing is of the essence here. When there is industry consensus (whatever that may be... taking hype cycles into account?) on (relevant) proven technologies, they should be available, otherwise the relevance of the platform becomes questionable (see e.g. the JSON discussion).  Before an idea becomes an available standard, there is however quite some time spent already. Wouldn't it be a good idea to have so-called incubator stages for standards, in which novel, unproven ideas can be prepared up to a point an actual standardization doesn't need to start from scratch (as we see happening now, e.g. MVC 1.0) and can be promoted to the official standardization stages hitting the ground running? Surely there will be plenty of ideas not making it after the incubator stages, but that is what innovation is about: only picking what works. And it would incorporate innovation into the Java EE culture better.",1-2 years,"The amount of work done between releases is huge. Sometimes this is necessary, but more often it can be split into more manageable pieces (just like in actual projects ;-)). It would make the whole standardization process more flexible, industry feedback would come quicker and that would help the platform to stay relevant.",Management and monitoring are areas that require works as well.
Belgium,Very important,,Important,,Not important,,Somewhat important,,Very important,,Very important,,,Not important,Important,,,Not important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
Austria,Important,,Very important,In my opinion at least date/time should be integrated just like the old Date or Calendar classes to work out of the box with JPA and the other technologies. It does not make any sense to require additional work in order to use core java classes.,Important,I always found it quite challanging to work with JAAS and the vendor specific configuration required to get it to word in different containers. I am really looking forward to simpler and better integrated solutions.,I don't think we should eliminate EJB,,Important,,Important,,,Not important,Somewhat important,,,Somewhat important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Java EE is already well suited to building practical microservices.,,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,,
Ireland,Very important,,Very important,,Very important,,Important,,Very important,,Very important,,,Important,Somewhat important,,,Somewhat important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Wait to see how well microservices is adopted in practical enterprise environments.,,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
United Kingdom,Important,,Very important,,Somewhat important,,I don't think we should eliminate EJB,"Performance wise I still see benefit in using EJB's server side for specific reasons, especially in larger systems.  Could be that I didn't do my research properly in changes of CDI.  Also phasing out 1 for the other is a good goal especially if my research was wrong, but then it should go over 1 or 2 EE specs and not within a few years.",Very important,"JSON API and support are still shallow and in my opinion still too loose. Like the beginning of XML where you would have to validate/map/marshall a lot yourself, JSON also requires a lot of manual interventions and validations still.",Somewhat important,,,Somewhat important,Somewhat important,Honestly I don't have a clue for it's purpose nor its benefits.  Will google deltaspike after this survey,,Important,Wait to see how well reactive is adopted in practical enterprise environments,,Java EE is already well suited to building practical microservices.,,"Java EE should innovate, but only very carefully.",,2-3 years,"Selected 2 til 3 years, but clinge on 3. 3 years is a nice cycle to have 2 years to gather wishes and make a solid spec standard. 1 year to implement for parties while new spec could possibly be started again.  And for companies 3 years is not really intrusive / too fast.  Reason why not more then 3 years: We don't want to become outdated / miss the fun of game changers.",
Turkey,Very important,,Very important,,Somewhat important,,Very important,,Very important,,Somewhat important,,,Very important,Somewhat important,,,Somewhat important,Introduce significantly specialized Java EE APIs for reactive programming,,Java EE is already well suited to building practical microservices.,,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,,
Israel,Very important,,Somewhat important,,Very important,,Very important,,Very important,,Important,,,Important,Very important,,,Not important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Microservices is merely hype, nothing should be done.",,"Java EE should innovate, but only very carefully.",,2-3 years,,"In my opinion the most important thing that is missing in Java EE is modularity ,  Introduce pluggable entities , pluggable rest services , pluggable CDI beans , and make no restrictions on the connection they have with the core project"
Germany,Important,"In any larger project, many web related workloads and tasks can be offloaded to a pure http server such as nginx, thus the requirement to support http2 by java server is definitely important but not critical IMHO.",Important,,Very important,"I believe that it is more important to bring in a robust security api for REST endpoints, native json token support, token invalidation, etc. ",Somewhat important,"The difference between ejb and cdi is not only in the AP but also in the internal operation of the two- the pool handling etc. Therefore the EJBs are faster in perf. tests then CDI beans.   If the EJBs are to be eliminated, we need to make sure, that we do not lose any features - such as @Startup (useful for singletons) etc.",Somewhat important,Most developers already rely on some well-developed json libraries like Jackson. ,Not important,,"As long is it is low level and api surface is small. Just the minimum required changes to support the view rendering, template processing etc.",Important,Somewhat important,,"With the wide range of nosql stores, it would be rather difficult to come up with a concise api that would work across multiple DBs. ",Somewhat important,"Reactive is merely hype, nothing should be done",,Java EE is already well suited to building practical microservices.,"The nature of routing,discovery, etc is far from standardized and varies from env to env depending on scale, platform used, containerization etc.. Therefore forcing a Java API on developers would probably not make much sense.",It is OK for Java EE to standardize unproven ideas that seem promising.,,3-4 years,"Right now, jee is very mature, feature rich and rather developer friendly. However as the main users of EE are enterprise customer it might be tricky to advertise Java EE as stable, industry proven standard with long support if there is a new release every year, and server vendors have to invest time into implementation of new features whilst support several previous releases.",
Sweden,Very important,,Very important,,Important,,I don't think we should eliminate EJB,,Very important,,Important,,,Very important,Important,,,Very important,Introduce significantly specialized Java EE APIs for reactive programming,,Java EE is already well suited to building practical microservices.,,"Java EE should innovate, but only very carefully.",,3-4 years,,
Portugal,Very important,,Very important,,Very important,,Important,,Very important,,Important,,,Important,Somewhat important,,,Not important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,2-3 years,,
Denmark,Very important,,Important,,Very important,,Somewhat important,,Important,,Important,,,Important,Very important,,,Very important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should not standardize ideas that are not clearly proven.,,2-3 years,,
,Very important,,Very important,,Important,,Important,,Important,,Somewhat important,,,Important,Somewhat important,,,Very important,Introduce significantly specialized Java EE APIs for reactive programming,,Wait to see how well microservices is adopted in practical enterprise environments.,,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,,
Austria,Very important,,Important,,Important,,Somewhat important,,Very important,,Very important,,,Somewhat important,Not important,,,Somewhat important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Java EE is already well suited to building practical microservices.,,Java EE should innovate in the same way that non-standard products do.,,2-3 years,,
Greece,Very important,,Very important,,Somewhat important,,Somewhat important,,Very important,,Somewhat important,,,Important,Somewhat important,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,It is OK for Java EE to standardize unproven ideas that seem promising.,,2-3 years,,
Poland,Important,,Important,,Very important,,Somewhat important,,Very important,,Important,,,Important,Somewhat important,,,Somewhat important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,2-3 years,,
Germany,Important,This does require new APIs for response priorisation and possibly low level von APN,Somewhat important,,Important,"Unlike the sample annotation however i think the operational APIs (query session, permission, acl, token) are more important than actual implementations. Controlling statically how a system addresses identity stores does not look very useful to me",Not important,"I don't see a distingtion here, a @Transactional is both a CDI intercepting as well as a session bean ""emulation"".",Important,,Somewhat important,,,Not important,Somewhat important,,,Not important,Wait to see how well reactive is adopted in practical enterprise environments,,Java EE is already well suited to building practical microservices.,,It is OK for Java EE to standardize unproven ideas that seem promising.,,2-3 years,,
Romania,Very important,,Very important,,Very important,,Not important,,Very important,,Very important,,,Important,Important,,,Important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,1-2 years,,
Vietnam,Important,,Important,,Important,,Not important,,Important,,Important,,,Not important,Important,,,Important,Introduce significantly specialized Java EE APIs for reactive programming,,Wait to see how well microservices is adopted in practical enterprise environments.,,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,,
Spain,Very important,,Important,,Very important,,I don't think we should eliminate EJB,,Somewhat important,With an API like Jackson I have all I need,Important,,,Important,Important,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,Java EE should not standardize ideas that are not clearly proven.,,1-2 years,,
Belgium,Very important,,Very important,,Important,,Important,,Very important,,Important,,,Important,Very important,,,Important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,1-2 years,,
Slovakia,Very important,,Very important,,Very important,,Very important,,Very important,,Very important,,,Very important,Very important,,,Very important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
United Kingdom,Very important,Application's that are transported over HTTP/2 will have a much better user experience. ,Very important,I only found out last week that parallel streams are not safe for Java EE. It came a surprise too. I strongly feel that what is available in Java SE should also be safe to use in Java EE. ,Very important,"Questions about security and talk about security come up, in some form, in almost every planning meeting my team have. ",Not important,"I guess if it helps Java EE's branding to clam the headline that ""EJBs are gone"" then that may be a good move. Personally, I like EJB 3's simplicity. In that they are transactional by default and that server's have EJB monitoring. ",Important,I have not had the chance to read up on this.,Very important,Java EE's value is well rooted in default configurations and component pre-assembly. As distributed caching is a component in demand it follows that it should be included in Application Containers.   ,"I think JSF is a superb feet of engineering, why muddy the water with a second paradigm? Java EE should be setting the example, if it is going to continue; and not blindly following the status quo. ",Not important,Somewhat important,"I have not had the chance to read up on this. However, maven works for me as a common system that most project use. ","Perhaps specification should be rationalise by the  each NoSQL supplier; as in one specification for each NoSQL DB. The community could help iron out the details, and a framework for the specification would give the suppliers a grounding when creating the specification. ",Important,"Reactive is merely hype, nothing should be done","Is this relay a software problem? For example, CDI's events are somewhat a contribution to ""reactive"". Of course reactive is also scaling etc. Reactive programming seem to be more of an education, and awareness problem.",Java EE is already well suited to building practical microservices.,,Java EE should not standardize ideas that are not clearly proven.,,2-3 years,"2-3 gives people time to take on new skills. Also, who would write books that have a 1-2 years shelf life.",
United Kingdom,Important,,Important,,Important,,Not important,,Very important,,Somewhat important,,,Not important,Not important,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,Java EE is already well suited to building practical microservices.,,It is OK for Java EE to standardize unproven ideas that seem promising.,,2-3 years,,
Netherlands,Very important,,Important,,Somewhat important,,Not important,,Very important,,Important,,,Not important,Somewhat important,,,Very important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Java EE is already well suited to building practical microservices.,,It is OK for Java EE to standardize unproven ideas that seem promising.,,2-3 years,,
Ukraine,Very important,,Important,,Somewhat important,,Important,,Important,,Somewhat important,,,Somewhat important,Important,,,Very important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,,
Portugal,Very important,HTTP/2 is a big step towards faster communications and applications. Users will for sure benefit from it's improvements so it only makes sense to make it a standard in Java EE.,Very important,"Although there are anew approaches and technologies enterprise applications till have and will have it's core on technologies like JPA, JMS or JAX-RS. It's obviously necessary to make them aligned with Java SE 8 in order to improve development processes and let developers be creative and innovative.",Very important,"Java EE security API is for me one of the poorest parts of Java EE. It implies a lot of old fashioned security definitions and setup which are not very aligned with current applications and enterprise needs. It needs to be more dynamic and manage change and diversity. For me it's one of the most important things in Java EE, but probably one of the baddest areas in terms of maturity.",Somewhat important,,Very important,JSON is the standard in terms of modern service communication and data transfer when there's no need for all the SOAP overhead and security features. It makes sense that it's API provides a better development model and allows developers to quickly take benefit from it.,Very important,This is one of things that tend to get fragmented when developing EE applications. Typically solutions are container dependent and people try to overcome that by implementing wrappers on top of them.,"I thing this is the part where Java has already lost the battle. The typical architectures that we currently implement are service oriented with client side processing with Angular and other similar frameworks. Of course it is an important part of any language but for me it doesn't seems a priority,",Somewhat important,Very important,I thing that this is probably an area where current trends like DevOps will make it become crucial. With continuous delivery becoming the main stream especially with agile projects it's mandatory to make application more configurable.,"It could be important if that doesn't mean making one API for either Relational and non-relational. JPA is mature and very important for enterprise development,  having a similar API for non-SQL makes sense but I think it should be a separate API.",Important,Wait to see how well reactive is adopted in practical enterprise environments,I think it's still not clear how react will evolve and what will become. Better put the effort on other areas that are more important in the short time.,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",Although I agree that Java EE already provides the minimum tools to create micro services I think it would be important to make some de-facto guidelines and tools. I n particular i think it would be important to have well defined standard for self-contained executable jars.,It is OK for Java EE to standardize unproven ideas that seem promising.,"Balance is indeed the keyword, but I will always prevail the standards due the nature of enterprise development. What I think it should happen is that Java EE should have groups, partnerships and people that work ahead of time helping developing the innovative path.. Actually this happens already at some extent with people working on Java EE and other community projects. In the end, what seems clear is that this has worked for a long time since Java is still the most used enterprise language probably because it's not working out to bad ...",2-3 years,If the frequency is to short it will end up fragmenting and people will never take benefit from the improvements. In enterprise environments making a change to a new version it's still a big problem. So it's better to have bigger intervals to let applications and technology mature and then start new ones with all the new benefits.,"I think still that OSGi is a paradigm to look to. Java EE should make it part of it. It is one of the most practical technologies in enterprise environments since it combines a lot of typical customer requirements regarding modular deployments or extensions. Although the Java Module System (JigSaw) will have some of this, I think OSGi is the next level. For me it's a shame that it isn't seen as a part of Java EE future."
Bangladesh,Very important,,Very important,,Somewhat important,,Not important,,Important,,Somewhat important,,,Not important,Somewhat important,,,Important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,1-2 years,"In modern days, release frequency more than 2 years is absurd regardless of enterprise app requirement.",
,Important,,Very important,Especially the datetime API support in JPA could be very usefull !,Somewhat important,,Very important,,Somewhat important,,Very important,,,Very important,Very important,,,Somewhat important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,2-3 years,,
Bulgaria,Very important,,Very important,,Important,,Somewhat important,,Very important,,Important,,,Very important,Very important,,,Very important,"Reactive is merely hype, nothing should be done",,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,2-3 years,,
India,Very important,,Important,,Important,,Somewhat important,,Important,Options like BSON should also be considered,Important,,,Important,Very important,,,Important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,1-2 years,,
Hungary,Very important,,Somewhat important,,Somewhat important,,Very important,,Very important,,Important,,,Somewhat important,Not important,,,Somewhat important,Introduce significantly specialized Java EE APIs for reactive programming,,Wait to see how well microservices is adopted in practical enterprise environments.,,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,,
Germany,Very important,,Important,Date/Time Api is very high on the list,Very important,,Not important,,Important,,Important,,,Important,Somewhat important,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,Java EE is already well suited to building practical microservices.,,It is OK for Java EE to standardize unproven ideas that seem promising.,,2-3 years,"Longer release cycles ensure that there is proper literature on every subject. One of the worst things about the ""js frontend framework of the day"" is that whenever you google something, all you find is allready outdated. ",
Russian Federation,Very important,,Very important,,Somewhat important,,Important,,Important,,Very important,,,Important,Somewhat important,,,Important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,2-3 years,,
Belgium,Important,,Very important,,Not important,,Very important,,Not important,,Somewhat important,,,Not important,Somewhat important,,,Not important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,1-2 years,,
Norway,Very important,,Very important,,Very important,,Important,,Very important,,Very important,,,Very important,Very important,,,Important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
Bangladesh,Very important,,Very important,,Very important,,Very important,,Very important,,Very important,,,Important,Very important,,,Important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Wait to see how well microservices is adopted in practical enterprise environments.,,It is OK for Java EE to standardize unproven ideas that seem promising.,,2-3 years,,
Philippines,Very important,,Very important,,Very important,,Very important,,Very important,,Important,,,Not important,Not important,,,Somewhat important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Java EE is already well suited to building practical microservices.,,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,Make Java EE minimal like removing the app containers like tomcat etc. Or make it optional. There are many ways to spinup a server without tomcat like what playframework did and other minimal java web frework like spark.
Spain,Very important,,Important,,Very important,,I don't think we should eliminate EJB,,Somewhat important,,Very important,,,Important,Not important,,,Somewhat important,Introduce significantly specialized Java EE APIs for reactive programming,,Java EE is already well suited to building practical microservices.,,"Java EE should innovate, but only very carefully.",,3-4 years,,
Austria,Important,,Very important,,Very important,,Somewhat important,,Very important,,Important,,,Important,Somewhat important,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,3-4 years,,
Turkey,Important,,Somewhat important,,Important,,Not important,,Very important,,Somewhat important,,,Not important,Somewhat important,,,Important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,1-2 years,,
United States,Important,,Very important,,Very important,Security issues and reduction of vulnerabilities must be the number one issue today.,Important,"A standard architecture and design patterns is important to the future of this technology.  When researching ""how"" to do something you are inundated with information from various historic technologies via websites, books, videos, etc, and the developer gets lost in what is the ""right"" method. Consolidating down to CDI was always my hope.",Important,"xml was good for its time, JSON is a signifiant improvement. We need to learn as we grow.  ",Somewhat important,I need to learn more about this capability.,"Standard libraries are important in selling a toolset to the stakeholders.  I have not studied this issue, but would encourage a lot of work on vulnerability assessment before even considering moving into it yet. Hopefully we will have learned from history and worked out the bugs ahead of time.",Important,Not important,"When I have an application running, configuration has been complete. You would have to show me some use cases that would explain the need.  A stable, known environment and configuration is key to maintaining and sustaining a product.","Relational databases are still the key for me, I need to research the need for nosql and how it would help me.  java.properties deal with configuration issues for me.. live data? I still use rdbs.",Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,"Let this continue to emerge via evolution. Trying to force an api before the architecture and design patterns are fully defined would not do well. (look how long it will take to extract EJBs, when only a few years ago they were the new and best technology).",Wait to see how well microservices is adopted in practical enterprise environments.,"Let the application container developers (jboss, gf, etc) work on this for another couple years and let it evolve as well.",Java EE should not standardize ideas that are not clearly proven.,"I wish I saw this question earlier, its saying just what I have been. Let the industry innovate.. then standardize later. Don't discourage the use of ""non-standard"" libraries in a production environment, but be sure to be able to identify and maintain them until they become standards.",2-3 years,A few new standards every couple years. Developers can always skip a release while working on updates to their products.,
Portugal,Very important,,Very important,,Somewhat important,,Somewhat important,,Very important,,Somewhat important,,,Important,Somewhat important,,,Not important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,2-3 years,,
Brazil,Very important,,Very important,,Very important,,Somewhat important,,Very important,,Very important,,,Somewhat important,Important,,,Very important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,1-2 years,,
Singapore,Very important,,Very important,,Somewhat important,,Very important,,Important,,Very important,,,Very important,Very important,,,Important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,1-2 years,1.5-2 years,free and open source TCK
Switzerland,Important,,Very important,,Somewhat important,,Not important,,Very important,,Very important,,,Not important,Important,,,Somewhat important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",If Java EE should stay as a specification shared amount different vendors. It should standardize technology but can innovate within some JSR.  Java EE vendor should in their part innovate around Java EE spec and provide new technology.,1-2 years,Small evolutions are better than a big revolution.,
Germany,Very important,Java EE will become  completely  irrelevant in a very short time if it is not keeping up with technical advencements of the web. Period.,Very important,Inconsistency is a platforms death promise.,Somewhat important,Security aspects are very complex and in most cases can not be generalized. So standards will always miss important features or capablities that may be adressed by a particular framework ,Somewhat important,"Elminiating EJB will result in huge number of legacy systems that would need to be rewritten to use CDI instead. Since this would simply not happen in most cases, JavaEE would become a synonyme for legacy enterprise systems that are stuck without a chance of migrating to newer technologies / standards.",Not important,"JSON-P spec is a bad joke, no need to cuddle up whats already dead",Important,,Component based Java Web-Frameworks are already dying. An action oriented standard web-framework is overdue.,Very important,Important,Thinking about Spring-like profiles and environment abstraction. A must have for every non-trivial software project.,Not worth the effort as there is no such thing as a common concept among the different Nosql solutions.,Not important,Wait to see how well reactive is adopted in practical enterprise environments,,Java EE is already well suited to building practical microservices.,,Java EE should not standardize ideas that are not clearly proven.,,3-4 years,,
Brazil,Very important,,Very important,,Important,,Very important,,Very important,,Important,,,Very important,Very important,,,Somewhat important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,,
Germany,Important,,Very important,,Very important,,Not important,,Somewhat important,,Very important,,,Important,Somewhat important,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,2-3 years,,
Spain,Very important,SSE support is also important,Very important,,Important,,Important,,Very important,,Somewhat important,,,Somewhat important,Somewhat important,,,Very important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Java EE is already well suited to building practical microservices.,,"Java EE should innovate, but only very carefully.",,1-2 years,,
United States,Very important,,Very important,,Not important,,Very important,,Very important,,Very important,,,Not important,Very important,,,Very important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
Spain,Important,,Somewhat important,,Very important,,I don't think we should eliminate EJB,,Very important,,Somewhat important,,,Very important,Somewhat important,,,Important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Java EE is already well suited to building practical microservices.,,Java EE should innovate in the same way that non-standard products do.,,2-3 years,,
Australia,Very important,,Very important,,Very important,,Somewhat important,,Very important,,Very important,,,Very important,Very important,,,Very important,Wait to see how well reactive is adopted in practical enterprise environments,,Java EE is already well suited to building practical microservices.,,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,,
United States,Very important,,Very important,,Very important,,Important,,Not important,"there are plenty of good JSON java libraries, no need to put it into the JavaEE",Somewhat important,,,Somewhat important,Important,,,Not important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,1-2 years,,
Argentina,Very important,,Important,,Somewhat important,,I don't think we should eliminate EJB,,Important,,Somewhat important,,,Important,Somewhat important,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,1-2 years,,
Colombia,Very important,,Very important,,Very important,,Important,"For as long the remaining specs implement important ejb functionality as mentioned in the question, I'm all up for unification.",Very important,,Somewhat important,,,Somewhat important,Somewhat important,"I only see this feature relevant when implementing multitenancy apps, which is not the most common scenario I've come across in 15 years of experience.","I don't think this is a good idea. There are many different nosql databases with very different scopes. How is it possible to unify an api to tackle graph, document, column oriented databases? Is it worth the effort?",Somewhat important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,"Streaming an lamda  are taking the world, just fix concurrency for java ee and that will make reactive more robustly supported (do ""robustly"" even exist?)",Java EE is already well suited to building practical microservices.,"Remove unneded complexity, wildfly swarm should be the example to follow, by letting the ""just enough app server"" idea to stack and put together an application.","Java EE should innovate, but only very carefully.","For me, standarization is a refining activity, which means to take the best approaches and bind them together in a way that makes sense and ease developer's work. Innovation by innovation's sake is not worth the effort since it takes resources away from other areas that need improvements. For instance, I don't like criteria Api at all, not worth the effort when compared with SQL or JOOQ, for me that work should have been put better in other spec, like cdi for example.",2-3 years,Prunning and partial upgrades.,"Java ee security needs more focus. Integration patterns, bpm? Is there any spec for these? Service discovery, clustering?"
Brazil,Very important,,Very important,,Very important,,Somewhat important,,Very important,,Important,,,Not important,Somewhat important,,,Somewhat important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Java EE is already well suited to building practical microservices.,,It is OK for Java EE to standardize unproven ideas that seem promising.,,2-3 years,,
Norway,Somewhat important,Not important enough to stall the process. ,Somewhat important,Minor objection to the word fully.    Not important enough to stall the process. ,Important,,I don't think we should eliminate EJB,At least not yet. (And I am not qualified to decide. ),Important,Don't feel the pain yet but assume it will hit us as well.  Also important for companies considering building on JavaEE. ,Important,,"Have been missing this for a long time.  Needs to be done carefully to end up with a good pragmatic solution.  Facelets actually got a good deal right wrt embedding and composition, only the components very easily gets inthe way as soon as you leavd the CRUD zone.",Very important,Somewhat important,,"At least not for us , yet.",Not important,Wait to see how well reactive is adopted in practical enterprise environments,,Java EE is already well suited to building practical microservices.,,"Java EE should innovate, but only very carefully.",,2-3 years,,"Documentation.  In addition to documenting each piece there should be end-to-end docs on building complete solutions. Rails and Symfony won a lot of developer mindshare this way and IMO JavaEE is way simpler than Rails, the only problem is getting everything pieced together first. (Exceptions exist but most examples are component level, not application-level.)"
Cuba,Very important,,Important,,Very important,,I don't think we should eliminate EJB,,Very important,,Important,,,Important,Not important,,,Very important,Wait to see how well reactive is adopted in practical enterprise environments,,Java EE is already well suited to building practical microservices.,,Java EE should not standardize ideas that are not clearly proven.,,2-3 years,,
Dominican Republic,Important,,Very important,,Important,,Somewhat important,,Very important,,Somewhat important,,,Somewhat important,Somewhat important,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,3-4 years,,
United States,Important,,Very important,,Important,,Very important,,Important,,Important,,,Somewhat important,Important,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,2-3 years,,
Poland,Important,,Very important,,Not important,,I don't think we should eliminate EJB,,Very important,,Very important,,,Not important,Very important,,,Not important,Introduce significantly specialized Java EE APIs for reactive programming,,Java EE is already well suited to building practical microservices.,,"Java EE should innovate, but only very carefully.",,1-2 years,,
,Very important,,Very important,,Very important,,Somewhat important,,Very important,,Important,,,Somewhat important,Somewhat important,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,1-2 years,,"Java EE need to priorize improvements in a pareto principle way, improving what most systems use. And modernize old apis, like Java EE Security in general. "
Brazil,Very important,,Very important,The new date/time API is sorely missed in JPA and JSF,Important,"More than revamping security, Oracle needs to improve the QA because the number of vulnerabilities popping in Java the last few years is unnaceptable.",I don't think we should eliminate EJB,"Both CDI and EJB have their roles, I don't think it's a good idea.",Somewhat important,,Important,,,Not important,Important,,"I don't think it's possible at all, let alone when the NoSQL is in its infancy, to bring a generic, one-size-fits-all API. The chance of such API become inadequate and obsolete is too high.",Not important,"Reactive is merely hype, nothing should be done",,"Microservices is merely hype, nothing should be done.",,Java EE should not standardize ideas that are not clearly proven.,,2-3 years,,
Czech Republic,Very important,,Very important,,Very important,,Important,,Very important,,Somewhat important,,,Very important,Important,,,Important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,1-2 years,,
Slovakia,Not important,,Important,,Important,,Very important,,Important,,Very important,,,Very important,Important,,,Not important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Java EE is already well suited to building practical microservices.,,It is OK for Java EE to standardize unproven ideas that seem promising.,,2-3 years,,
,Very important,,Important,,Very important,,Somewhat important,,Important,,Important,,,Very important,Important,,,Very important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,2-3 years,,
Poland,Important,,Very important,,Very important,,,,Important,,,,,Important,,,,,,,,,,,,,
Italy,Important,,Important,,Very important,,Important,,Very important,,Very important,,,Somewhat important,Very important,,,Not important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,2-3 years,,
,Very important,,Important,,Very important,,Somewhat important,,Important,,Very important,,,Somewhat important,Important,,,Not important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,3-4 years,,
Hungary,Very important,,Important,,Very important,,Somewhat important,,Important,,Important,,,Somewhat important,Important,,,Very important,Wait to see how well reactive is adopted in practical enterprise environments,,Java EE is already well suited to building practical microservices.,,"Java EE should innovate, but only very carefully.",,1-2 years,,
Tunisia,Important,,Important,,Important,,Very important,,Very important,,Very important,,,Very important,Very important,,,Important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
United States,Somewhat important,,Very important,,Very important,,Very important,,Very important,,Not important,,,Important,Not important,,,Important,Wait to see how well reactive is adopted in practical enterprise environments,,Java EE is already well suited to building practical microservices.,"I see the biggest challenge is developing a ""how to"" which integrates well suited Java EE with other technologies (single sign on, load balancing) to create a microservices architecture which is good for everyone else who's not Netflix",Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
Serbia,Important,,Very important,,Important,,Important,,Very important,,Very important,,,Somewhat important,Somewhat important,,,Not important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,1-2 years,,
Bangladesh,Very important,,Important,,Very important,,Very important,,Very important,,Very important,,,Very important,Very important,,,Very important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,2-3 years,,
Ukraine,Important,,Very important,,Very important,,Important,,Somewhat important,,Somewhat important,,,Very important,Very important,,,Very important,"Reactive is merely hype, nothing should be done",,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,,
Australia,Very important,HTTP/2 is the future of the web.,Very important,This is necessary to keep developers interested in Java 8 - to have Java 8 new features.,Important,,Important,EJB is one reason people lost interested in Java EE.,Very important,First-class JSON support is required for web apps.,Important,,"This space is already owned by Spring MVC and the Spring Boot stack. And, RESTful APIs for JavaScript front-eds.",Not important,Important,,"It is difficult to provide a common API to all the NoSQL. Instead, management APIs could be used instead.",Not important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,"While reactive is important, it is not necessary to make it top-level in Java EE since there are already existing frameworks. It could be an adapter to say, Netflix reactive.","Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.","The support must be provided though not necessarily using ""microservices"" terminology since much of that is hype and is experiencing some backlash.","Java EE should innovate, but only very carefully.",Java EE should be conservative.,1-2 years,"It should have a semantic versioning scheme, and not just EE 7, EE 8, and other whole numbers.","The spec should be fully open, not like the current specs that need a license to agree with."
Portugal,Important,,Important,,Important,,Somewhat important,,Somewhat important,,Important,,,Important,Somewhat important,,,Not important,Wait to see how well reactive is adopted in practical enterprise environments,,Java EE is already well suited to building practical microservices.,,It is OK for Java EE to standardize unproven ideas that seem promising.,,3-4 years,,
Colombia,Important,,Very important,,Somewhat important,,Important,"EJB was good, but now it's just the reason people are leaving JEE",Very important,,Important,,,Important,Very important,,,Very important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",We have to use spring and netflix OS,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,,
United States,Important,,Important,"Particularity JPA, JMS, and JAX-RS",Important,,Not important,,Very important,,Somewhat important,,,Very important,Very important,,,Not important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,1-2 years,,
Ukraine,Important,HTTP/2 is for sure needed protocol improvement but not one of critical needs.,Very important,"As Server-side development need to be robust, Java EE must be fully aligned to Java SE 8 best features.",Very important,,Very important,,Very important,,Important,important but not critical,,Somewhat important,Somewhat important,,,Important,Introduce significantly specialized Java EE APIs for reactive programming,,Java EE is already well suited to building practical microservices.,,"Java EE should innovate, but only very carefully.",,2-3 years,,
United States,Very important,,Very important,,Very important,,Not important,,Very important,,Important,,,Somewhat important,Somewhat important,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,2-3 years,,
Brazil,Important,,Very important,,Important,,Very important,,Very important,,Important,,,Important,Important,,,Important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,2-3 years,,
United States,Very important,,Very important,,Very important,,Not important,,Very important,,Not important,,,Not important,Very important,,,Very important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
Czech Republic,Very important,,Very important,This is essential. Maybe not 100% doable in v8 but it makes sense to do as much as possible.,Important,,Somewhat important,This is nice but probably not doable in v 8,Very important,"""JSON has replaced XML as the de-facto data interchange format."" this was already said",Somewhat important,,nice to have,Not important,,,better good support later than buzzword checked ASAP,Important,Introduce significantly specialized Java EE APIs for reactive programming,,Java EE is already well suited to building practical microservices.,,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,Smaller releases more often. ,
Germany,Very important,"Web-Technologies are the most important technologies at current time. Every performance and feature-enhancement is good and important to deliver fast and reliable applications. Even for REST, what is more and more popular, will benefit from HTTP/2",Very important,Especially for the new data-types (Date/Time API) we need an update to use in JPA.,Very important,"JavaEE security is somewhat special, every project has it's own proprietary implementation. Ther a filter-solutions, interceptor-solutions, realms (which a proprietary to the app-server) and so on... we need a new customizable and default way to secure applications and resources (if I think in REST).",Somewhat important,"I would appreciate using only one framework instead of two (EJB and CDI), but EJB is currently the most fastest technology and it has great support for monitoring throught the App-server. All these benefits must be taken to CDI, if EJBs should be replaced with.",Very important,"JSON is wide-used, so it is very important to be up to date. In addition, JSON should be better integrated to JAXB, so that entities can better be transformed form/to JSON.",Important,"A default way for caching is always a good idea. Currently, you have to deal with the proprietary features of current Cache-Frameworks...","We have so many WebFrameworks currently to choose from, a new one is really not important.",Not important,Not important,"It would be nice to have standardized ways for technical concerns like configuration, but this can either be done via injection in combination with REST-endpoints or even distributable configuration over settings, which are stored and provided via haszelcast.","I would be happy to have something, but there NoSQL-concepts are so widely different, that this would be very difficult to define.",Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,Java EE is already well suited to building practical microservices.,"But new features like in option 1 (""Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads."") are very welcome.",It is OK for Java EE to standardize unproven ideas that seem promising.,,3-4 years,Releases in a 3-4 years rate are enough... ,
Netherlands,Important,,Important,,Somewhat important,,Important,,Important,,Not important,,,Not important,Important,,,Not important,Wait to see how well reactive is adopted in practical enterprise environments,,Java EE is already well suited to building practical microservices.,,"Java EE should innovate, but only very carefully.",,2-3 years,,
Poland,Important,,Very important,,Very important,,Somewhat important,,Somewhat important,,Important,,New MVC Framework is critical! I do not want to use spring anymore. I want my war thin.,Very important,Important,It could make testing easier.,,Not important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,Java EE should not standardize ideas that are not clearly proven.,,2-3 years,,
,Very important,,Very important,,Important,,I don't think we should eliminate EJB,,Very important,,Important,,,Somewhat important,Important,,,Somewhat important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Wait to see how well microservices is adopted in practical enterprise environments.,,It is OK for Java EE to standardize unproven ideas that seem promising.,,2-3 years,,
Greece,Very important,,Very important,,Very important,,Not important,,Very important,,Not important,,,Very important,Very important,,,Not important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,Java EE should not standardize ideas that are not clearly proven.,,3-4 years,,
Mexico,Very important,,Very important,,Important,,I don't think we should eliminate EJB,,Important,,Important,,,Very important,Very important,,,Very important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Java EE is already well suited to building practical microservices.,,Java EE should innovate in the same way that non-standard products do.,,2-3 years,,
Colombia,Important,,Very important,,Very important,,Important,,Very important,,Important,,,Somewhat important,Somewhat important,,,Somewhat important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Java EE is already well suited to building practical microservices.,,Java EE should innovate in the same way that non-standard products do.,,1-2 years,"I'd like to say that it'd be interesting that JavaEE was more dynamic regarding releases, not expecting a huge release to deliver new features, but improving and delivering new features at the moment that are ready.   This way we would be able to access new features as soon as those are ready, and not when a new big major release is ready.  Something like that could improve the platform, give the idea that JavaEE is dynamic and offers new feature soon to support developers' productivity.",Thanks for this process in order to make Java a better Enterprise Platform.
Egypt,Very important,,Important,,Very important,,Important,,Very important,,Very important,,,Very important,Very important,,,Very important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,,Thank You ALL for you great JOB and IDEAs
Argentina,Very important,,Important,,Important,,Important,,Somewhat important,,Somewhat important,,,Important,Somewhat important,,,Not important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,2-3 years,,
United States,Very important,,Important,,Important,,Important,,Very important,,Important,,,Very important,Important,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
Norway,Very important,,Important,,Important,,Not important,,Very important,,Somewhat important,,,Not important,Not important,,,Important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Java EE is already well suited to building practical microservices.,,,,2-3 years,,
Nicaragua,Very important,,Very important,,Important,,Important,,Important,,Very important,,,Somewhat important,Not important,,,Not important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,2-3 years,,
Hungary,Very important,,Important,,Important,,Somewhat important,,Very important,,Very important,,,Somewhat important,Important,,,Very important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,It is OK for Java EE to standardize unproven ideas that seem promising.,,2-3 years,,
Pakistan,Somewhat important,,Very important,,Very important,,Very important,,Very important,,Somewhat important,,,Very important,Very important,,,Very important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,1-2 years,,
United States,Very important,,Very important,,Very important,,Very important,,Very important,,Very important,,,Very important,Somewhat important,,,Not important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,2-3 years,,
Russian Federation,Very important,,Very important,,Very important,,Very important,,Very important,,Very important,,,Very important,Very important,,,Very important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,fuck off i hate java
Canada,Very important,,Very important,I've had to implement my own converters for both JSF and JPA on projects where LocalDate was used instead of the 2-decades-obsolete Date api; use of Java8 features really should be seamless!,Important,"I don't believe it's every going to be quite that simple, but whatever it is, please move it into the EE standard instead of leaving it server-specific - this is a major botch in the portability that the technology now lets us correct, so yes, please do!",Important,"We got rid of all the EJB2.x cruft some while back, so let's keep the momentum on this one too!",Somewhat important,"Pattern this after JACKSON, don't reinvent the flat tire. Again.",Important,,"This is only important because people thought they wanted it and Oracle got it 90% implemented before ""the fall"", so let's keep it going, finish it, and make sure it is server-independent (current draft implementation doesn't fly on WildFly, for example)",Important,Somewhat important,,"May be too early to standardize this or, as the survey points out, divergent nature of NoSQL db's.",Not important,Introduce significantly specialized Java EE APIs for reactive programming,"I think it's more than hype but again, it may be too early to standardize? Not sure on this one...",,"I'm all over the map on this one, so: abstaining.","Java EE should innovate, but only very carefully.",,2-3 years,"I'd vote for either 1-2 or 2-3 years, but you used a radio button selection.",Time alone will tell if so.
United Kingdom,Important,,Very important,,Very important,,Very important,,Very important,,Important,,,Very important,Very important,,,Not important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
Japan,Very important,It's essential in today web.,Somewhat important,,Very important,,I don't think we should eliminate EJB,,Somewhat important,,Somewhat important,,"If it will look like VRaptor 4 for example or ASP.NET MVC5, then no problem.",Somewhat important,Somewhat important,,,Not important,Introduce significantly specialized Java EE APIs for reactive programming,,Java EE is already well suited to building practical microservices.,,"Java EE should innovate, but only very carefully.",Reactive was proven for example.,2-3 years,"Usually, a technology in proven to be useful between 2 and 3 years.",Asynchronous JDBC Drivers and specification. 
Italy,Very important,,Very important,,Important,,Somewhat important,,Very important,,Important,,,Important,Somewhat important,,,Very important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,,
Colombia,Important,,Very important,,Very important,,Important,,Important,,Important,,,Important,Important,,,Very important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,Java EE should not standardize ideas that are not clearly proven.,,2-3 years,,"I´m not sure if this Java EE8/Oracle issue is just a coincidence with the moves of Microsoft and the slow ""killing"" of the Java Version of Minecraft. The new C++ version won´t allow Mods, and this will basically kill one of the Biggest Java programmers community. I would prefer to be wrong on this one, since Mods are a big foundation for the success of Minecraft. The new MC Education Edition revealed on June, is just confirming this concern."
Brazil,Very important,,Very important,,Important,,Not important,,Very important,,Somewhat important,,,Somewhat important,Not important,,,Somewhat important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,It is OK for Java EE to standardize unproven ideas that seem promising.,,2-3 years,,
Germany,Important,,Important,,Very important,,I don't think we should eliminate EJB,,Somewhat important,,Important,,,Not important,Somewhat important,,,Very important,"Reactive is merely hype, nothing should be done",,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,1-2 years,,
Ukraine,Very important,,Very important,,Very important,,Important,,Very important,,Somewhat important,,,Very important,Important,,,Very important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,2-3 years,,
Bulgaria,Very important,It is the new HTTP standard after all and as performance is criticial for web application Java EE should make the most out of this new standard.,Somewhat important,It should be aligned with features that could be adapted and makes sense to adapt them in the context of Java EE. Fork/join for example is not one of them at present (e.g. due to the common fork join pool). However - for others such as lambdas it would make sense to refactor internally anonymous classes wherever possible to boost performance. Support for some of the Java 9 features should also be considered as a preliminary step for better integration in Java EE 9 maybe.,Very important,The Java EE security API should address the risk of recently uncovered modern-day threats and make it more easier for developers (and enforce them) to establish security in a declarative manner.,Not important,Although an older API many Java EE applications still make huge use of EJBs. I doubt many would like to migrated to Java EE 8 if EJBs are eliminated and that would take a risky and time-consuming refactoring. It would make more sense to evolve CDI with new features and allow for applications to have a smooth migration path from EJBs to CDI beans.,Somewhat important,,Somewhat important,JCache is somewhat not widely adopted and still has some implementation issues. As I think the API is close to become ready for enterprise use it still needs some more adoption before being targeted for Java EE.,If one is to use an action-oriented framework better use Struts. Better integration with Angular-like libraries should be provided at the JSF layer rather than introducing an entirely new web framework alongside I think. ,Not important,Important,Dynamic services would be a vital component to enable a configurable microservice-style of configuration in a Java EE application. In order to support microservice-like Java EE architectures I think this is an important feature.,I think that Java EE should provide some additional utilities to simplify integration with NoSQL datastores I think that the diversity of NoSQL datastores will make it very difficult to dervice a common general purpose API for accessing NoSQL datastores.,Not important,Introduce significantly specialized Java EE APIs for reactive programming,Reactive can be easily supported by means of third-party libraries such as RxJava. However if the Java 9 Flow class is adopted as the central unit of doing reactive programming in Java 9 then Java EE may consider some API for deriving reactive stream on the basis of the Flow class.,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",You already suggested one :- )) (dynamic configuration) although there is some effort in external frameworks (such as SnoopEE) to provide discovery for Java EE. More effort should be provided to make Java EE microservice - aware I think. ,"Java EE should innovate, but only very carefully.",Innovation should be derived on the basis of practical requirements and workarounds for problems hit in certain Java EE use cases I think.,2-3 years,Release cycles may not be fixed - better invest more time in delivering something practical and useful that trying to deliver fast (apart from bug fixes and other minor updates).,
Spain,Somewhat important,,Very important,,Very important,,Somewhat important,,Important,,Somewhat important,,,Important,Not important,,,Not important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,1-2 years,,
Italy,Very important,,Very important,,Important,,I don't think we should eliminate EJB,,Very important,,Somewhat important,,,Very important,Important,,,Very important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,2-3 years,,
Germany,Very important,,Very important,,Not important,,Important,,Very important,,Somewhat important,,,Somewhat important,Important,,,Not important,Wait to see how well reactive is adopted in practical enterprise environments,,Java EE is already well suited to building practical microservices.,,"Java EE should innovate, but only very carefully.",,3-4 years,,
Spain,Very important,,Very important,,Not important,,Very important,,Very important,,Very important,,,Not important,Very important,,,Not important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
Poland,Somewhat important,,Very important,"If JavaMoney will be incorporated into Java9, it would be also nice to have support for ""Money"" types for JSF or JPA converters",Important,,Very important,,Very important,,Somewhat important,,,Important,Very important,"This is one of the reasons why it is hard to do in-app installation wizard, just like PHP CMSes have.",,Not important,Wait to see how well reactive is adopted in practical enterprise environments,I don't really know,Java EE is already well suited to building practical microservices.,Startup time might be important for me,Java EE should not standardize ideas that are not clearly proven.,"Innovations may be provided by vendors, no need to standardize them",1-2 years,,
Australia,Very important,,Very important,,Important,,Not important,,Very important,,Important,Depends on the actual performance. It should be as good as existing solutions.,,Somewhat important,Important,,,Important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,,
United States,Very important,,Very important,,Somewhat important,,Not important,,Important,,Important,,,Not important,Not important,,,Not important,Wait to see how well reactive is adopted in practical enterprise environments,,Java EE is already well suited to building practical microservices.,,Java EE should not standardize ideas that are not clearly proven.,,1-2 years,,
Vietnam,Very important,,Very important,,Very important,,Important,,Important,,Important,,,Very important,Very important,,,Somewhat important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,,,2-3 years,,
Ecuador,Very important,,Very important,,Very important,,I don't think we should eliminate EJB,,Very important,,Very important,,,Important,Important,,,Not important,"Reactive is merely hype, nothing should be done",,"Microservices is merely hype, nothing should be done.",,Java EE should not standardize ideas that are not clearly proven.,,3-4 years,,
United States,Very important,HTTP/2 support is very important to maintain relevance in the evolving world of enterprise software.,Very important,,Somewhat important,,Somewhat important,"Moving to a single API is important to simplify the platform for new developers. Additionally, migrating EJB functionality into the CDI world may finally do away with the stigma that EJB never fully shed, sadly.",Very important,Critical to stay relevant with evolution of web development.,Important,,Important to allow standardization of MVC pattern. This niche seems to largely be filled by Spring MVC currently and would benefit from standardization.,Very important,Somewhat important,,,Somewhat important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Wait to see how well microservices is adopted in practical enterprise environments.,,It is OK for Java EE to standardize unproven ideas that seem promising.,,2-3 years,,
United States,Very important,,Very important,,Very important,,Important,CDI is great. We should align more closely with it.,Important,,Very important,,,Very important,Important,,,Not important,Wait to see how well reactive is adopted in practical enterprise environments,,Java EE is already well suited to building practical microservices.,,"Java EE should innovate, but only very carefully.","Some libraries like jOOQ could use some exposure by standardization. However, everything must be done carefully with low risk. ",1-2 years,Every 2 years should be a good cadence,"Java EE is important. It is important to Java the language, Spring the framework, and the enterprise in general."
Australia,Very important,,Very important,,Very important,,Very important,,Very important,,Very important,,,Somewhat important,Not important,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,,
Poland,Very important,,Very important,,Important,,Somewhat important,,Very important,,Very important,,,Somewhat important,Somewhat important,,,Very important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,1-2 years,,
Romania,Important,,Very important,,Important,,Important,,Very important,,Somewhat important,,,Important,Important,,,Not important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,3-4 years,,
Germany,Very important,,Important,,Important,,Not important,,Important,,Important,,,Not important,Not important,,,Not important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Java EE is already well suited to building practical microservices.,,"Java EE should innovate, but only very carefully.","Instead, incorporate third-party libs like Spring Security when they prove to be successful/useful.",1-2 years
Switzerland,Very important,,Very important,,Somewhat important,,Not important,,Important,,Somewhat important,,,Somewhat important,Somewhat important,,,Important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,2-3 years
United States,Very important,,Important,,Very important,,Somewhat important,,Somewhat important,,Somewhat important,,,Somewhat important,Important,,,Very important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Wait to see how well microservices is adopted in practical enterprise environments.,,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years
Spain,Important,,Important,,Somewhat important,,Not important,,Important,,Somewhat important,,,Very important,Very important,,,Important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,It is OK for Java EE to standardize unproven ideas that seem promising.,,2-3 years
South Africa,Very important,,Very important,,Very important,,Somewhat important,,Very important,,Very important,,,Somewhat important,Very important,,,Important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years
Austria,Important,,Very important,,Important,,Somewhat important,,Very important,,Important,,,Somewhat important,Somewhat important,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,2-3 years
United Kingdom,Very important,,Very important,,Very important,Spring Security should be the basis of this. It makes securing applications so much easier.,Somewhat important,,Very important,,Not important,"There are very mature solutions already in the market, I don't believe an API would make this any better.",I think it missed the train and now comes too late.,Somewhat important,Somewhat important,,,Somewhat important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Java EE is already well suited to building practical microservices.,,It is OK for Java EE to standardize unproven ideas that seem promising.,,3-4 years
Spain,Important,,Very important,,Very important,,Important,,Very important,,Important,,,Very important,Important,,,Very important,,,Java EE is already well suited to building practical microservices.,,Java EE should innovate in the same way that non-standard products do.,,2-3 years
Slovakia,Very important,,Somewhat important,,Important,,I don't think we should eliminate EJB,,Not important,,Somewhat important,,,Somewhat important,Very important,,,Somewhat important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,1-2 years
,Important,,Somewhat important,,Very important,,Important,,Important,,Important,,,Very important,Somewhat important,,,Not important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Wait to see how well microservices is adopted in practical enterprise environments.,,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years
Slovenia,Somewhat important,,Very important,,Very important,,Not important,,Very important,,Very important,,,Very important,Important,,,Somewhat important,,I don't know if reactive is needed on the server side...,,Rechristening Payara to Pariah... nice touch :),It is OK for Java EE to standardize unproven ideas that seem promising.,,3-4 years
Philippines,Very important,,Very important,,Very important,,I don't think we should eliminate EJB,,Very important,,Very important,,,Very important,Very important,,,Very important,Wait to see how well reactive is adopted in practical enterprise environments,,Java EE is already well suited to building practical microservices.,,"Java EE should innovate, but only very carefully.",,4-5 years
Poland,Somewhat important,,Very important,,Very important,,Important,,Somewhat important,,Important,,,Not important,Important,,,Very important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,2-3 years
Sweden,Very important,,Important,,Somewhat important,,Not important,,Very important,,Somewhat important,,,Not important,Somewhat important,,,Somewhat important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,2-3 years
India,Important,,Very important,,Very important,More than features we need lot of examples and clear documentation,I don't think we should eliminate EJB,,Very important,,Not important,,,Not important,Very important,,,Very important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,3-4 years
Ghana,Very important,,Very important,,Not important,,Somewhat important,,Important,,Very important,,,Somewhat important,Very important,,,Not important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,2-3 years
United States,Very important,,Very important,,Very important,,I don't think we should eliminate EJB,,Very important,,Somewhat important,,,Not important,Very important,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,1-2 years,,
Switzerland,Very important,,Very important,,,,I don't think we should eliminate EJB,,Important,,Somewhat important,,,Somewhat important,Important,,,Somewhat important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Java EE is already well suited to building practical microservices.,,Java EE should innovate in the same way that non-standard products do.,,4-5 years,,
India,Very important,,Very important,,Important,,Somewhat important,,Somewhat important,,Somewhat important,,,Not important,Important,,,Somewhat important,Introduce significantly specialized Java EE APIs for reactive programming,,Wait to see how well microservices is adopted in practical enterprise environments.,,Java EE should not standardize ideas that are not clearly proven.,,2-3 years,,
South Africa,Very important,,Very important,,Very important,This is one of the most difficult features to port between application servers because of the lack of a comprehensive API to deal with all the authentication and authorization possibilities and custom implementations,I don't think we should eliminate EJB,,Important,,Very important,I also feel this is a feature lacking in the EE environment and should be standardized.,I'm not involved the web part of EE but I could see that it could be useful to people,Somewhat important,Somewhat important,,,Somewhat important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,1-2 years,,
France,Very important,,Very important,,Very important,,Important,,Important,,Very important,,,Somewhat important,Very important,,,Important,Introduce significantly specialized Java EE APIs for reactive programming,,Java EE is already well suited to building practical microservices.,,"Java EE should innovate, but only very carefully.",,2-3 years,,
Belgium,Very important,,Important,,Very important,,Important,,Very important,,Important,,,Very important,Very important,,,Very important,Wait to see how well reactive is adopted in practical enterprise environments,,Java EE is already well suited to building practical microservices.,,"Java EE should innovate, but only very carefully.",,2-3 years,,
Morocco,Very important,,Very important,,Very important,,Not important,,Very important,,Very important,,,Important,Somewhat important,,,Not important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Microservices is merely hype, nothing should be done.",For me microservices is an architecture. I think that jee as a platform should not be seen as a framework that follows some specific architecture principles. There are enough frameworks out there that offer tools/ways of building specific applications following the microservices visions. So there is no need for me to add stuff to jee for that matter.,"Java EE should innovate, but only very carefully.",,2-3 years,,
Slovakia,Somewhat important,,Somewhat important,it would be nice to have,Important,,Very important,Please migrate EJB (except for remote EJB) to CDI and enable multitenancy on JPA (no more static datasource).,Not important,,Not important,,"I want to have similar to Angular where the client UI ""gets"" the data from server via REST. I guess Java MVC uses the REST on server side, but I mean REST on client side.",Very important,Very important,,,Not important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,Please continue with reactive MVC.,Wait to see how well microservices is adopted in practical enterprise environments.,"Segregating CDI and EJB certification profiles of miscellaneous application servers would be the first step. Maybe separating CDI features and web profile. I guess the previous question ""5. Eliminating EJB"" determines this answer.","Java EE should innovate, but only very carefully.",Somehow innovate the process in order to find it faster and interesting to JSR participants. Maybe splitting API into fine grained API where conflicts would be minimized in particular JSR group. Maybe separate profiles and release Java EE API per profile individually and in parallel which would make developers and users more happy instead of waiting for whole bunch of profiles in one milestone.,1-2 years,Somehow innovate the process in order to find it faster and interesting to JSR participants. Maybe splitting API into fine grained API where conflicts would be minimized in particular JSR group. Maybe separate profiles and release Java EE API per profile individually and in parallel which would make developers and users more happy instead of waiting for whole bunch of profiles in one milestone.,
,Very important,,Very important,,Somewhat important,,Important,,Very important,,Not important,,,Not important,Somewhat important,,,Not important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
Argentina,Very important,,Very important,,Very important,,Somewhat important,,Very important,,Important,,,Important,Somewhat important,,"It would be better to determine NoSQL database types (document, graph,...) and  create a standard data access for each type. In the case of key/value stores, JPA may overlap with JCache",Very important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,1-2 years,,
Mexico,Very important,,Very important,,Important,,Important,,Very important,,Important,,,Very important,Very important,,,Very important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,It is OK for Java EE to standardize unproven ideas that seem promising.,,2-3 years,,
Sweden,Very important,,Important,,Very important,,Very important,,Important,,Very important,,,Important,Very important,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,Java EE is already well suited to building practical microservices.,,"Java EE should innovate, but only very carefully.",,2-3 years,,
United States,Very important,,Important,"If we not implement java 8 the developers have less tools to make great apies , then they going to use other tools that offers what java already have, it does make sence ",Very important,,Not important,,Very important,,Very important,,"JSF does not full fill current market requeriments , is just for companies does not want to work with full stack or front end developers , but the companies that need front end ,do not consider javaEE as an option , does JEE continue ignoring this market ",Very important,Important,,"Well, connector o very extensible interface but I do not think some standards like JPA ,take advantage of unique features are the reasons to use NoSql .",Somewhat important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,"If you do not try , just wait what others do, then the JEE supports it , all the market will be  using other tools ",1-2 years,Early feedback is key for building mature products ,
United States,Important,,Somewhat important,,Important,,Somewhat important,,Important,,Very important,,,Somewhat important,Very important,,,Important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,1-2 years,,
United States,Very important,"Save out of the box, binary on the wire and in line with websockets (JSR-356?) would be a big plus.",Very important,"Functional capabilities are nice but we aren't using them heaviliy, YET. But the most important thing is smoother and more intuitive concurrency. Processors are just shipping with more cores and I'd like my apps and container to take full advantage.",Important,Would be nice to get this into the app and out of the apps XXXX.xml and container configuration. It would seem to be a step in the right direction to making apps more fully portable.,I don't think we should eliminate EJB,"I like EJBs. They seem to be a powerful and durable part of the API. Plus, you can front and reuse them with other parts of your applications. For instance we have websockets that utilize EJBs for the heavy lifting AND we have JSF/BB that use the same EJBs. If something needs troubleshooting having EJBs at the center of our app makes zeroing in on the problem a breeze. Plus, our apps tend to communicate with multiple DBs so integration at this level is nice as well.",Very important,Anything that make this marshal and unmarshal (and json processing in general) more intuitive is welcome. We're using fasterxml right now which is just fine but better is always welcome.,Somewhat important,"We do some work arounds now but it would nice if this was just ""there.""",JSF seems to do the trick 85% of the time. It would be nice to see this become more optimized and efficient. If an action-oriented frame work is as easy to use as JSF (hiding all that ugly js stuff) I'll take it!,Somewhat important,Not important,I could see a use case but most of our apps are locked into a set a runtime and configuration parameters. That being said if this made it into the standard I would surely take it for a test spin. I might not be seeing the full upside of this.,"The more the merrier. But, I think this might be one of those APIs that need to be put through its paces in some kind of proving ground before it enters the JCP or holds up JAVA EE 8. NoSQL might be hard to pin down. These databases ""seem"" to change fast and are kind of wibbly wobbly unlike a structured RDMS. Don't take that as a negative on NoSQL it's just that there is often a trade off between flexibility and predictability.",Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,Wait and see,Wait to see how well microservices is adopted in practical enterprise environments.,I'm just not sure the same could be accomplished with a few decorations in a websocket or rest for most cases. Lots of little devices talking to quick and fast interfaces on the server.,"Java EE should innovate, but only very carefully.",80/20 -- Rock Solid / New Stuff,1-2 years,,At some point even legends like Bjarne Stroustrup saw the need to let their creations out into the world via a shared and open standards organization. It would be ideal if the same happened with Java SE and Java EE under common umbrella.  This is an important technology family and its development should not be choked by a single firm or organization.
Croatia,Very important,,Important,,Not important,,Very important,,Very important,,Very important,,,Somewhat important,Very important,,,Very important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,2-3 years,,
Canada,Very important,,Very important,,Somewhat important,,Important,,Very important,,Very important,,,Important,Very important,,,Very important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
Germany,Important,,Important,,Important,,I don't think we should eliminate EJB,,Important,,Somewhat important,,,Somewhat important,Somewhat important,,,Important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,2-3 years,,
Netherlands,Very important,,Very important,,Important,,Important,I prefer only one single component framework (CDI),Very important,,Important,,Jsf is more complex than the proposed mvc. ,Very important,Not important,Because:  deltaspike,"Not now, maybe later depends on the success of OGM ",Not important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,If the APIs can support to some extent the paradigm without many compromises is a nice addition. And let's build other cdi extensions as experiments.,Wait to see how well microservices is adopted in practical enterprise environments.,Let's wait for microprofile.io and build something upon it.,"Java EE should innovate, but only very carefully.","The JCP+Oracle add more overhead than necessary. The standard could be deployed faster once there is a clear idea, sadly, once we have a specification it would take months before being shipped (remember the 9 months of Oracle laziness?)",1-2 years,"The java-ee group could ship fewer things, with proven ideas, more robust, in less time, more often (agile-ish).   I don't think is impossible many people already manage it's dependencies and knows what is shipped with spring X, or wildfly Y.Z. And this will reduce the big commitments that the umbrella java-ee spec does every release.","Unify and Optimize around CDI, that is a big win when working with java-ee."
Germany,Not important,,Important,,Important,,I don't think we should eliminate EJB,,Very important,,Important,,,Very important,Not important,,,Not important,Wait to see how well reactive is adopted in practical enterprise environments,,Java EE is already well suited to building practical microservices.,,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
Bangladesh,Very important,,Very important,,Very important,,Very important,https://developer.jboss.org/thread/259964?start=0&tstart=0  ,Very important,,Very important,,"Action oriented framework also important but  they follow spring mvc , struts2. i think you also think about GWT , Errai.",Very important,Not important,,,Very important,,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,,"1. clustering , load balance , session replication, sso capability also needed standard.",2-3 years,,"java ee7 has some limitation .  I know that you are struggling about JAVA EE . I am showing you that the progress of java ee.and spring vs JAVA EE   --------------------------------------2008----------------------------------------------------------   people say, for small project using spring is nice . EJB is complex. and big project go to ejb.          ---------------------------------------2010-------------------------------------------------------------    Spring is easy than other (EJB/cdi) .      ----------------------------------------2012------------------------------------------------------------     mid size project using spring is good , it has layered , pattern based , easy tested.       -------------------------------------------2013----------------------------------------------------------       now , Spring is very popular , it is good fit for  large scale application .               -------------------------------------2015---------------------------------------------------------------           Now , spring is widely used framework for large mission critical application and it has no any competitor .      spring is very matured than other ,            My Question is : why spring is widely used framework at 2015  ?  why not java ee popular at this moment?                     If , yes, what is gap in java ee ?   --------------------------------------------offcourse java ee has some gap--------------------------------------------------------------         ########################################################################################     Every One know that java ee is nice  but believe me that , it has no proven history.     but how many project use this java ee. it is very limited , now several people suggest that   do not use java ee , use spring instead of java ee.       i know some java slogan ------------ Its stanard , please stop this type of comments , it is very  much pain type word.   in programming word 'nothing any standard' .     IBM , Redhat, apache , they already use spring , their most of the project , they move spring .       ################################################################################################     please stop your all talking about java ee . it is very nice but it is not feasible ,      So, at least please find out GAP about JAVA EE . why people can not use java ee. ?    Then give appropriate solution , how to use java ee easily .     ##################################################################################   Objective : my objective is ,always i am  try to find out java ee gap . Why most of people can not use java ee ?                                    I am totally JAVA EE programmer and My Passion is JAVA EE , not spring . I am interested to learn performance optimization of            JAVA EE application and problem of solving of java ee related.            I want to develop a large mission critical erp model project(Open source)  using java ee. this is my idea .                                 https://developer.jboss.org/wiki/GSOC15StudentIdeas#comment-14254            http://sourceforge.net/projects/optinfraenterpirseplatform/                                  I have search people for contributing this project , but i am not found any programmer who are  interested to contribute this            project . I am pretty sure that if , i was announced this project using Spring then several programmer interested to contribute            this project .                       I am not worried for this situation . just frustrated  that why people not interested on java ee ?                       Because ,                       1. most of the company not use java ee , so programmer not interested on java ee .            2. another common problem is : JSF2 (server side ) vs Action based programming model . java ee model not support action based               web app development .So, maximum company move from java ee .                             Professional site : http://linkedin.com/    always suggest that not Use JSF2 . practically , it not perfect for large app.               http://www.coderanch.com/t/643586/JSF/java/JSF-takes-time-partial-rendering                           -- complex , large form based application JSF consume lot of bandwidth.             -- i think that i page or form contain 5 tab/50 element exits , when concurrent user hit this page JSF2 totally stuck.                       4. My last word is : actually , complex, bandwidth ,learning curve  is not real problem.               Actual problem is , java ee related maximum problem's solution has no at online. it is real fact .                                           ---------------------------------------------------------------------------------------------------------                             i am not find any java ee related skeleton project at online using java ee5/6/7.                             http://stackoverflow.com/questions/2165896/java-ee-real-world-open-source-applications                             But spring has several large project at online . it has big backbone for Open source project .                             https://www.kuali.org/download               http://www.qalingo.org/               https://mifosforge.jira.com/wiki/display/MIFOS/Architecture+Overview           http://www.broadleafcommerce.com/           http://terasolunaorg.github.io/           http://terasolunaorg.github.io/guideline/5.0.x/en/                               so, this is problem/gap of java ee.                      I want to trying to remove this problem form java ee. i want to build a semi- product architecture using java ee with           following requirements.                           https://developer.jboss.org/wiki/GSOC15StudentIdeas#comment-14254            http://sourceforge.net/projects/optinfraenterpirseplatform                                  2 years ago , i have found your presentation on online , your choose is java ee . so, I am choosing your every words of java ee.            please understand me and my analogy , why i am frustrated .  ==============================   described to you several issue  to you for  a mid size app.   lastly i got a solution for all over those issue . but one issue is it is totally propitiatory framework.  OpenMeisterEnterpirse v5 is design and app framework based on JSp and ejb.  pls find attached file .   i suggest you that you have to try   ## need to adapt ""openMeisterEnterprise5"" type similar framework  ,it is very urgent.                 "
Brazil,Very important,,Very important,,Important,,Important,,Very important,,Very important,,,Somewhat important,Very important,,,Important,Introduce significantly specialized Java EE APIs for reactive programming,,Wait to see how well microservices is adopted in practical enterprise environments.,,Java EE should not standardize ideas that are not clearly proven.,,3-4 years,,
Jordan,Important,,Important,,Important,,Somewhat important,,Somewhat important,,Important,,,Important,Somewhat important,,,Very important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,3-4 years,,
Spain,Very important,,Very important,,Very important,,Important,,Important,,Important,,,Very important,Very important,,,Somewhat important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.","Metrics and monitoring, discovery, services registries and related stuff should be first class citizen in JavaEE.  ",It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,The point is that different parts of JavaEE could have different lifecycle.  ,
Netherlands,Very important,,Very important,,Very important,,Somewhat important,,Very important,,Very important,,,Important,Very important,,,Very important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,Java EE should not standardize ideas that are not clearly proven.,,1-2 years,,
Italy,Very important,,Very important,,Important,,Not important,,Important,,Very important,,,Important,Somewhat important,,,Somewhat important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,,
Germany,Very important,Modern JEE app commonly have a web interface (e.g. JSF) and will profit from HTTP/2,Important,,Very important,,Not important,"If I could do somes tasks with CDI, I would do. But as long as EJBs will perform well, rewriting everithing is a nice to have, but not a must have.",Very important,,Somewhat important,,Let's add an improved JS and REST support into JSF.,Not important,Somewhat important,,,Important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.","Java EE may standardize features such as uber jars, metrics... We need to add a microservice profile to reduce some overhead. Or define a ""custom"" profile: Reduce an application server to a small kernel and let the developer decide which features are needed.",It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,"The IT is a very innovative sector, with a fast pace. JEE needs to support this. JAVA EE 8 needs to be standardized as early as possible (within 2016!!!). Java EE 9 shall improve from Java SE 9 and be released max. 1/2 a year after Java'9 launch. After that, it would be great to standardize mainenance releases J EE 9.x every 1-2 years to include current developments and to relaese J EE Y.0 half a year after Java SE Y.0.",
Germany,Very important,,Very important,,Very important,,Important,,Very important,,Important,,,Somewhat important,Important,,,Somewhat important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,It is OK for Java EE to standardize unproven ideas that seem promising.,,2-3 years,,
Poland,Important,,Very important,,Somewhat important,,Important,,Important,,Important,,,Somewhat important,Somewhat important,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,2-3 years,,
Germany,Important,,Very important,,Very important,,Not important,,Not important,,Somewhat important,,,Not important,Not important,,,Not important,Wait to see how well reactive is adopted in practical enterprise environments,,Java EE is already well suited to building practical microservices.,,"Java EE should innovate, but only very carefully.",,2-3 years,,
Bulgaria,Very important,,Very important,,Somewhat important,,Somewhat important,,Very important,,Very important,,,Very important,Somewhat important,,,Somewhat important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Microservices is merely hype, nothing should be done.",,Java EE should innovate in the same way that non-standard products do.,,2-3 years,,
France,Important,,Important,,Somewhat important,,Somewhat important,,Important,,Very important,,,Somewhat important,Important,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,It is OK for Java EE to standardize unproven ideas that seem promising.,,2-3 years,,
Canada,Very important,,Very important,,Very important,,Somewhat important,,Very important,,Important,,,Not important,Not important,,,Not important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Java EE is already well suited to building practical microservices.,,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,,There needs to be more emphasis on the web profile and especially JavaServer Faces I feel that the client side has been abandoned in favour of JavaScript that I feel is unfortunate. 
India,Somewhat important,No app I am developing now and near by future need HTTP/2.,Very important,Using CORE features to it's full potential will definitely help community move forward.,Important,"Most of the times, we never depend on JEE security and we have our own mechanisms, but something usable avail JEE would be very helpful.",Very important,EJB word itself confusing many and it has enough bad reputation.,Very important,"To align upto date standards of communication, it would be important to have JSON support.",Not important,People get used to many frameworks and it may not any use now. It can be simply another java.util.logging.,Definitely unsure of these.,Not important,Very important,It can make apps more dynamic and adoptable to load changes.,As NOSQL itself is not that standard... Not sure people are ready to follow the stadard made by JEE.,Very important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.","JBOSS like app servers are supporting module structure, which in some way make servers lean. Similar kind of well standard approach will help anyone build microservice with their own feature set enabled. SpringBoot looks promising but non standard.","Java EE should innovate, but only very carefully.",,1-2 years,,Make sure not to create forks. which give negative value to JEE. Definitely fork may win dev minds[influential dev teams]. But this create lot of confusion.Find ways to slowly get JavaEE get out of Oracle hands. 
Bulgaria,Very important,,Very important,,Not important,,Somewhat important,,Very important,,Important,,,Not important,Very important,,,Not important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
Brazil,Important,,Very important,,Very important,,I don't think we should eliminate EJB,,Very important,,Very important,,,Important,Important,,,Important,Wait to see how well reactive is adopted in practical enterprise environments,,Java EE is already well suited to building practical microservices.,,"Java EE should innovate, but only very carefully.",,2-3 years,,"There are lots of non standardized things that always prevent us not going on a vendor specific path. Sometimes really silly things, like, for instance, specifying timeouts for WS ports, transactions (CMT)."
Georgia,Very important,,Important,,Very important,,I don't think we should eliminate EJB,,Very important,"Json in this days? most popular , i think so..",Important,,,Not important,Important,,,Very important,Introduce significantly specialized Java EE APIs for reactive programming,,Java EE is already well suited to building practical microservices.,,"Java EE should innovate, but only very carefully.",,3-4 years,,
United States,Very important,"Critical, I would say ... ",Very important,,Very important,,Very important,,Very important,,Important,,,Very important,Very important,,,Important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Java EE is already well suited to building practical microservices.,,It is OK for Java EE to standardize unproven ideas that seem promising.,,2-3 years,,".Security, Servlets 4 and http2 will apply in cloud as well, but if security is not done and adopted correctly, all the JSR 375 work Will be wasted, which we cannot afford, at all."
India,Very important,,Very important,,Very important,,Important,,Very important,,Very important,,,Somewhat important,Important,,,Very important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,1-2 years,,
"Korea, Republic of",Very important,,Very important,,Very important,,Very important,,Somewhat important,,Somewhat important,,,Not important,Somewhat important,,,Not important,Introduce significantly specialized Java EE APIs for reactive programming,,Java EE is already well suited to building practical microservices.,,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
South Africa,Very important,,Very important,,Very important,,Somewhat important,,Very important,,Important,,,Important,Very important,,,Important,Wait to see how well reactive is adopted in practical enterprise environments,,Java EE is already well suited to building practical microservices.,,"Java EE should innovate, but only very carefully.",,2-3 years,,
Finland,Important,,Very important,,Very important,,I don't think we should eliminate EJB,,Important,,Very important,,,Not important,Somewhat important,,,Somewhat important,Introduce significantly specialized Java EE APIs for reactive programming,,"Microservices is merely hype, nothing should be done.","Microservices are excellent in some cases, but most of the enterprise systems don't really need real microservices. Combining cloud and application server in right way and we have microservices in the cloud.","Java EE should innovate, but only very carefully.",,1-2 years,,
United States,Very important,,Very important,,Very important,,I don't think we should eliminate EJB,,Very important,,Very important,,,Somewhat important,Somewhat important,,,Not important,Wait to see how well reactive is adopted in practical enterprise environments,,Java EE is already well suited to building practical microservices.,,Java EE should not standardize ideas that are not clearly proven.,,1-2 years,,
China,Very important,,Somewhat important,,Somewhat important,,Somewhat important,,Very important,,Very important,,,Very important,Somewhat important,,,Not important,Wait to see how well reactive is adopted in practical enterprise environments,,Java EE is already well suited to building practical microservices.,,Java EE should not standardize ideas that are not clearly proven.,,2-3 years,,
United Kingdom,Very important,,Very important,,Important,,Not important,,Not important,,Somewhat important,,Happy with Spring MVC :-),Somewhat important,Somewhat important,,,Not important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",Try to integrate Maven or Java 9 modules so that dependencies can be auto-installed and accessed instead of being bundled into uber-jars,"Java EE should innovate, but only very carefully.",,2-3 years,,Integrate Maven / Java 9 modules as part of application deployment
Germany,Important,,Very important,,Somewhat important,,I don't think we should eliminate EJB,,Very important,,Important,,,Very important,Important,,,Important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Java EE is already well suited to building practical microservices.,,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,,
United States,Very important,,Very important,,Very important,,Very important,,Very important,,Somewhat important,,We simply use Angular + nodejs for that layer and stick to Java for backend RESTful APIs,Not important,Somewhat important,"We use owner, works great",Our team isnt using and just havent jumped on the JPA bandwagon,Not important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
United States,Very important,,Very important,,Very important,,Very important,,Very important,,Very important,,,Not important,Very important,,,Not important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,Java EE should not standardize ideas that are not clearly proven.,,1-2 years,,
United Kingdom,Not important,,Very important,,Very important,,Somewhat important,,Very important,,Very important,,,Not important,Somewhat important,,,Not important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,1-2 years,,
United States,Very important,,Very important,,Very important,,I don't think we should eliminate EJB,,Very important,,Very important,,,Somewhat important,Important,,,Somewhat important,,,Wait to see how well microservices is adopted in practical enterprise environments.,,Java EE should not standardize ideas that are not clearly proven.,,4-5 years,,I would prefer to have singletons build into JavaEE specification that can be singletons in clustered servers
Finland,Somewhat important,,Important,,Very important,,Not important,,Important,,Somewhat important,,,Somewhat important,Important,,,Not important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,,,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,,
Croatia,Not important,,Very important,,Important,,I don't think we should eliminate EJB,,Very important,,Somewhat important,,,Somewhat important,Somewhat important,,,Somewhat important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,3-4 years,,
Sweden,Important,,Very important,,Not important,,Important,,Important,,Somewhat important,,,Not important,Not important,,,Not important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Java EE is already well suited to building practical microservices.,,"Java EE should innovate, but only very carefully.",,1-2 years,,
Czech Republic,Very important,,Somewhat important,,Important,,Somewhat important,,Somewhat important,,Very important,,,Not important,Important,,,Somewhat important,Introduce significantly specialized Java EE APIs for reactive programming,,Java EE is already well suited to building practical microservices.,,Java EE should not standardize ideas that are not clearly proven.,,1-2 years,,
,Important,,Very important,,Very important,,I don't think we should eliminate EJB,,Very important,,Very important,,,Somewhat important,Important,,,Important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,1-2 years,,
Germany,Important,,Very important,,Important,,Not important,,Somewhat important,,Important,,,Not important,Somewhat important,,,Very important,Introduce significantly specialized Java EE APIs for reactive programming,,Wait to see how well microservices is adopted in practical enterprise environments.,,Java EE should not standardize ideas that are not clearly proven.,,2-3 years,,
United Kingdom,Very important,,Very important,,Somewhat important,,Somewhat important,,Somewhat important,,Somewhat important,,,Somewhat important,Somewhat important,,,Not important,Wait to see how well reactive is adopted in practical enterprise environments,,Java EE is already well suited to building practical microservices.,,"Java EE should innovate, but only very carefully.",,3-4 years,,
Europe,Important,,Very important,,Very important,,Somewhat important,,Very important,,Very important,,"Web Frameworks are evolving too fast and Java EE 8 too slow. A MVC-framework should not be part of Java EE 8 if it is blocking and slowing down Java EE releases. Additionally I have the impression that the new MVC framework, as it is being developped now, would not be used by enough people. A Java EE 8 web framework would be great and is important, but at this point I have little belief in it.",Not important,Important,,,Very important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,1-2 years,,Why was the Java EE Certification from Oracle certification was never updated to Java EE 7. Will it be updated for Java EE 8? How do people value it's importance?  The certification allowed me study and get recognized for my Java EE knowledge so it did have value for me.
Australia,Important,,Very important,It is clearly a problem if we can't use the base language features safely.,Very important,,Somewhat important,This can wait,Very important,"""JSON has replaced XML as the de-facto data interchange format"". Exactly. Would be good to make it easy to plug in other serialization formats like Protobuffers, Thrift, etc.",Very important,,"Not sure how (maybe on top of Nashorn) or if it should be part of the MVC standard, but we need a (performant) way to reconcile client-side and server-side rendering otherwise Node.js will always have an advantage there",Somewhat important,Important,"This might help JPA multi tenancy, which is a big missing piece in JPA (but probably can be done in JPA specifically)",Probably this can still wait a bit to see if there is some convergence,Somewhat important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Wait to see how well microservices is adopted in practical enterprise environments.,Can wait a bit to see what gets proven/adopted but it would be nice to start standardizing as much as possible,"Java EE should innovate, but only very carefully.",,1-2 years,"It is important to keep a good pace, otherwise Java EE might get too far behind de-facto standards. Not every ""release"" needs to be a major one and add completely new, feature complete stuff","Java lost the client side battle. I think long term it is important to reconcile server and client side rendering somehow, otherwise as Javascript in the Server improves it might get less and less interesting to use Java there too"
Netherlands,Very important,The performance benefits from HTTP/2 are such that there is not question that we need to support this .,Very important,when JSE and JEE are being used in conjunction it is simply madness that lambdas and streams cannot be used/returned by JEE classes. This has to be aligned. First priority in my opinion.,Important,"Hard to choose how important I feel this is. Don't this it is that important. But then again, the current security model has hardly changed since EJB 2.x and such an overhaul is overdue.",Somewhat important,"Having two component models is both luxury and confusing at the same time. Yet, it has not stopped  me from using these interchangably. And it hurts a bit to see EJBs disappear altogether (though I guess it is inevitably). So while, important, it does not deliver new functionalitity and as such I only consider it somewhat important.",Somewhat important,"As you say, JSON is the standard. JSON-B would be nice both for the developers and tool vendors. Don't let Java fall behind in this area too.",Important,"Every modern application, and even a few not so modern ones, support caching. So it is time that there will a JEE standard available","Let's face it. JS, HTML5 and Rest can do the job these frameworks want to do. And why build something that is available as Spring MVC for years.  If we have to prioritize and choose, then this one should be dropped for sure",Not important,Somewhat important,"Nice feature, but in the environments I come across this is not as important as functionality. With the rise of microservices, re-configuration and restarting services is not so much an issue.","This is very interesting and growing area. Right now, if I wanna use MongoDB for example, I have a choice of writing my own code (like we did in the pre-hibernate/JPA days for RDBM systems) or use something like Spring-Data. A standard would be nice for delivering it for JEE8 seems not the way to go. It will either be contain too few features to be able to impress the community as being an alternative or it will delay JEE8. This is something that could be addressed for JEE8.1. In Oracles new philosophy not all needs to  delivered at once.",Important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,We have seen some reactive ideas sip in via the Concurrent package and I believe the majority of EE developers is still unfamiliar with all the posibilities. Sessions I've attended with e.g. Adam Bien prove this to me. So an ad-hoc adaptation should suit us just fine. But more increments than only  every 3-4 years then please.,Java EE is already well suited to building practical microservices.,"Adaption will take place. We just should tell developers/architectsn (or maybe just management) that we're not all Netflix and we have different demands for webservices. Right now with the current tooling (outside of JEE) we can manag this juist fine. I do not think a sensible standard will evolve any time soon. Also, the infrastructure is extended with container managers like Kubernetes and docker swarm. This is hard to include into a standard. Lets use what we have and see where this microservices wave is riding us.","Java EE should innovate, but only very carefully.",,1-2 years,"When we have more frequent releases, when do not have to do everything at once and i would allow to think better about technologies (see my nosql comments). And it allows us not to jump to every trend immediately but to still adopt those things that have emerged from the trends as a more proven solution.",
France,Very important,,Important,,Somewhat important,Security is important but be part of JavaEE is not my priority because I can manage it outside,Important,,Somewhat important,Jackson is here,,,,Somewhat important,Very important,guys we are in 2016 wake-up,,Important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Java EE is already well suited to building practical microservices.,Need choice: Java EE is NOT well suited to building practical microservices but does we really need standard for something that should be domain specific?,It is OK for Java EE to standardize unproven ideas that seem promising.,,2-3 years,,
United States,Very important,,Very important,,Somewhat important,We have worked around the problem but an easier spec would probably reduce the vulnerabilities born of our mistakes ;-),Not important,,Important,Other libraries fill most of the gaps but the absence of this feature is used to sight that Java EE isn't suitable for new projects.,Important,We already use JCache,The world of MVC JS frameworks moves far faster than J-EE and so I worry that anything added for the current wave will just be baggage in a couple of years.,Not important,Not important,Increases complexity and seems likely to lead to rarely seen bugs as live reconfiguration will be rare.,The world of NoSQL is large and divergent. A single API is unlikely to be appropriate. ,Not important,Wait to see how well reactive is adopted in practical enterprise environments,J-EE has enough features to implement a Reactive style. Libraries that offer a more unified view over the top of J-EE are a better option for now.,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",Circuit breakers and bulkheads are not Microservies specifically and are sadly missing at the moment.,It is OK for Java EE to standardize unproven ideas that seem promising.,Clear separation of the more innovative areas such that they can be easily ignored if they don't work out is important. Entity Beans were put at the heart of the EJB 2 spec and so have been hard to back away from.,1-2 years,,
Brazil,Very important,"It is also very important to support multimedia applications, and maybe, also IoT.",Somewhat important,"IMHO, lambda is already, in someway, supported (depends on the JDK version container supports), some features are important (e.g.  new date time & streams), and another ones should be supported in a different way or are less important (e.g. fork/join).",Very important,"Thinking about modularity, container embbeding (fat jars), microservices, cloud scaling and distribution, CI/CD, it is very important to distributed, set and plug other frameworks (e.g. style OAuth 2, OpenID, etc) these configurations with the application without the need of GUI.",Somewhat important,"It's good to have (the elimination). But, is better to have first support to any missing features, if any.",Important,"Mainly, but not only, because of JAX-RS support.",Somewhat important,,"I feel that JSF is not enough if application has some complexity, because, easy things are too easy to develop using JSF. But, when some complexity appears it becomes more hard then using other lower level frameworks, like action-orientend ones. ",Very important,Very important,"I think it's important to enable microservice architecture style (e.g. dynamic service discovery, client side load-balance, etc).","Because, ""may ... be very difficult to arrive at a standard data access API"". ",Not important,Introduce significantly specialized Java EE APIs for reactive programming, See versiong comments for more.,Java EE is already well suited to building practical microservices.,"I don't really agree with the idea that ""Java EE is already well suited"". It is a lot tricky to enabled ""custom configured, self-contained executable jars, metrics, discovery, circuit breakers and bulkheads"". But, I agree with Martin Fowler that microservices is not already proven and also that is not required for many applications until it grows. But, if JEE doesn't not supports it, Java will to loose more and more developers. See versiong comments for more.",It is OK for Java EE to standardize unproven ideas that seem promising., See versiong comments for more.,1-2 years,"It's great if releases were done more frequently. For example, if JEE 8.0.0 has only new CDI, and Servlet, than, JEE 8.1.0 new MVC, JEE 8.1.3 patch (maybe), ..., JEE 9.0.0 new/change concepts introduced, and so on. So, following these ideias (of course the is a really high level thought) would be possible to innovate, try new frameworks/concepts (careful innovation) and have new features faster.", 
Germany,Very important,,Very important,,Important,,Not important,,Very important,,Somewhat important,,,Somewhat important,Not important,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,1-2 years,,
Mexico,Very important,,Very important,,Very important,,I don't think we should eliminate EJB,,Very important,,Important,,,Somewhat important,Important,,,Very important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,It is OK for Java EE to standardize unproven ideas that seem promising.,,3-4 years,,Update the certifications according these updates.
Netherlands,Somewhat important,Usually have Apache in front of it but Naked EE service would be nice.,Very important,Coming from a .NET background the verbosity of Java EE 7 seems silly. Lightens with Akka etc might be an interesting more succinct alternative.,Very important,The above sample is Strongly typed. Please provide a strong typed DSL.,Very important,Less stuff to support and maintain. Smaller attack surface. Easier to learn. As a Java EE noobmynoof and .NET teacher I am aware that it is very easy to start with old complex outdated stuff from blog posts from years ago. Please eliminate the legacy.,Very important,,Important,,"As a long time developer coach I have seen junior developers use ASP.NET webforms( the .NET equivalent of JSF) as if  they where doing desktop programming. Ofcourse such software breaks in reality. Real MVC based frameworks do not give the illusion of desktop programming. However with REST based services and single page webapps, the need for MVC based sites may limited.",Somewhat important,Important,Not expert enough but as this means injecting different components based on user input/data yes please.,,Somewhat important,Introduce significantly specialized Java EE APIs for reactive programming,Look at RX and Akka. Learn and integrate.,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.","Please start with evolving Java SE faster by learning from C#, Scala, F#, Javascript,Kotlin etc. Plain Java's verbosity is silly.",1-2 years,"I left the Java world completely in 2005. I came back in December 2015. What was new: Decorators, Lambda and AOP with decorators in Java EE. From a .NET point of view Java(EE) is stone age technology.",Standardized symantic logging like the symantic logging application block in Microsoft Enterprise Library. That is logging domain special objects instead of strings
Germany,Very important,Some AS already support that but enabling that and using it is a pain in the ass. Luckily the end-user will not notice the difference besides the faster response. ,Very important,,Somewhat important,,Important,"It is important to have a common language. Since JSF Managed Beans are already somewhat deprecated, why not use CDI whenever possible. In the end the old EJB annotations can be used to reflect similar properties with CDI.  Though it is important not to overload the CDI spec. Sometimes it will hinder the seperation of concern for the developers. ",Very important,"A lot of APIs are using JSON, be it end to end or service to service communication. ",Somewhat important,,"If you are doing business applications JSF is fine, but for mobile first applications you always had to use REST Endpoints and communicate with another framework to get your job done.   If something like MVC can elevate that problem, that would be great.",Very important,Somewhat important,"Nowadays using Docker there is rarely a case, where you can not spin up a second server and re-direct the communication to the new configured AS.  This is great though for coorperates where more than 1 server is not required.",Researching for a common API is wanted. Not sure if this is possible though.,Very important,Wait to see how well reactive is adopted in practical enterprise environments,,Java EE is already well suited to building practical microservices.,,It is OK for Java EE to standardize unproven ideas that seem promising.,"The problem that the majority is not playing with the unstandardized APIs until it is released. It is clear that they also want to help keeping the API as backwards compatible as possible, but only after the usage people will detect flaws in some use-cases.  Fixing those problems is taking way too long ",1-2 years,"I would not mind waiting longer for a bigger feature. But there is no reason to include like 50 new features in a release and thus wait 5 years for the new version.   If for example JCache is an accepted standard, why not just include that and call it JavaEE 8 for example.  It also depends on the AS vendors. If it takes too long for the AS vendors to implement the implementations, then there is no meaning in releasing the API if the developers can not use the API for multiple month or years.  I think the AS vendors would also appreciate smaller implementations steps, so they can adept more flexible",
United States,Important,,Very important,,Somewhat important,"There are many possible identity providers (DB/LDAP/SAML....), and then there are multiple authorization concepts (direct, role-based,...) so might be hard to generalize here.",Somewhat important,,Very important,,Important,,,Very important,Somewhat important,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,"Especially wait for standards for, e.g. discovery.",It is OK for Java EE to standardize unproven ideas that seem promising.,,2-3 years,,
United States,Very important,This fundamental as the rest of the infrastructure of the internet is switching over to this.   It would critical to have good support for it in the JEE platform.,Very important,,Very important,,I don't think we should eliminate EJB,I think I would need more information on this to understand the impact.   I've worked with EJBs for a long time and less so with CDI.   If the all the functionality of EJB (I'm assuming Session and Message Beans and not Entity Beans) could be unified under CDI than that would change my response.,Important,It would be nice to have a standard. Especially with how heavily JSON is used.  ,Important,"It would be nice to have a standard. However, the current spec seemed a little too restrictive especially on creating/configuring of the cache.   I had to fall back to ehcache for my simple use-case.","I've been using Stripes for the past 8 years which works good.  However, MVC support part of the platform would great as an augment to JAX-RS.  Which from what I've seen of the spec this looks pretty good.",Very important,Important,It would be nice for long running systems where restarts are too disruptive.,"It would be nice to have standard APIs for different types of DBs.  Time Series, Document, Graph, Key-value, etc.   Perhaps, to persistence API can have different pieces to it rather than trying to fit it all in one model.  IE. JPA for relational,  X for document.",Important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,"There should be some support but, I think may be good to wait JEE 9 to decide if needs a specialized API.",Java EE is already well suited to building practical microservices.,"I agree with Adam Bien.  Supposedly, ""light weight"" solution tend to become heavy over time.  I think it great to have options so having Swarm, Paraya Micro versions is a good thing.    JEE could benefit from some standard for metrics, discovery, circuit breakers and bulkheads.  That could be helpful for other use-cases.   ","Java EE should innovate, but only very carefully.",The danger of high innovation is once you add the API it needs to be supported for a long time and that may make it hard innovate in the future.  JEE has primarily valued stability.,2-3 years,1-2  would make sense if the changes are small.  2-3 tends make more sense because it takes awhile for the app servers to catch up and for old projects to update.   I think it's important for ecosystem to have non-standard alternates for immediate needs then standardizing in time to reduce dependency lock in.,JAX-RS should be updated to have a standard upload file support rather than having to use something implementation specific.
Nigeria,Very important,,Very important,,Very important,,Somewhat important,,Very important,,Very important,,,Very important,Somewhat important,,,Very important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,,
Slovakia,Very important,,Important,Streams not being safe is an overstatement - just parallel streams are.   Also let's not forget Optional. ,Important,"But must be much more capable add this example, which just promotes storing plaintext passwords. ",I don't think we should eliminate EJB,,Somewhat important,,Somewhat important,,,Not important,Somewhat important,,We rather need better support for integrating async result delivery from the drivers into the container as well as handling timeouts and retries. ,Not important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",Über jars are IMO not important; the rest should be more easy to achieve than it is now. E.g. Implementing retry in case of optimistic lock  exception for EJB is almost impossible. ,Java EE should not standardize ideas that are not clearly proven.,Standards are hard to change. ,2-3 years,,
United States,Very important,,Important,,Somewhat important,,Important,,Somewhat important,,Somewhat important,,,Not important,Very important,,,Very important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,2-3 years,,
Hungary,Important,,Very important,,Very important,,Somewhat important,,Important,,Somewhat important,,,Not important,Not important,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,2-3 years,,
Czech Republic,Very important,,Important,,Important,,Somewhat important,,Important,,Important,,,Somewhat important,Somewhat important,,,Somewhat important,Introduce significantly specialized Java EE APIs for reactive programming,,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,2-3 years,,
Czech Republic,Very important,,Somewhat important,,Somewhat important,,Not important,,Important,,Somewhat important,,,Somewhat important,Somewhat important,,,Not important,Introduce significantly specialized Java EE APIs for reactive programming,,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,2-3 years,,
Germany,Very important,,Very important,,Important,,Very important,,Very important,,Important,,,Very important,Important,,,Very important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,,
India,Very important,,Important,,Very important,,Somewhat important,,Very important,,Very important,,,Important,Very important,,,Very important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,1-2 years,,
Spain,Very important,,Very important,,Important,,Very important,,Very important,,Important,,,Somewhat important,Very important,,,Very important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
Belgium,Important,,Very important,,Very important,,Not important,,Important,,Somewhat important,,,Somewhat important,Somewhat important,,,Important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Java EE is already well suited to building practical microservices.,,Java EE should not standardize ideas that are not clearly proven.,"Since it is a standard and many players are working hard to implement it, including unproven things that will later on be deprected and removed, is a waste of time multiplied by the number of players.  However it should be designed in a way that allows me to choose the innovations I want to include in my application through standard integration/extension points.",3-4 years,3 years.,
Brazil,Very important,,Very important,,Important,,Somewhat important,,Very important,,Important,,,Not important,Not important,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,3-4 years,,
Switzerland,Important,,Very important,,Very important,,Important,,Very important,,Important,,,Somewhat important,Very important,,,Very important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,1-2 years,,
Brazil,Important,,Very important,,Very important,,Very important,,Very important,,Important,,,Very important,Very important,,,Very important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,3-4 years,,
Thailand,Very important,,Important,,Somewhat important,,Important,,Important,,Important,,,Not important,Somewhat important,,,Somewhat important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should not standardize ideas that are not clearly proven.,,1-2 years,,-
,Very important,,Very important,,Not important,,Not important,,Very important,,Important,,,Somewhat important,Somewhat important,,,Very important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,2-3 years,,
Germany,Important,,Very important,,Very important,,Not important,,Important,,Important,,,Important,Important,,,Important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Java EE is already well suited to building practical microservices.,,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
France,Important,,Very important,,Somewhat important,,I don't think we should eliminate EJB,,Very important,,Very important,,,Not important,Important,,,Important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should not standardize ideas that are not clearly proven.,,2-3 years,,
Germany,Very important,,Very important,,Important,,Very important,,Very important,,Important,,,Somewhat important,Important,,,Very important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
France,Somewhat important,,Very important,,Important,,Important,,Somewhat important,,Very important,,,Very important,Important,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,2-3 years,,
United States,Very important,,Very important,,Not important,,Very important,,Not important,,Not important,,,Not important,Not important,,,Not important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
Egypt,Important,,Very important,,,,I don't think we should eliminate EJB,,Very important,,Important,,,Very important,Very important,,,Very important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
Brazil,Very important,,Very important,,Very important,,Important,,Very important,,Very important,,,Very important,Very important,,,Very important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,1-2 years,,
Italy,Important,,Very important,,Very important,,Very important,,Important,,Important,,,Important,Somewhat important,,,Somewhat important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Wait to see how well microservices is adopted in practical enterprise environments.,,Java EE should innovate in the same way that non-standard products do.,,3-4 years,,
Thailand,Very important,,Very important,,Very important,,I don't think we should eliminate EJB,,Very important,,Important,,,Important,Important,,,Important,Introduce significantly specialized Java EE APIs for reactive programming,,Java EE is already well suited to building practical microservices.,,"Java EE should innovate, but only very carefully.",,1-2 years,,
Brazil,Very important,,Important,,Very important,,Very important,,Very important,,Important,,"Alongside the reduction of verbosity, this is a key point if we want Java to be integrated with the consolidated standards in web development. At my point of view, frameworks like JSF (and its intrincate lifecycle) tend to be replaced by other options that are easier to engage and more flexible in sense of custom UI solutions (like springMVC or Asp.NET MVC).",Very important,Important,,,Not important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Wait to see how well microservices is adopted in practical enterprise environments.,,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
India,Very important,,Very important,,Very important,,Not important,,Not important,,Not important,,,Not important,Important,,,Very important,Wait to see how well reactive is adopted in practical enterprise environments,,Java EE is already well suited to building practical microservices.,,"Java EE should innovate, but only very carefully.",,1-2 years,,
Saudi Arabia,Very important,,Very important,,Not important,,Important,,Very important,,Not important,,,Very important,Not important,,,Not important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
Finland,Very important,,Very important,,Somewhat important,,Important,,Not important,,Somewhat important,,,Not important,Important,,,Not important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,2-3 years,,
India,Very important,,Very important,,Important,,Not important,,Very important,,Important,,,Important,Important,,,Very important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,Need to take the momentum back in-order to beat the competition
Spain,Very important,,Important,,Somewhat important,,Important,,Important,,Somewhat important,,,Important,Very important,,,Important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,It is OK for Java EE to standardize unproven ideas that seem promising.,,2-3 years,,
Czech Republic,Somewhat important,All APIs we write are fast enough without HTTP/2,Very important,,Important,,Not important,,Important,,Not important,,Do you need to build another Spring?,Somewhat important,Somewhat important,,,Very important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Java EE is already well suited to building practical microservices.,,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
Poland,Very important,,Very important,,Very important,,Not important,,Very important,,Somewhat important,,,Not important,Very important,,,Somewhat important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
Spain,Important,,Important,,Somewhat important,,I don't think we should eliminate EJB,,Important,,Very important,,,Very important,Very important,,,Somewhat important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,,
Russian Federation,Very important,,,,,,Important,,,,,,,,,,,Very important,,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,,,1-2 years,,
India,Important,,Very important,,Somewhat important,,Somewhat important,,Very important,,Important,,,Important,Somewhat important,,,Not important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,Java EE should innovate in the same way that non-standard products do.,,2-3 years,,
Sweden,Important,,Very important,,Important,,Very important,,Very important,,Somewhat important,,,Very important,Somewhat important,,,Important,"Reactive is merely hype, nothing should be done",,Java EE is already well suited to building practical microservices.,,"Java EE should innovate, but only very carefully.",,2-3 years,,
Ukraine,Important,,Important,,Very important,,Very important,,Very important,,Important,,,Important,Important,,,Important,Introduce significantly specialized Java EE APIs for reactive programming,,Wait to see how well microservices is adopted in practical enterprise environments.,,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,,
India,Very important,,Very important,,Very important,,Somewhat important,,Important,,Important,,,Important,Important,,,Important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,3-4 years,,"Don't change the basic flavour of Java. Lambda expressions okay, remove default  method implementations in Interfaces."
Turkey,Very important,,Very important,,Important,,Very important,,Very important,,Somewhat important,,,Important,Important,,,Important,Introduce significantly specialized Java EE APIs for reactive programming,,Wait to see how well microservices is adopted in practical enterprise environments.,,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,,
Saudi Arabia,Important,,Not important,,Important,,Not important,,Important,,Important,,,Very important,Not important,,,Important,,,,,"Java EE should innovate, but only very carefully.",,1-2 years,,
Turkey,Very important,,Very important,,Somewhat important,,Very important,,Not important,,Somewhat important,,,Not important,Very important,,,Very important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,3-4 years,,
Turkey,Somewhat important,,Very important,,Very important,"Essential, deal breaker",Very important,,Very important,,Important,,,Very important,Somewhat important,,,Somewhat important,"Reactive is merely hype, nothing should be done",,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,2-3 years,,
Bulgaria,Very important,,Not important,,Not important,,Very important,,Very important,,Somewhat important,,,Not important,Not important,,,Not important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,,
Turkey,Important,,Very important,,Not important,,Not important,,Important,,Very important,,,Not important,Important,,,Not important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Java EE is already well suited to building practical microservices.,,It is OK for Java EE to standardize unproven ideas that seem promising.,,3-4 years,,
Argentina,Important,,Not important,,Important,,Very important,,Very important,,Very important,,,Important,Somewhat important,,,Very important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,,
Brazil,Important,,Very important,,Very important,,Somewhat important,,Very important,,Very important,,,Not important,Important,,,Important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,2-3 years,,
Canada,Very important,,Very important,,Important,,Not important,Unsure,Very important,,Somewhat important,,,Important,Not important,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,Java EE should not standardize ideas that are not clearly proven.,,2-3 years,A release could be just minor improvements. ,Will each jsr become a module?
Argentina,Important,,Very important,,Very important,,Very important,,Not important,,Somewhat important,,,Not important,Important,,,Somewhat important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
United States,Very important,,Very important,,Important,,Somewhat important,,Very important,,Somewhat important,,,Somewhat important,Important,,,Not important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,1-2 years,,
Spain,Very important,,Somewhat important,,Very important,,Somewhat important,,Very important,,Not important,,,Not important,Important,,,Important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,1-2 years,,
Sweden,Somewhat important,,Very important,,Important,,Important,,Very important,,Very important,,,Very important,Important,,,Important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,2-3 years,,
Brazil,Important,,Somewhat important,backwards compatibility are the million dollar question here,Very important,,I don't think we should eliminate EJB,,Somewhat important,,Important,,,Not important,Very important,,,Not important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,2-3 years,,"someone tell's oracle that ""reboot"" is a very silly term to use.   ""enhance"", ""extend"", whatever could do less damage than ""reboot"".  no one ""reboots"" ten years of investment.  oracle, pay more attention to java/jee than stupid judicial madness about android.  the java ecosystem can make you last forever or can make you sink in a unrepairable manner."
Bulgaria,Very important,,Very important,,Somewhat important,,Important,,Very important,,Very important,,,Very important,Important,,,Very important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,It is OK for Java EE to standardize unproven ideas that seem promising.,,2-3 years,,
Sweden,Somewhat important,,Very important,,Not important,,Very important,,Important,As important is to drive the change from Json to something halfway decent.,Somewhat important,,,Somewhat important,Not important,,,Somewhat important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.","Microservices are hype, but can not be neglected.   The main driver is actually to get more control of deployment and of configuration for the developers. Java should provide mechanisms for that, which would be helpful regardless of microservices survives.",Java EE should innovate in the same way that non-standard products do.,,1-2 years,,"The main competition on the backend seems to be node.js. It is crap in every conceivable way, except that it is very lightweight to work with.   Java "
Spain,Important,,Very important,,Very important,,Very important,,Very important,,Very important,,,Important,Important,,,Important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
Bangladesh,Very important,,Very important,,Very important,,,,Very important,,Very important,,,Very important,Very important,,,Very important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
Sweden,Important,,Very important,,Important,,Somewhat important,,Important,,Somewhat important,,,Not important,Somewhat important,,,Not important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Wait to see how well microservices is adopted in practical enterprise environments.,,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,,
Italy,Important,,Important,,Very important,,Important,,Somewhat important,,Very important,,,Important,Important,,,Somewhat important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,3-4 years,,
France,Very important,,Very important,,Very important,,Important,,Very important,,Important,,,Somewhat important,Important,,,Important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Wait to see how well microservices is adopted in practical enterprise environments.,,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
Czech Republic,Very important,,Important,,Very important,,Somewhat important,,Not important,,Important,,,Not important,Somewhat important,,,Somewhat important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
India,Important,,Very important,,Important,,Important,,Very important,,Very important,,,Somewhat important,Very important,,,Very important,Introduce significantly specialized Java EE APIs for reactive programming,,Java EE is already well suited to building practical microservices.,,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,,
Czech Republic,Very important,,Important,,Very important,,Somewhat important,,Very important,,Somewhat important,,,Somewhat important,Somewhat important,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,Java EE is already well suited to building practical microservices.,,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,,
Turkey,Very important,,Very important,,Somewhat important,,Not important,,Very important,,Important,,,Important,Very important,,,Important,Introduce significantly specialized Java EE APIs for reactive programming,,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,1-2 years,,
India,Important,"As claimed to be making the web faster and improve performance, this is definitely important.",Somewhat important,This is needed in the long run. But I believe first aim should be to make sure more and more developers are using Java-8 features. Java community first take steps to encourage java 8 feature use among developers/companies.,Important,,Important,EJB is losing relevance in today's world. There is no use continuing with it. I guess everything can be achieved using CDI frameworks.,Very important,"As a light weight data interchange format, JSON support is very important.",Important,"With a container built in second level caching mechanism, developing distributed applications will become much easier.",I believe currently there are enough MVC frameworks that can cater to the needs of Web fraternity.,Not important,Somewhat important,,"Since NoSQL is gaining usage and popularity, it will be good to have JPA API's for accessing NoSQL DBs.",Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,4-5 years,,
Spain,Very important,,Very important,,Somewhat important,,Important,,Very important,,Somewhat important,,,Somewhat important,Very important,,,Important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,,
Ukraine,Important,,Very important,,Somewhat important,,Very important,,Very important,,Somewhat important,,,Very important,Important,,,Important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,It is OK for Java EE to standardize unproven ideas that seem promising.,,2-3 years,,
India,Very important,,Important,,Very important,,Somewhat important,,Important,,Important,,,Important,Important,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,"Microservices is merely hype, nothing should be done.",,Java EE should not standardize ideas that are not clearly proven.,,1-2 years,,
Portugal,Very important,,Not important,,Very important,,Important,,Very important,,,,,,Important,,,Important,Wait to see how well reactive is adopted in practical enterprise environments,,,,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
Sri Lanka,Very important,,Very important,,Very important,,Important,,Very important,,Very important,,,Somewhat important,Very important,,,Important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,,
Ecuador,Very important,,Important,,Very important,,Very important,,Very important,,Very important,,,Important,Important,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,It is OK for Java EE to standardize unproven ideas that seem promising.,"This will keep community strong, as long as they feel supported in new technologies",1-2 years,,
Hungary,Somewhat important,,Very important,IMHO Java EE should align to the SE version to have the freedom to interchange codeparts (ie. copy-paste-try from StackOverflow). ,Important,,Important,"EJB and CDI can live together although I'd prefer a sooner ""death"" of EJB because they can cause headaches sometimes.",Somewhat important,,Important,Would be nice to have standard caching.,,Somewhat important,Important,,,Important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,It is OK for Java EE to standardize unproven ideas that seem promising.,,2-3 years,,
United Kingdom,Very important,Its already late,Very important,,Not important,,Somewhat important,,Very important,,Very important,,,Somewhat important,Not important,,,Important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
Denmark,Somewhat important,,Very important,,Very important,,Important,,Important,,Very important,,,Very important,Somewhat important,,,Not important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,"Vendors could cooperate on base functionality ... On a proven ""core"" so to speak. Or sets of ""cores""."
Sweden,Very important,,Very important,,Very important,,Very important,,Very important,,Not important,,,Important,Very important,,,Not important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Java EE is already well suited to building practical microservices.,,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
Romania,Very important,,Very important,,Important,,Not important,,Important,,Very important,,,Very important,Very important,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,Java EE should not standardize ideas that are not clearly proven.,,2-3 years,,
Spain,Very important,,Important,,Very important,,Important,,Very important,,Very important,,,Very important,Very important,,,Important,Wait to see how well reactive is adopted in practical enterprise environments,,Java EE is already well suited to building practical microservices.,,"Java EE should innovate, but only very carefully.",,2-3 years,,
Netherlands,Very important,,Important,,Somewhat important,,Important,,Important,,Very important,,,Very important,Very important,,,Not important,"Reactive is merely hype, nothing should be done",,Wait to see how well microservices is adopted in practical enterprise environments.,,It is OK for Java EE to standardize unproven ideas that seem promising.,,2-3 years,,
Spain,Very important,,Very important,,Important,,Somewhat important,,Important,,Not important,,,Not important,Not important,,,Somewhat important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Java EE is already well suited to building practical microservices.,,Java EE should not standardize ideas that are not clearly proven.,,3-4 years,,
Russian Federation,Important,,Somewhat important,,Not important,,Somewhat important,,Somewhat important,,Not important,,,Not important,Important,,,Not important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,,,,,
Sweden,Very important,,Very important,,Important,,Not important,,Somewhat important,,Important,,,Not important,Very important,,,Important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
Colombia,Very important,,Important,,Somewhat important,,Very important,,Important,,Very important,,,Not important,Important,,,Somewhat important,Introduce significantly specialized Java EE APIs for reactive programming,,Wait to see how well microservices is adopted in practical enterprise environments.,,Java EE should innovate in the same way that non-standard products do.,,3-4 years,,Unit and integration test improvements and model promotion.  Log and monitoring improvements for large scale apps.  Faster and light app servers like. Net  
Nigeria,Very important,,Very important,,Very important,,Somewhat important,,Important,,Important,,,Important,Very important,,,Important,Wait to see how well reactive is adopted in practical enterprise environments,,Java EE is already well suited to building practical microservices.,,Java EE should innovate in the same way that non-standard products do.,,2-3 years,,
United States,Very important,,Very important,,Very important,,Not important,,Important,,Important,,,Not important,Somewhat important,,,Somewhat important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Java EE is already well suited to building practical microservices.,,"Java EE should innovate, but only very carefully.",,1-2 years,,
United Kingdom,Very important,,Important,,Somewhat important,,Important,,Very important,,Somewhat important,,,Not important,Very important,,,Not important,Wait to see how well reactive is adopted in practical enterprise environments,,Java EE is already well suited to building practical microservices.,,"Java EE should innovate, but only very carefully.",,1-2 years,,
Germany,Very important,,Very important,,Very important,,Very important,,Very important,,,,,Very important,Very important,,,Very important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
Belgium,Very important,,Important,,Important,,Somewhat important,,Important,,Somewhat important,,,Not important,Very important,,,Important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,1-2 years,,
South Africa,Somewhat important,,Important,,Very important,Should also like this to be a configuration on the app server without having to recompile code or repackaging of artifacts ,Somewhat important,I think EJB form a nice layer for separating of concerns  ,Very important,,Very important,We've been waiting for a very long time for this,,Very important,Very important,Changing config of a server without having to restart is vital,,Very important,Wait to see how well reactive is adopted in practical enterprise environments,,Java EE is already well suited to building practical microservices.,,"Java EE should innovate, but only very carefully.",,4-5 years,I think 5 years if a good period for a full adoption from most stubborn large corporations,
Spain,Very important,,Somewhat important,,Important,,Important,,Very important,,Somewhat important,,,Somewhat important,Important,,,Very important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,2-3 years,,
Argentina,Somewhat important,,Somewhat important,,Somewhat important,,Important,,Very important,,Important,,,Very important,Important,,,Somewhat important,"Reactive is merely hype, nothing should be done",,"Microservices is merely hype, nothing should be done.",,It is OK for Java EE to standardize unproven ideas that seem promising.,,3-4 years,,
Greece,Important,,Very important,,Important,,Very important,,Very important,,Very important,,,Very important,Important,,,Somewhat important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,Or even more frequent. ,"JDBC standard looks very static. It could be enhanced and improved (also with functional style API), for applications that do not need an ORM. "
Croatia,Very important,,Important,,Somewhat important,,Not important,,Important,,Somewhat important,,,Somewhat important,Important,,,Important,Introduce significantly specialized Java EE APIs for reactive programming,,Java EE is already well suited to building practical microservices.,,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
South Africa,Very important,,Very important,,Somewhat important,,I don't think we should eliminate EJB,,Important,,Very important,,,Very important,Important,,,Very important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Java EE is already well suited to building practical microservices.,,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,,
Montenegro,Important,,Somewhat important,,Somewhat important,,Not important,,Very important,,Very important,,,Very important,Somewhat important,,,Important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Java EE is already well suited to building practical microservices.,,Java EE should not standardize ideas that are not clearly proven.,,1-2 years,,
United Kingdom,Very important,,Important,,Very important,,I don't think we should eliminate EJB,,Somewhat important,,Important,,,Important,Somewhat important,,,Not important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,3-4 years,,
Germany,Very important,,Very important,,Important,,Important,,Important,,Important,,,Somewhat important,Somewhat important,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,Java EE should not standardize ideas that are not clearly proven.,,2-3 years,,
Germany,Very important,Maybe by using OkHttp ,Very important,,Important,,I don't think we should eliminate EJB,,Very important,,Important,,,Somewhat important,Somewhat important,,,Important,"Reactive is merely hype, nothing should be done",,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,2-3 years,,
Spain,Somewhat important,,Very important,,Very important,,Important,,Very important,,Somewhat important,,,Important,Somewhat important,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,,,,,
Germany,Very important,,Very important,,Very important,,Somewhat important,,Very important,,Very important,,,Somewhat important,Somewhat important,,,Very important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
Austria,Very important,,Somewhat important,,Important,,I don't think we should eliminate EJB,,Somewhat important,,Somewhat important,,,Important,Somewhat important,,,Important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Java EE is already well suited to building practical microservices.,,"Java EE should innovate, but only very carefully.",,3-4 years,,
Netherlands,Important,,Very important,,Very important,,Very important,"EJB does not necessarily need to be eliminated, but I'll embrace every effort to reduce the number of containers in JEE. That is still the major benefit of Spring over EE, it has only one containers, whereas EE suffers from needless complexity with separate containers fot EJB, CDI, Servlet, JSF. ",Important,,Important,,"The MVC spec should have been there 10 years ago. Component based MVC like JSF tempts to hide complexity behind an abstraction, but these are mostly leaky abstraction. However, I think server side MVC is dead. Client side MVC is even more clean and is here to stay. Rather invest in JAX-RS in order to embrace this. Better Hypermedia support please! ",Not important,Very important,,"Maybe a high level persistence API will do the trick, but I think the topic is just too broad to come to a workable solution. ",Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,2-3 years,More important is the adoption speed among implementers. Both JEE 6 and 7 took ages to be adopted by all major vendors. What use is it to have a fast release frequency if only few can keep up with the pace? ,"Yes, Hypermedia support in EE 7 is a joke. We ended up writing our own stuff.  "
France,Not important,,Very important,,Not important,,Very important,,Very important,,Not important,,,Not important,Very important,,,Very important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
France,Very important,,Important,,Important,,Important,Carefull !!! Remote Ejb with Tx support ? how do you want to do ? Don't speak about Jaxws Tx.... ,Somewhat important,,Somewhat important,,,Not important,Very important,,,Somewhat important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,,
Argentina,Somewhat important,,Very important,,Very important,,Somewhat important,,Very important,,Very important,,,Important,Important,,,Very important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,2-3 years,,
Germany,Very important,,Very important,,Very important,,I don't think we should eliminate EJB,,Not important,,Important,,,Somewhat important,Somewhat important,,,Not important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Wait to see how well microservices is adopted in practical enterprise environments.,,Java EE should not standardize ideas that are not clearly proven.,,2-3 years,2 years is absolutely fine,I am not a 100% sure if one release for all EE sub standards is still the best choice. Smaller changes like SE alignment could be done much faster.
Colombia,Very important,"The future of enterprise applications resides on the web, keeping up with the most current technologies will help establish Java as a viable platform for web development",Important,"The focus should be with inclusion of new features, but there should also be some alignment with SE",Important,"There should also be focus on newer forms of security, such as oauth and jwt for http security",Very important,"CDI has the potential to replace EJBs, and I think it should.",Important,"As I said earlier the future is on the web, as such is important to focus on JSON, but there are also plenty of very robust libraries that include the kind of JSON support required",Somewhat important,,"JSF is clunky and slow, and I think that, with time, frameworks will be created which support action oriented web development",Very important,Somewhat important,,"As stated, it would be hard to come to a standard for NoSQL JPA, it's better to focus on more achievable goals",Not important,Wait to see how well reactive is adopted in practical enterprise environments,,Java EE is already well suited to building practical microservices.,,Java EE should innovate in the same way that non-standard products do.,,2-3 years,,
Mexico,Somewhat important,,Very important,,Very important,,Very important,,Somewhat important,,Very important,,,Very important,Very important,,,Not important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,2-3 years,,
Colombia,Very important,Performance of Java-Web based Frameworks needs to kkep up with market trends,Somewhat important,,Somewhat important,,I don't think we should eliminate EJB,"In order to provide transition and backwards compatibiliy. EJBs don´t need to be eliminated.  However, CDI is the future",Very important,Every API must be provided in JSON format!  ,Somewhat important,,I Love prime because it allows to do similar development such as Angular.   ,Important,Somewhat important,,,Somewhat important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Java EE is already well suited to building practical microservices.,,It is OK for Java EE to standardize unproven ideas that seem promising.,,3-4 years,"My analogy is Mobile Dev   Android: Long pace, it allows the community to adapt and build, also for the group to have time to think.  iOS: Because of market, they need to release newers versions each year, for the rush, they don´t care about backwards compatibiliy, community don't know if program on Objective-c or swift   ",
Denmark,Very important,,Very important,This is a key requirement for match other up raising technologies/frameworks you can take advantage of the new features in the JVM,Important,,I don't think we should eliminate EJB,To many systems will be impacted by this change and IMHO there is nothing wrong with EJB it does a very good job. At least there should be a long transition period before EJB is   eliminated,Very important,,Important,,,Somewhat important,Very important,Both from test and production purpose this would make it a hole lot easier to be a developer when working with fully integrated CI environment,,Not important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",I would argue that Java EE fit nicely in the microservices as it's defined today. This is more a architecture choice of style IMHO if you find monoliths or microservices a better fit for you. But I also acknowledge we should better to embrace this architecture style,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,,
South Africa,Very important,,Very important,,Important,,Somewhat important,,Very important,,Important,,,Somewhat important,Very important,,,Not important,"Reactive is merely hype, nothing should be done",,Wait to see how well microservices is adopted in practical enterprise environments.,,Java EE should not standardize ideas that are not clearly proven.,,3-4 years,,
Turkey,Very important,,Very important,,Important,,Not important,,Important,,Very important,,,Somewhat important,Not important,,,Not important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,2-3 years,,
India,Very important,,Very important,,Important,,I don't think we should eliminate EJB,,Important,,Not important,,,Not important,Somewhat important,,,Not important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,Java EE should not standardize ideas that are not clearly proven.,,2-3 years,,"One must remember that EE is a specification, where items should be incorporated after due diligence with strong reasoning and not because doing the same thing differently"
France,Very important,,Very important,,,,,,,,,,,,,,,,,,,,,,,,
Denmark,Important,,Important,,Very important,,Very important,,Very important,,Important,,,Somewhat important,Very important,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,Java EE is already well suited to building practical microservices.,,"Java EE should innovate, but only very carefully.",,3-4 years,,
India,Very important,,Important,,Very important,,Very important,,Very important,,Very important,,,Not important,Very important,,,Very important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,2-3 years,,
Cote D'Ivoire,Very important,,Very important,,Somewhat important,,Very important,,Very important,,Important,,,Very important,Somewhat important,,,Important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,2-3 years,,
Bulgaria,Very important,,Very important,,Somewhat important,,Important,,Important,,Not important,,,Somewhat important,Very important,,,Somewhat important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Microservices is merely hype, nothing should be done.",,Java EE should not standardize ideas that are not clearly proven.,,2-3 years,,
France,Important,,Very important,,Very important,,Somewhat important,,Important,,Important,,,Somewhat important,Important,,,Important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
Germany,Very important,,Important,,Not important,,I don't think we should eliminate EJB,,Very important,,Somewhat important,,,Not important,Very important,,,Important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should not standardize ideas that are not clearly proven.,,1-2 years,,
France,Important,,Very important,,Important,,Very important,,Very important,,Somewhat important,,,Somewhat important,Very important,,,Very important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,2-3 years,,
Spain,Very important,,Very important,,Important,,Important,,Very important,,Important,,,Not important,Very important,,,Somewhat important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Wait to see how well microservices is adopted in practical enterprise environments.,,Java EE should not standardize ideas that are not clearly proven.,,1-2 years,,
Germany,Important,,Very important,,Very important,,Somewhat important,,Very important,,Important,,,Important,Somewhat important,,,Important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Java EE is already well suited to building practical microservices.,,Java EE should not standardize ideas that are not clearly proven.,,1-2 years,,
Chile,Important,,Important,,Important,,Not important,,Important,,Somewhat important,,,Important,Important,,,,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,Java EE should not standardize ideas that are not clearly proven.,,2-3 years,,
Italy,Very important,,Very important,,Somewhat important,,Somewhat important,,Very important,,Important,,,Somewhat important,Somewhat important,,,Not important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,,
Egypt,Very important,,Very important,,Very important,,Not important,,Important,,Very important,,,Very important,Important,,,Somewhat important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,It is OK for Java EE to standardize unproven ideas that seem promising.,,2-3 years,,
Colombia,Very important,,Important,,Very important,,I don't think we should eliminate EJB,,Very important,,Somewhat important,,,Very important,Very important,,,Very important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
France,Very important,,Very important,,Somewhat important,,Very important,,Very important,,Important,,,Not important,Important,,,Somewhat important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Microservices is merely hype, nothing should be done.",,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
Italy,Very important,,Important,,Very important,,Very important,,Somewhat important,,Important,,,Somewhat important,Not important,,,Not important,Introduce significantly specialized Java EE APIs for reactive programming,,Java EE is already well suited to building practical microservices.,,It is OK for Java EE to standardize unproven ideas that seem promising.,,2-3 years,,
Argentina,Important,,Very important,,Somewhat important,,Very important,,Very important,,Important,,,Very important,Very important,,,Somewhat important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,It is OK for Java EE to standardize unproven ideas that seem promising.,It can be targeted in a new kind of api (like a beta or experimental api),2-3 years,,"EIP standarization, "
United States,Very important,,Important,,Not important,,Important,,Very important,,Important,,,Important,Important,,,Very important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
Israel,Very important,,Very important,,Somewhat important,,Important,,Important,,Somewhat important,,,Important,Important,,,Not important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,1-2 years,,"The most important thing is to keep it simple and easy to use, everything new should follow the Covention over Configuration role.  Keeping backword compatability is also important"
Russian Federation,Very important,,Somewhat important,,,,Very important,,Very important,,Somewhat important,,,Very important,Important,,,Important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,3-4 years,,
Germany,Very important,,Important,,Very important,,Somewhat important,,Important,,Somewhat important,,,Not important,Not important,,,Important,Introduce significantly specialized Java EE APIs for reactive programming,,Wait to see how well microservices is adopted in practical enterprise environments.,,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,,
Portugal,Very important,,Very important,,Somewhat important,,Important,,Important,,Somewhat important,,,Very important,Somewhat important,,,Somewhat important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Java EE is already well suited to building practical microservices.,,Java EE should not standardize ideas that are not clearly proven.,,1-2 years,,
Mexico,Very important,,Very important,,Important,,Important,,Very important,,Somewhat important,,,Very important,Very important,,,Important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Wait to see how well microservices is adopted in practical enterprise environments.,,It is OK for Java EE to standardize unproven ideas that seem promising.,,2-3 years,,
Canada,Important,,Very important,,Important,,Somewhat important,,Very important,,Important,,,Very important,Very important,,,Somewhat important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,2-3 years,,
Mexico,Very important,,Very important,,Somewhat important,,Somewhat important,,Very important,,Very important,,,Very important,Important,,,Very important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
France,Very important,,Important,,Very important,,Not important,,Somewhat important,,Not important,,,Somewhat important,Not important,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,Java EE is already well suited to building practical microservices.,,"Java EE should innovate, but only very carefully.",,2-3 years,,
Italy,Important,,Very important,,Important,,Not important,,Somewhat important,,Important,,,Somewhat important,Somewhat important,,,Not important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,2-3 years,,
Thailand,Important,,Important,,Very important,,Not important,,Very important,,Very important,,,Important,Somewhat important,,,Not important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,3-4 years,,
Spain,Very important,,Very important,,Somewhat important,,Somewhat important,,Very important,,Important,,,Very important,Somewhat important,,,Somewhat important,"Reactive is merely hype, nothing should be done",,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
Romania,Important,,Very important,,Important,,Somewhat important,,Very important,,Very important,,,Not important,Somewhat important,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,1-2 years,,
France,Very important,,Important,,Important,,Somewhat important,,Very important,,Very important,,,Important,Important,,,Somewhat important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Java EE is already well suited to building practical microservices.,,Java EE should innovate in the same way that non-standard products do.,,2-3 years,,
Switzerland,Very important,,Important,,Somewhat important,,Somewhat important,,Very important,,Somewhat important,,,Important,Somewhat important,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,,
Spain,Very important,,Very important,,Very important,,Somewhat important,,Very important,,Important,,,Somewhat important,Very important,,,Important,Wait to see how well reactive is adopted in practical enterprise environments,,Java EE is already well suited to building practical microservices.,,"Java EE should innovate, but only very carefully.",,3-4 years,,
Georgia,Important,,Very important,,Very important,,I don't think we should eliminate EJB,,Very important,,Somewhat important,,,Not important,Somewhat important,,,Not important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
Italy,Important,,Very important,,Somewhat important,,Somewhat important,,Very important,,Important,,,Not important,Somewhat important,,,Very important,Introduce significantly specialized Java EE APIs for reactive programming,,Wait to see how well microservices is adopted in practical enterprise environments.,,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
United States,Very important,,Important,,Very important,,Very important,,Very important,,Very important,,,Very important,Very important,,,Very important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
Bulgaria,Very important,,Important,,Very important,,I don't think we should eliminate EJB,"I think rather than eliminate EJB, just leave them for backward compatibility and add CDI based services for newer applications.",Very important,,Very important,,,Important,Important,,,Very important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,It is OK for Java EE to standardize unproven ideas that seem promising.,,2-3 years,,
Spain,Important,,Very important,,Important,,I don't think we should eliminate EJB,,Important,,Somewhat important,,,Not important,Somewhat important,,,Not important,Wait to see how well reactive is adopted in practical enterprise environments,,Java EE is already well suited to building practical microservices.,,"Java EE should innovate, but only very carefully.",,2-3 years,,
United States,Very important,,Somewhat important,,Important,,Not important,,Very important,,Important,,,Not important,Important,,,Somewhat important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,1-2 years,,
Brazil,Very important,"I develop Web applications with JSF, so yes this is very important. ",Very important,,Very important,"Indeed, to add security in my web applications, I had to rely on third party libraries like apache shiro, which doesn't even integrate with cdi. A security api to java ee is very welcome. ",Important,"If this doesn't lead to more boilerplate code, I'm all for that. I'm not a specialist, but ejb seems pretty easy for use to me. ",Very important,"Totally agreed, the json-p api is very boring to build json with jax-rs. Something like Jackson binding would be great. ",Very important,Another thing we had to rely in third party libraries with different standards. Very welcome. ,,Somewhat important,Important,,,Not important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,Java EE should not standardize ideas that are not clearly proven.,"Java EE should not standardize trends, Java EE should should standardize standards. ",1-2 years,,
Germany,Somewhat important,,Very important,,Very important,,I don't think we should eliminate EJB,"EJB's are monitored by default within an EJB Container, they are pooled and passivated and can be failed over to different nodes in a cluster. IT's not only transactions that makes the difference!",Important,"What's there - for me it is good enough. I don't need binding and the way to construct a Json-Structure is a bit crude, but it is working.",Not important,,,Not important,Important,,,Important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Java EE is already well suited to building practical microservices.,,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,This depends on one question: how fast do the application server provider support the new releases.,"Clarify the usage of Websocket ServerEndpoints in a CDI environment. Let the endpoint use existing scopes or support a ""WebsocketRequestScope""/""WebsocketSessionScope"" to let a bean discover the current Websocket-Session for the current request."
United States,Somewhat important,,Important,,Important,,Very important,,Very important,,Somewhat important,,,Somewhat important,Very important,,,Somewhat important,Introduce significantly specialized Java EE APIs for reactive programming,,Wait to see how well microservices is adopted in practical enterprise environments.,,It is OK for Java EE to standardize unproven ideas that seem promising.,,3-4 years,,
United States,Important,,Somewhat important,,Important,,Not important,,Somewhat important,"App developers can use JSON freely, in whatever way they want. Integration with EE isn't critical.",Not important,"EE vendors already have good distributed caching solutions. While this might be a ""nice to have"", it's certainly not necessary.",,Not important,Somewhat important,This would be really nice for some applications.,,Not important,Introduce significantly specialized Java EE APIs for reactive programming,"This has been  a shortcoming of EE for quite some time. Especially with where we are as an industry, this model is very important, and it would be great to have built-in support for it.",Java EE is already well suited to building practical microservices.,,Java EE should not standardize ideas that are not clearly proven.,,2-3 years,,
Brazil,Very important,,Very important,,Very important,,Very important,,Very important,,Important,,,Very important,Very important,,,Important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,2-3 years,,Bruno to Java EE features from Spring framework
Slovakia,Somewhat important,,Important,,Very important,,Not important,What about pooling?,Important,,Important,,,Important,Important,,,Somewhat important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,,
Russian Federation,Very important,,Important,,Somewhat important,,Not important,,Very important,,Important,,,Somewhat important,Somewhat important,,,Not important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,3-4 years,,
Germany,Very important,,Very important,,Very important,,Somewhat important,,Very important,,Very important,,,Not important,Somewhat important,,,Not important,Wait to see how well reactive is adopted in practical enterprise environments,,Java EE is already well suited to building practical microservices.,,"Java EE should innovate, but only very carefully.",,1-2 years,,
France,Somewhat important,,Very important,,Important,,Somewhat important,,Important,,Not important,,,Very important,Very important,,,Important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,1-2 years,,
United States,Very important,,Very important,,Somewhat important,,Somewhat important,,Somewhat important,,Somewhat important,,"A JEE MVC framework would restart the Cola Wars. MVC should be plug-and-play, not part of the spec. JSF just left a bad taste and I don't care to see it repeated.",Not important,Somewhat important,,,Not important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Java EE is already well suited to building practical microservices.,I find Spring to be adequate.,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,,I hope JEE can catch up. I prioritize the language features and HTTP/2. Best to succeed with this release and its important features and hope to regain velocity and momentum
India,Somewhat important,"Not many customers hv adopted this, not sure",Important,"Creating multiple threads is not the option now, rather distributed computing is more widely being used. Lambda expression need to be adopted in all new development projects.",Important,,Important,,Very important,,Very important,,"JSF has its limitations, too many back and forth communications create issues, since ev UI comp is rendered on server side",Very important,Very important,,,Very important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.","Industries are facing challenge in implementing micro service based architecture, nobody has any ide of what this means in its entirety. Standardisation will help.",Java EE should not standardize ideas that are not clearly proven.,,1-2 years,,"Integration with streaming APIs like Spark, Math based languages like R can be considered."
Guatemala,Very important,,Important,,Important,,Somewhat important,,Very important,,Somewhat important,,,Very important,Important,,,Very important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,1-2 years,,
Switzerland,Very important,,Very important,,Not important,,I don't think we should eliminate EJB,We should align the two specifications. And make EJB a special type of a CDI Bean.,Not important,,Not important,I think it's hard to standardize caching because all the implementations that I know have specific features. And why should the cache be inside the app server? You don't put the DB inside your app server either.,But please have a look at ASP.NET Core! I don't want a ModelAndView as result of the Action. I need a typed result that can be used by code completion in the view.,Very important,Very important,It should support a config server and stages and profiles like Spring Cloud,I prefer to stay on the NoSQL native API of the product. As NoSQL is no standard there is no way to standardize this in a useful manner.,Not important,"Reactive is merely hype, nothing should be done",I don't think that we should put every hype into Java EE,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",That's very important. And please have a look at Spring. But keep in mind that uber jar may not work because of the Java EE specs like JPA where the JAR is the module,"Java EE should innovate, but only very carefully.",,1-2 years,,
Belgium,Important,,Very important,,Important,,I don't think we should eliminate EJB,,Important,,Important,,,Important,Somewhat important,,,Not important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",... but that sould'nt be blocking!,"Java EE should innovate, but only very carefully.",,1-2 years,,
Germany,Important,,Important,,Very important,,I don't think we should eliminate EJB,,Important,,Somewhat important,,,Very important,Somewhat important,,,Very important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Java EE is already well suited to building practical microservices.,,It is OK for Java EE to standardize unproven ideas that seem promising.,,2-3 years,,
United States,Very important,"But, without the dependency on Java SE 9.  We need a solution for ALPN that does not require Java SE 9.",Important,,Very important,,I don't think we should eliminate EJB,"We could still push for further deprecation of EJB-related items such as remote IIOP support.  But, complete removal of EJBs seems a bit drastic.",Very important,We either need to finish up the JSON features (both JSON-P and JSON-B) or just indicate that Jackson is the winner and be done with it.,Somewhat important,"Yes, JCache is long awaited, but is it too little, too late?  I'm just wondering if this is really necessary in the platform any longer...",Hasn't Spring MVC already won this battle?  I'm just wondering whether it's worth the effort...,Somewhat important,Very important,Flexibility for the cloud is critical.,NoSQL hasn't solidified yet enough in the industry...  Attempting to map JPA to multiple NoSQL dialects is going to be difficult.  Just use the native API for NoSQL.,Not important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,Frameworks such as Hystrix already provide many of the reactive paradigms.  Attempting to get this level of functionality into the Java EE APIs is going to take a huge effort.  Is it worth it?,Java EE is already well suited to building practical microservices.,,"Java EE should innovate, but only very carefully.","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.",1-2 years,,
Guatemala,Important,,Very important,,Important,,Important,,Very important,,Somewhat important,,,Not important,Somewhat important,,,Important,"Reactive is merely hype, nothing should be done",,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,1-2 years,,
Guatemala,Important,,Very important,,Very important,,I don't think we should eliminate EJB,,Very important,,Important,,,Very important,Very important,,,Important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,It is OK for Java EE to standardize unproven ideas that seem promising.,,2-3 years,,
Thailand,Important,,Important,,Important,,I don't think we should eliminate EJB,,Very important,,Important,,,Very important,Important,,,Important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,2-3 years,,
Poland,Somewhat important,,Very important,,Somewhat important,,Very important,,,,Somewhat important,,,Important,Important,,,Not important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should not standardize ideas that are not clearly proven.,,2-3 years,,
Greece,Very important,,Very important,,Very important,,Very important,,Important,,Important,,,Very important,Important,,,Somewhat important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,,
South Africa,Very important,,Very important,,Important,,Very important,,Very important,,Very important,,,Very important,Important,,,Very important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,,
Switzerland,Very important,,Very important,,Very important,,Important,,Very important,,Somewhat important,,,Not important,Important,,,Somewhat important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Java EE is already well suited to building practical microservices.,,"Java EE should innovate, but only very carefully.",,1-2 years,,
South Africa,Very important,,Very important,,Very important,,Very important,,Very important,,Very important,,,Very important,Very important,,,Important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should not standardize ideas that are not clearly proven.,,2-3 years,,
South Africa,Important,,Very important,,Somewhat important,,Important,,Somewhat important,,Somewhat important,,,Not important,Important,,,Somewhat important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should not standardize ideas that are not clearly proven.,,1-2 years,,
Belgium,Very important,,Important,,Very important,,Very important,,Very important,,Important,,,Somewhat important,Somewhat important,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,"Microservices is merely hype, nothing should be done.",,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,,In my opinion Java EE should be equal or better then Spring CDI and the Hibernate API.  Also easier en better integration with webservices or rest services.
United States,Very important,,Very important,,Very important,,Very important,,Very important,,Very important,,,Very important,Very important,,,Very important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,It is OK for Java EE to standardize unproven ideas that seem promising.,,2-3 years,,
Australia,Very important,URGENT MUST INCLUDE IN EE8 - there can not be any doubt of omission,Very important,Most Java EE applications are data intensive and Streams are so powerful..there should be alignment as early as possible,Very important,It is high time that Java EE security revamping is  given one of the top priority in JEE8,Very important,"Should proceed further to eliminate the EJB API and rewrite  services using CDI inside  JMS, Security, Concurrency as mentioned",Very important,JSON-B must be included in JEE8,Very important,JCache must be included in JEE8,A New MVC Framework introduction is important but good if can co-exist with existing JSF and PrimeFaces --> Also can there be inclusion of Portlet API too!?,Important,Very important,Static Config in Java EE (which is so powerful otherwise) at times seems very restrictive -- (and if possible) Dynamic Config API must be included in JEE8 ,Wait to see how well NoSQL can be useful in its evolution to most applications and also when standard data access API becomes available,Somewhat important,Introduce significantly specialized Java EE APIs for reactive programming,As mentioned earlier - something proven to be good in other frameworks - must be wisely adopted  after due diligence with all community agreement,Java EE is already well suited to building practical microservices.,Agrees with Adam Bien that Java EE is already well suited  and also Fowler that microservices may not make sense to most applications,Java EE should not standardize ideas that are not clearly proven.,There can be innovation on top of Java EE ecosystem and once they are proven - and if found necessary - can be embedded as standards later on,2-3 years,Not too early - not too late, Can there be inclusion of Portlet API as part of JEE8?  [[[[ Also if there can be link comparing one's answers v/s community majority answers v/s JCP experts opinions to get feedback ]]]] MANY THANKS TO ALL WHO INVOLVED
Italy,Important,,Not important,,Very important,,I don't think we should eliminate EJB,,Very important,,Very important,,,Not important,Important,,,Somewhat important,"Reactive is merely hype, nothing should be done",,"Microservices is merely hype, nothing should be done.",,Java EE should not standardize ideas that are not clearly proven.,,1-2 years,,
Czech Republic,Very important,,Important,,Important,,Somewhat important,,Not important,,Important,,,Not important,Very important,,NoSQL are heterogeneous. Standardization effort are full of troubles. I suggest to wait until JEE 9. ,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,Java EE is already well suited to building practical microservices.,"Application server with minimum required modules makes sense, but standards is probably not required. ","Java EE should innovate, but only very carefully.",,2-3 years,Beautiful design needs time. Poorly engineered APIs are made in rush. I believe the process can rarely be shortened.,Integration of existing standards with new Java SE API should be quicker. Maybe release a Java 7.5 with java.time integration?  
Germany,Very important,,Very important,,Important,,Not important,,Important,,Important,,,Not important,Somewhat important,,,Important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,,
Japan,Very important,,Somewhat important,,Very important,,Not important,,Not important,,Somewhat important,,,Very important,Important,,,Not important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,1-2 years,,"MVC, HTTP/2 and Security(OAuth2) are very important. Others may be released in Java EE 9 or later."
,Very important,,Very important,,Very important,,Somewhat important,,Important,,Important,,,Important,Important,,,Somewhat important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,,
United States,Very important,we need to move forward,Very important,"its easy to move on enterprise, we have to do less efforts on migration ",Important,security is always critical but there are work arounds,Important,,Very important,JSON is critical for JEE,Very important,,,Not important,Very important,,,Not important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",we are in production,1-2 years,,
Brazil,Very important,,Very important,,Very important,Very very very important,Somewhat important,,Important,,Very important,,,Somewhat important,Important,,,Important,Wait to see how well reactive is adopted in practical enterprise environments,,Java EE is already well suited to building practical microservices.,,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,,
Belgium,Very important,,Very important,,Important,,Somewhat important,,Very important,,Somewhat important,,Personally I don't see the added value for a Java-based front-end framework. Frameworks like AngularJS only need a REST layer.,Not important,Very important,,,Very important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
United Kingdom,Very important,"Based on criticism of Java Servlet by Play Framework, I would like to see tighter integration and less abstraction around HTTP. ",Very important,I want to move Java EE forward and squeeze the wriggle for legacy business who refuse to upgrade from ancient Java EE versions 5 and 6,Very important,,Somewhat important,,Very important,Important for stock microservices and component based services,Important,Hazlecast already supports JCache,This will be important for Single Page Applications on React.JS and AngularJS,Very important,Important,,I am unsure of the importance. How reasonably can one expect standard to behave in order to embrace the feature set of MongoDB (key value) and also say Neo4j (graph) database,Somewhat important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.","Micro services are about potentially scaling services. So what is missing here is the distributed data and communication and consistency targets.  This question is closely related to completable futures, asynchronous I/O and reactive programming",Java EE should not standardize ideas that are not clearly proven.,,1-2 years,,
United States,Somewhat important,,Very important,,Very important,,Somewhat important,,Very important,Very very very high return to a small investment. And absolutely critical to standardizing interoperability with so many other services. ,Somewhat important,,"Very important not just to add this but to add it in a way that plays well with other tech, especially client side tech. Might be nice to even write some standard glue to Angular (and Foundation and MaterialDesign and other UI tech starting to themselves become componentized) to really solidify Jave EE as the the most flexible server side solution. ",Very important,Important,"Maybe not right in the middle of run time but definitely post-build. Some better playing of configure with cloud deployment tech would be fantastic.   Also, better defaults because saying ""automagically"" wired up sounds great until the wiring doesn't work and now newbies are trying to debug complex CDI and JNDI failures to play nice in cloud deployments. ","Rather than just focusing on the DB, maybe something more like the philosophy behind streams in SE8. The code should express what you want to do and how to get it into a form to send over the wire. Sometimes that means storing in an ORM and sometimes I don't want the server having to do a lot of translational steps because that's the clients job now. ",Somewhat important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,It is OK for Java EE to standardize unproven ideas that seem promising.,"I would want people to turn to Java as the main tool in their toolbox. At a time when there's lot of change, balance the risk of standardizing too early against the risk of people departing the ecosystem. As a risk-risk trade in today's environment, I'd vote to keep the innovation in our ecosystem and find ways to mitigate the risk of having to later revise standards. ",2-3 years,,
Germany,Somewhat important,,Somewhat important,,Very important,,Not important,,Somewhat important,,Important,,,Important,Very important,,,Important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,It is OK for Java EE to standardize unproven ideas that seem promising.,,2-3 years,,
Singapore,Somewhat important,I am not sure about this,Very important,,Important,,Important,,Very important,,Important,,Please! This is very very important! And this is what I have been waiting for such a long time!!!,Very important,Somewhat important,,,Somewhat important,,,,,,,1-2 years,,
United States,Very important,Http/2's multiplexing and headers compression is more suitable for the current trend and enhances the latency and accelarates content download. ,Very important,As fork join pool is faster than executor services. In my perspective it's a new gear shifting to wards functional programming.,Very important,Reduces boilerplate code and much straight forward way of writing.,Important,,Important,,Very important,,,Very important,Important,,,Very important,Introduce significantly specialized Java EE APIs for reactive programming,,Java EE is already well suited to building practical microservices.,,Java EE should not standardize ideas that are not clearly proven.,,2-3 years,,
Australia,Very important,,Very important,,Very important,,Somewhat important,,Very important,,Somewhat important,,,Not important,Somewhat important,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,Java EE is already well suited to building practical microservices.,,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
Austria,Somewhat important,,Very important,,Important,,I don't think we should eliminate EJB,,Very important,,Important,,,Not important,Not important,,,Not important,Wait to see how well reactive is adopted in practical enterprise environments,,"Microservices is merely hype, nothing should be done.",,"Java EE should innovate, but only very carefully.",,2-3 years,,
Germany,Very important,,Very important,,Important,,I don't think we should eliminate EJB,,Very important,,Somewhat important,,,Important,Important,,,Important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Java EE is already well suited to building practical microservices.,,"Java EE should innovate, but only very carefully.",,3-4 years,,
Italy,Very important,,Very important,,Important,,Somewhat important,,Very important,,Important,,,Somewhat important,Important,,,Somewhat important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,1-2 years,,
India,Very important,,Very important,,Very important,Need more examples and how to's online. I couldn't find a single working application on authentication / authorization on jee,Not important,,Very important,,Somewhat important,,Not sure,Not important,Not important,,,Very important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should not standardize ideas that are not clearly proven.,,2-3 years,,
India,Very important,,Very important,,Very important,,Somewhat important,,Very important,,Important,,,Important,Very important,,,Very important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
Italy,Very important,,Very important,,Important,,Important,,Very important,,Very important,,,Not important,Important,,,Somewhat important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,2-3 years,,
United States,Somewhat important,,Important,,Somewhat important,,Somewhat important,,Important,,Not important,,,Important,Somewhat important,,,Important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,1-2 years,,
Italy,Very important,,Very important,,Very important,,Somewhat important,,Very important,,Important,,,Very important,Important,,,Not important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,1-2 years,,
Belgium,Important,,Very important,,Important,,I don't think we should eliminate EJB,,Very important,,Very important,,,Somewhat important,Somewhat important,,,Important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Java EE is already well suited to building practical microservices.,,It is OK for Java EE to standardize unproven ideas that seem promising.,,2-3 years,"For some of the sub-components, it should be easy to update them in between umbrella releases. I believe this was one of the original goals for EE 8 already, or at least it was the plan for doing so in GlassFish.","Profiles: currently, there is only the ""Web"" profile, apart from the full stack. Since mobile apps are booming, and those somehow need to connect to enterprises, it makes sense to have a ""Mobile"" profile that has some overlap with the Web Profile, but that doesn't include any front-end specs."
South Africa,Very important,,Very important,,Important,,I don't think we should eliminate EJB,,Somewhat important,,Very important,,,Important,Important,,,Important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Wait to see how well microservices is adopted in practical enterprise environments.,,Java EE should not standardize ideas that are not clearly proven.,,2-3 years,,"Add camel to EE as a standard. It has been proven enough, in my opinion."
Brazil,Very important,,Very important,,Very important,,Very important,,Very important,,Important,,,Important,Very important,,,Very important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,,
Spain,Very important,,Important,,Very important,,Important,,Very important,,Important,,,Somewhat important,Somewhat important,,,Important,Wait to see how well reactive is adopted in practical enterprise environments,,Java EE is already well suited to building practical microservices.,,Java EE should not standardize ideas that are not clearly proven.,,2-3 years,,
Brazil,Very important,,Very important,,Very important,,Somewhat important,,Very important,,Very important,,,Important,Very important,,,Very important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
Turkey,Not important,,Not important,,Not important,,I don't think we should eliminate EJB,,Very important,it should be in javase,Somewhat important,,,Very important,Not important,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,"Microservices is merely hype, nothing should be done.",,"Java EE should innovate, but only very carefully.",,2-3 years,,jsf..javascript...node...spa
United Kingdom,Important,,Very important,,Somewhat important,,Not important,,Important,,Somewhat important,,,Somewhat important,Somewhat important,,,Somewhat important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,1-2 years,,
India,Very important,HTTP/2 is the future and it's support is inevitable for any Web platform,Very important,Java SE 8 brought the next level of language features to Java and everyone must take advantage of it. ,Important,,Important,,Very important,,Somewhat important,,,Very important,Somewhat important,,,Important,Wait to see how well reactive is adopted in practical enterprise environments,,Java EE is already well suited to building practical microservices.,,"Java EE should innovate, but only very carefully.",,1-2 years,,
Germany,Very important,,Very important,,Very important,,Somewhat important,,Important,,Not important,,,Very important,Not important,,,Somewhat important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,1-2 years,,
India,Very important,,Important,,Important,,Somewhat important,Actually i'm note sure :),Important,,Important,,,Important,Somewhat important,,,Not important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,Java EE should not standardize ideas that are not clearly proven.,,1-2 years,,
Brazil,,,,,,,,,,,,,,,,,,,,,,,,,,,
Brazil,Important,,Somewhat important,lambda are useless. date/time API is good but every company already did its own api. It's important but not essential.,Important,,Important,,Very important,JSON is the new XML for data integration. Its essential to have it done as fast as you can.,Not important,,JavaScript it's the new deal and Java EE cant stay behind. Althoug I and many developers think that JSF has clean code and a lot of benefits over JavaScript.,Important,Important,,Always great to improve/increase the access of diferent kind of databases.,Very important,"Reactive is merely hype, nothing should be done",,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,2-3 years,,
India,Very important,,Very important,,Very important,,I don't think we should eliminate EJB,,Important,,Not important,,,Not important,Somewhat important,,,Not important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,Java EE should not standardize ideas that are not clearly proven.,,3-4 years,,
Kazakhstan,Somewhat important,I am using HTTP2 proxy.,Somewhat important,We can live without it,Very important,"If security would be easy as example above, don't do anything related to the security. Not very complete solution. I think there should be interfaces like:  interface AuthenticationProvider {     authenticate(String username, String password) throws AuthenticationException; }  interface AuthorityProvider {     Iterable< String> authorities(String username); }  And if our app needs security we can implement this interfaces",Somewhat important,Would be nice,Very important,MUST!,Not important,For me.,"There are a lot of other frameworks, it would be yet another MVC framework. So not so important",Somewhat important,Important,Sounds interesting,For me.,Not important,Wait to see how well reactive is adopted in practical enterprise environments,"Java EE is not for reactive apps, no...",Wait to see how well microservices is adopted in practical enterprise environments.,"There are other important things that needs to be done. At first Java EE should be smaller. Drop old specs, please.","Java EE should innovate, but only very carefully.",,1-2 years,Fast and little changes over slow and big changes,"Java EE should be more community oriented, improve and make changes fast in order to survive in less than 5 years... It's not dying now, but at least in last half year my interest is drops down significantly"
United States,Very important,,Very important,,Very important,,I don't think we should eliminate EJB,,Very important,,Very important,,,Very important,Important,,NoSQL is still early years. we can wait before a JSR is created for NoSQL Standardization.  ,Important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,1-2 years,,
Germany,Somewhat important,,Important,,Somewhat important,,Very important,,Very important,"Please don't call it JSON-P. That term has already been in use for years to describe ""JSON with padding"". See: https://en.wikipedia.org/wiki/JSONP",Important,,"For most parts when working with action oriented frameworks, you have your components and component libraries in JS Frameworks.",Very important,Somewhat important,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,Java EE is already well suited to building practical microservices.,,It is OK for Java EE to standardize unproven ideas that seem promising.,,2-3 years,,
Bulgaria,Very important,,Very important,,Very important,,Very important,,Very important,,Very important,,,Very important,Very important,,,Somewhat important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,,
Tunisia,Important,,Very important,,Somewhat important,,Somewhat important,,Very important,,Important,,,Very important,Important,,,Very important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,It is OK for Java EE to standardize unproven ideas that seem promising.,,2-3 years,,
United Kingdom,Very important,,Very important,,Important,,,,Very important,,Very important,,,Very important,Very important,,,Very important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,2-3 years,,
Czech Republic,Very important,,Very important,,,,Important,,Important,,Very important,,,Not important,Somewhat important,,,Somewhat important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Java EE is already well suited to building practical microservices.,,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,,
Germany,Very important,,Very important,,Somewhat important,,I don't think we should eliminate EJB,,Very important,,Not important,,,Very important,Not important,,,Not important,Introduce significantly specialized Java EE APIs for reactive programming,,Java EE is already well suited to building practical microservices.,,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
Italy,Very important,,Important,,Very important,,Important,,Very important,,Very important,,,Somewhat important,Very important,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
Czech Republic,Very important,,Very important,,Very important,!!!!!!!!!!!!!!!,Important,,Very important,,Very important,,,Not important,Somewhat important,,,Somewhat important,"Reactive is merely hype, nothing should be done",,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,2-3 years,,
France,Important,,Very important,,Somewhat important,,Very important,CDI vs EJB is a mess. Drop EJBs.,Somewhat important,,Somewhat important,,Too late. Enhance JAX-RS.,Not important,Somewhat important,Configuration API or Annotations ?,,Somewhat important,,I don't know. Reactive is too young for me.,"Microservices is merely hype, nothing should be done.",,Java EE should not standardize ideas that are not clearly proven.,,2-3 years,,
United States,Very important,,Very important,,Not important,,Not important,,Important,,Important,,,Somewhat important,Somewhat important,,,Somewhat important,Introduce significantly specialized Java EE APIs for reactive programming,,Java EE is already well suited to building practical microservices.,,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,,
Estonia,Important,,Very important,,Somewhat important,,Important,,Important,,Somewhat important,,,Not important,Important,,,Important,"Reactive is merely hype, nothing should be done",,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
Finland,Somewhat important,,Important,,Very important,,I don't think we should eliminate EJB,,Not important,,Somewhat important,,,Very important,Important,,,Somewhat important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,,
Vietnam,Very important,,Very important,,Very important,,Very important,,Very important,,Very important,,,Important,Very important,,,Very important,Introduce significantly specialized Java EE APIs for reactive programming,,Java EE is already well suited to building practical microservices.,,"Java EE should innovate, but only very carefully.",,2-3 years,,
Germany,Very important,,Very important,,Important,,Very important,All Java EE Annotations should be unique!,Somewhat important,,Somewhat important,,"Modern Views with Html5, JS, Css",Very important,Important,,Like Spring Data NoSQL,Very important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Wait to see how well microservices is adopted in practical enterprise environments.,,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,"No application servers, make war new ear!"
France,Very important,,Very important,,Important,,Somewhat important,,Very important,Just use Jackson,Somewhat important,,,Somewhat important,Somewhat important,,,Very important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",Actually I'd rather tend to remove JEE technologies as they are too monolithic. And use state of the art proven innovation that JEE can not standardise.,1-2 years,"Just break the model of one big JEE version, instead release sub project API at their own pace, and allow implementers to implements the wanted implementations.",Microservice spec should just be the JDK !!!
Germany,Very important,,Important,,Very important,,I don't think we should eliminate EJB,,Very important,,Important,,,Not important,Important,,,Not important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,1-2 years,,
Dominican Republic,Very important,,Very important,,Somewhat important,,Not important,,Important,,Important,,,Not important,Important,,,Not important,"Reactive is merely hype, nothing should be done",,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.","There should be, module of eager to prototype of a standard, and then later a real standard  The eager should not have backwards compatibility ",1-2 years,"It should be 1/year, and not everything have to be ready at the same time.  smaller goals, should be the new focus, and a long plan of constant evolution.","Cloud Support, Discovery Services "
Bolivia,Somewhat important,,Somewhat important,,Very important,,Important,,Important,,Very important,,,Somewhat important,Somewhat important,,,Important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,2-3 years,,
Brazil,Very important,,Very important,,Very important,,Important,,Very important,,Very important,,,Very important,Very important,,,Very important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
United States,Very important,,Important,,Somewhat important,,Not important,,Very important,,Somewhat important,,,Not important,Not important,,,Not important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Java EE is already well suited to building practical microservices.,,Java EE should not standardize ideas that are not clearly proven.,,1-2 years,,
Denmark,Somewhat important,,Very important,,Important,,Important,,Important,,Somewhat important,,,Somewhat important,Somewhat important,,,Somewhat important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,2-3 years,,
Brazil,Very important,,Very important,,Important,,Important,,Important,,Important,,,Important,Very important,,,Important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,1-2 years,,
Brazil,Important,,Not important,,Important,,I don't think we should eliminate EJB,,Important,,Not important,,,Somewhat important,Somewhat important,,,Very important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should not standardize ideas that are not clearly proven.,,3-4 years,,
Spain,Very important,,Very important,"Are you serious? Streams, lambda expressions and the date/time API are FUNDAMENTAL.",Very important,"Please, please, please, this part is absolutely outdated, specially when compared to the non official standard (Spring) and it is FUNDAMENTAL.",I don't think we should eliminate EJB,"I still consider REALLY relevant the sole idea of EJB. In this way, I think CDI is just a way of building EJB. I think we should never give up on EJB, no matter the ""bad press"" and the existence of simpler (not better) alternatives.",Very important,"JSON is effectively cannibalizing XML. We NEED to provide an standard and ease of use, in this sense, JSON-B would be a big step ahead.",Very important,"In a similar way to security, we really need an standard, at least for reference.","I've been professionally developing with JSF since version 1.1, almost eight years ago?. I gave up last year in favour of Spring MVC, it may not have components, it may not have a lifecycle, it may be lower level. But it is incredibly easier to use, far easier to debug and it does not involve the same amount of ""magic"" of JSF. JSF should be deprecated. be sincere, it had sense back in 2006, but not nowadays.",Very important,Somewhat important,,"Oh, c'mon, ever heard of Spring Data?",Very important,Wait to see how well reactive is adopted in practical enterprise environments,"As opposed to NoSQL, which I consider a mature set of technologies, I think reactive programming still needs to show its adoption rate and maturity.  We should wait and see.",Java EE is already well suited to building practical microservices.,,It is OK for Java EE to standardize unproven ideas that seem promising.,"The problem with EJB 2 was XML not the Entity Beans (which became standardized in a less powerfull way by hibernate/jpa). Talking about that, I think that was the most effective standardization ever done by Java EE, recognizing that Hibernate was working on the enterprise and standardizing it.",3-4 years,We need to consider the HUGE size of Java EE and the backward compatibility issues.,"Best wishes, we can do a better Java EE :)"
India,Very important,,Very important,,Important,,Very important,,Very important,,Very important,,Please don't ask me to learn another MVC framework,Not important,Very important,,It may vary but you can support most popular nosql solutions,Very important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,"Yes , you forget JPA 3"
Italy,Very important,,Important,,Very important,,Not important,,Very important,,Important,,,Important,Very important,,,Not important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,3-4 years,,
Netherlands,Very important,Essential,Important,,Very important,,I don't think we should eliminate EJB,Backwards compatibility is important for migrating legacy applications,Very important,,Not important,,Modern web applications use stateless REST services anyway,Not important,Somewhat important,,,Not important,,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should not standardize ideas that are not clearly proven.,,2-3 years,,
Sweden,Important,,Very important,,Somewhat important,,Not important,,Somewhat important,,Important,,,Important,Important,,"I think it is important to support a reactive model of access to databases, not only NoSQL flavored. Secondly it is important to try to support a common way to work with NoSQL",Very important,Introduce significantly specialized Java EE APIs for reactive programming,There should be a way to be able to avoid to rely on a thread per request model. To help with that it is helpful if there is something that is easy to use.,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.","Don't forget about logging, uber jar may not be important as long as you can run with dependencies.",Java EE should not standardize ideas that are not clearly proven.,,1-2 years,,
Greece,Very important,,Somewhat important,,Important,,I don't think we should eliminate EJB,,Important,,Not important,,,Important,Very important,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,"Microservices is merely hype, nothing should be done.",,"Java EE should innovate, but only very carefully.",,1-2 years,,
Germany,Very important,,Important,,Somewhat important,Not familiar enough to judge.,Somewhat important,,Somewhat important,,Very important,,,Not important,Very important,,,Very important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Java EE is already well suited to building practical microservices.,I guess time will bring more understanding and consent what a standard should look like,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,,
United States,Very important,,Very important,,Very important,,Important,,Very important,,Very important,,,Important,Very important,,,Very important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should not standardize ideas that are not clearly proven.,,1-2 years,,
Argentina,Very important,,Very important,,Very important,,Very important,,Very important,,Very important,,,Somewhat important,Very important,,,Very important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
Turkey,Very important,,Important,,Somewhat important,,Important,,Very important,,Very important,,,Very important,Very important,,,Important,Introduce significantly specialized Java EE APIs for reactive programming,,"Microservices is merely hype, nothing should be done.",,"Java EE should innovate, but only very carefully.",,1-2 years,,
Spain,Very important,,Very important,,Very important,,Somewhat important,,Very important,,Very important,,,Very important,Very important,"Runtime configuration changes that ease server provisioning is a must. Things like ease of use consul,etcd and others are very important imo",,Important,Introduce significantly specialized Java EE APIs for reactive programming,Even jdk9 comes with Flow. So EE should be ready take advantatge of it. Also a few EE experts should join the reactor community imo  ,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.","Service discovery, metrics/monitoring are a must today ",It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years, ,
United States,Somewhat important,"Most of the projects I work on are internal-use. The fact that browsers require encryption for HTTP/2 means that adopting HTTP/2 would be painful, since no certificate authority is going to issue a certificate for a private IP and self-signed certs have their own problems.",Very important,IMO this is the most important thing EE 8 needs to do.,Somewhat important,"I'm skeptical the security JSR will achieve a useful result. A standard API would be nice, but I have yet to encounter a security framework that was both flexible enough to easily meet the differing requirements of different applications, and was also straightforward to configure and use. PicketLink came close, but that project is dead now.",Very important,"The sooner EJB goes the way of the dodo bird, the better.",Not important,"There are already plenty of solid JSON libraries available for Java. The lack of a standard API hasn't been a problem for me, and I'd prefer to see limited development resources be allocated to something that isn't so well covered by the community.",Somewhat important,"I haven't spent much time looking at the JCache spec, but from what I've seen, I think the standard APIs aren't going to provide enough flexibility in many situations. Which means people are going to end up using proprietary APIs anyway, which defeats the purpose of having a standard API.","This would be nice to have, but I wouldn't classify it as essential. Straight JAX-RS is already a pretty good fit for frameworks like Angular.",Somewhat important,Not important,I've never had a need to be able to dynamically reconfigure stuff provided by the container.,"IMO this is a fool's errand. JPA has enough issues with its various abstractions, and it has the advantage of being able to rely on a consistent data model and mostly standardized query syntax. I have a very hard time picturing a NoSQL API that's going to work for Mongo and Redis and Cassandra and... etc.",Not important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,"Event-driven, non-blocking APIs are very important to me, but I'm not convinced a specialized reactive API needs to be added and then mapped onto all the other specs.","Microservices is merely hype, nothing should be done.",None of the projects I've worked on would have benefited from being decomposed into microservices.,"Java EE should innovate, but only very carefully.","I'm all for new ideas, but if they're going to make it into EE, the reason needs to be that people actually need them. Not just because X is the latest buzzword.",1-2 years,"It's important to keep in mind that there's a lag after the spec is finalized before vendors catch up. IIRC it took Red Hat/JBoss about a year to release an EE 7 certified server after the spec was finalized. So the release cycle needs to be fairly short, to help get new features into users' hands faster. It's okay (and maybe preferable) if that means releases are smaller.",
Germany,Very important,,Important,,Very important,,Not important,,Somewhat important,,Important,,,Very important,Very important,,,Somewhat important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Java EE is already well suited to building practical microservices.,,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,,I definetly would like a more dynamic way to access data like linq from C#. Streams are good - but for query lile requests it would fit very well.
Italy,Very important,,Important,,Important,,I don't think we should eliminate EJB,,Very important,,Very important,,,Not important,Very important,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,,
United States,Very important,,Very important,,Very important,,Important,,Very important,,Very important,,,Very important,Important,,,Important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,,
Germany,Important,,Very important,,Important,,Somewhat important,,Very important,,Very important,,,Somewhat important,Not important,,,Somewhat important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,It is OK for Java EE to standardize unproven ideas that seem promising.,,2-3 years,,
Poland,Very important,,Very important,,Very important,,Somewhat important,,Very important,,Important,,,Very important,Somewhat important,,,Somewhat important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
Italy,Important,,Very important,,Very important,,Very important,,Very important,,Important,,,Important,Important,,,Important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,2-3 years,,
Germany,Important,,Not important,,Not important,,Very important,,Very important,,Not important,,,Not important,Not important,,,Very important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,4-5 years,,
France,Very important,,Very important,,Somewhat important,,Very important,,Very important,,Important,,,Very important,Very important,,,Somewhat important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
Germany,Very important,,Very important,,Very important,,Important,,Somewhat important,,Somewhat important,,,Very important,Important,,,Very important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
Turkey,Very important,,Somewhat important,,Important,,I don't think we should eliminate EJB,,Somewhat important,,Important,,,Important,Important,,,Important,Wait to see how well reactive is adopted in practical enterprise environments,,Java EE is already well suited to building practical microservices.,,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,,
France,Very important,,Very important,,Somewhat important,,Not important,,Very important,,Somewhat important,,,Not important,Somewhat important,,,Important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should not standardize ideas that are not clearly proven.,,1-2 years,,
Turkey,Very important,,Very important,,Very important,,Very important,,Important,,Very important,,,Very important,Very important,,,Very important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,2-3 years,,
India,Very important,,Very important,,Very important,,Very important,,Very important,,Very important,,,Very important,Very important,,,Very important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
Brazil,Very important,,Very important,,Important,,Very important,,Very important,,Very important,,,Very important,Very important,,,Very important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
United Kingdom,Very important,,Very important,,Very important,,Not important,,Very important,,Very important,,,Important,Somewhat important,,,Important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,1-2 years,,
United Kingdom,Important,,Very important,,Important,,Important,,Important,,Important,,,Somewhat important,Important,,,Important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,,
India,Very important,Servlet or JSF has to be support all the features available through HTTP 2,Somewhat important,Some of the them in terms of concurrency are addressed using ManagedExecutorService introduced in Java EE 7. Mainly if the improvements are done to make use of the maximum capacity available on the machine to use cpu/cores available.,Not important,Security is based on the enterprise application which is being developed and its to the discretion of the company to implement the kind of security it requires if the fundamental security concepts are addressed these are enough. Not every application developed using Java EE 8 requires full-fledged security requirement.,I don't think we should eliminate EJB,why to reinvent the wheel which has already addressed most of the cases using EJB instead CDI can be leveraged for other features.,Somewhat important,,Very important,Next generation enterprise applications will mostly use distributed caching and this has to be a priority one functionality in Java EE 8. At the same time data consistency and integrity are to be fully addressed.,Applications which don't use JSF will use JS related like AngularJS in combination of RESTFul will be more in future.,Very important,Not important,,There is a need of hour to address even non RDBMS databases.,Very important,Introduce significantly specialized Java EE APIs for reactive programming,,Java EE is already well suited to building practical microservices.,,"Java EE should innovate, but only very carefully.",Entity beans are big blow on J2EE framework and this has lead third party tools to milk their businesses showing the flaw in it. Should be very cautious in getting new things on the board.,1-2 years,Its a changing world and customers do look for new things always though the standard comes late it has to address not only current but also future requirements. ,Most of the enterprise applications do require Graph and Grid for displaying and editing the business data. JavaFX do has graphing capability but at client side. For this requirement usually third party tools like FusionCharts and DHTMLX grid are used if there is a way to provide these features as well in Java EE 8 it will be great.
Bosnia and Herzegovina,Very important,Perhaps the most important standard to be introduced to JavaEE.,Very important,,Very important,Existing security model in Java EE is insuficient.,I don't think we should eliminate EJB,"EJB will be hard to eliminate, just because vendors of brand name application servers built so much of their functionalities around EJB container. Although, it would be a good thing to have only CDI for the sake of simplified development.",Very important,Many developers tend to go out of Java EE dependency for various libraries for JSON processing. It's crucial to have excelent JSON support so that only Java EE dependency is suitable for everything JSON related.,Not important,This spec is not that important in my opinion.,"This is a good step in admiting that JSF failed and in my personal opinion is the least used standard in Java EE framework. Everyone is turning their head for new front end technologies based on JS like Angular/React where MVC fits great. JSF is slow, hard to maintain and it's time to be retired is comming.",Very important,Very important,"Such a simple functionality to implement, but such a gamechanger for developers. Everyone has their own prefered solution for DC so it's important to provide a standard one.","This would be a plus for Java EE, bit it's not that important as previous standards, and probably hard to implement. .",Somewhat important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Java EE is already well suited to building practical microservices.,Java EE is already great for microservices development. Trust Adam Bien :-),It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,,
,Very important,,Very important,,Important,,Somewhat important,,Very important,,Very important,,,Somewhat important,Very important,,,Very important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,2-3 years,,
Belgium,Very important,,Very important,,Very important,,Not important,,Very important,,Very important,,,Not important,Important,,,Important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,,
Turkey,Important,,Important,,Very important,,Important,,Important,,Very important,,,Very important,Very important,,,Important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,4-5 years,,
Germany,Very important,,Important,,Important,,Somewhat important,,Very important,,,,,,Not important,,,Very important,Introduce significantly specialized Java EE APIs for reactive programming,,Java EE is already well suited to building practical microservices.,,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,,
Brazil,Very important,,Important,,Very important,,I don't think we should eliminate EJB,"With EJB we got a lot of services and pooling out of the box with a simple annotation, I don't think we should eliminate it. But instead, we could just reuse those services at CDI separately, at demand. In project which required highest level of consistency and atomicity, EJB should still play the role.",Very important,"Nowaday, JSON is widely used at all tecnologies, thus should be supported as soon as possible.",Very important,,"The lack of a MVC framework, in my opinion, was one of the biggest errors of Java EE. It should be provided since its beginning.",Very important,Very important,The dynamic configuration of data sources and JMS should be provided out of the box to facilitate the SAAS.,"I don't think we should standardize the use of a NoSQL  database, may be only its access. Each specific NoSQL database has its own features, which isn't so standard. So standardize its use will just kill its greatest features!",Somewhat important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Java EE is already well suited to building practical microservices.,Java EE already provide the tools for building microservices. I think it should only create new profiles for microservices which provides the principal JSR's.,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
Ukraine,Very important,,Important,,Important,For now Keycloack fills this gap very well. Unfortunately it does not work for all applications servers.,Important,,Important,It is important but there are 3-rd party libraries which solve the problem. So it's not urgent.,Very important,It's almost ready. Go ahead with it.,In order to work with JavaScript libs we alreday have JAX-RS,Somewhat important,Very important,Very important for cloud,No need and no way to standardize this,Not important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,"There is already async support for jax-rs. Enable usage of JDBC, JMS and cache in this model","Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",These features are important for the cloud in general and not only no micro services.,Java EE should innovate in the same way that non-standard products do.,The pace of innovation is very fast. You need to move as fast as possible,1-2 years,The pace of innovation is very fast. You need to move as fast as possible,
Greece,Important,,Important,,Important,,Somewhat important,,Important,,Important,,,Somewhat important,Important,,,Somewhat important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
Turkey,Important,,Not important,,Very important,,Somewhat important,,Important,,Important,,,Somewhat important,Somewhat important,,,Important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
India,Very important,,Very important,,Very important,,,,Very important,,Very important,,,Important,Important,,,Important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
Turkey,,,,,,,,,,,,,,,,,,,,,,,,,,,
India,Very important,,Very important,,Somewhat important,,Very important,,Very important,,Very important,,,Not important,Not important,,,Very important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should not standardize ideas that are not clearly proven.,,2-3 years,,
Germany,Very important,Clearly more than very important.,Very important,"Java 8 is the most important set of changes to the language since, erm, 5. Not leveraging lambdas and co would be very silly.",Somewhat important,,Very important,Are EJBs still a thing?,Very important,On the other hand you could just integrate Jackson and get over it.,Very important,,Spring and co have long solved this.,Not important,Important,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,"Highly reactive environments have long since moved past J2EE. Akka, Reactor, Vertx.","Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.","Well, try standardising, but I'd take the Netflix stack, Spring Boot, Dropwizard or something like that.",Java EE should not standardize ideas that are not clearly proven.,,2-3 years,,"I really forgot that JEE was still a thing, haven't touched it in years. Just servlet API (in the background) and JMS."
Hungary,Not important,We mainly use the remoting with rich clients,Very important,"It would be extremely useful to use parallel streams within Managed Entities (EJBs, etc.)",Very important,Resolving security-related incompatibilities has been our biggest single problem when moving from Glassfish 3.1.2 to Wildfly 10,Somewhat important,"Currently we mainly use the features that are available in EJBs, but it would be nice to unify EJBs and CDIs",Very important,It would be VERY important for us to automatically marshal to and from JSON with JAXB instead of 3rd party libraries,Very important,"We use A LOT of caching in our AS for reporting, etc. It would be great not having to write our own caching framework",Wicket is good for us right now. JSF is way to complicated and not scalable enough (EL code cannot be reused),Not important,Not important,,PostgreSQL is doing an excellent job for our limited big data requirements,Not important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,"If enough was known to a specialized API, then that would be great, but we prefer to incremental improvements rather than a poorly designed API ",Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,2-3 years,,
India,Very important,,Very important,,Very important,,Very important,,Very important,,Very important,,,Very important,Very important,,,Very important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
Germany,Important,,Somewhat important,,Important,,I don't think we should eliminate EJB,,Very important,,Important,,,Very important,Important,,,Very important,Wait to see how well reactive is adopted in practical enterprise environments,,Java EE is already well suited to building practical microservices.,,Java EE should not standardize ideas that are not clearly proven.,,2-3 years,,
Austria,Very important,,Important,,Not important,,Not important,,Very important,,Important,,,Not important,Very important,Please note that it is very important to distinct container configuration from application configuration! The later should finally get a standard. Probably close to what Apache DeltaSpike config provides. But keep it simple and stupid!,,Not important,"Reactive is merely hype, nothing should be done",,"Microservices is merely hype, nothing should be done.",,"Java EE should innovate, but only very carefully.",,3-4 years,,The JCP should be less political and more technical. Many EG members don't actually do much work and some even don't understand their topic.
Brazil,Very important,,Important,,Very important,,Somewhat important,,Very important,,Very important,,,Not important,Not important,,,Important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,Java EE should not standardize ideas that are not clearly proven.,,1-2 years,,
United States,Very important,,Important,,Very important,"This is vital work. But, the approach here is likely not the best, w/ embedded SQL and such. So, while this is vital work, it needs some serious thinking/design.",Important,,Very important,JSON is the way forward. The lack of top-tier support in JavaEE is inexcusable.,Important,,This needs to align with the current trend towards responsible JavaScript frameworks.,Important,Very important,Vital trend that must be kept up with.,,Important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Java EE is already well suited to building practical microservices.,,"Java EE should innovate, but only very carefully.",,3-4 years,,
Australia,Very important,,Very important,,Very important,,Very important,,Very important,,Very important,,,Very important,Very important,,,Very important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,1-2 years,,
Hungary,Very important,,Very important,,Important,,Somewhat important,,Very important,,Very important,,,Somewhat important,Somewhat important,,,Very important,Introduce significantly specialized Java EE APIs for reactive programming,,Java EE is already well suited to building practical microservices.,,"Java EE should innovate, but only very carefully.",,2-3 years,,
Netherlands,Important,,Important,,Somewhat important,,Not important,,Important,,,,,Important,Somewhat important,,,,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,2-3 years,,
France,Very important,,Very important,,Very important,,Very important,,Very important,,Important,,,Somewhat important,Very important,,,Not important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should not standardize ideas that are not clearly proven.,,2-3 years,,
France,Very important,,Very important,,Very important,,Important,,Very important,,Important,,I think web component is closer to the idea of jsf,Very important,Somewhat important,,,Important,Wait to see how well reactive is adopted in practical enterprise environments,,"Microservices is merely hype, nothing should be done.",,"Java EE should innovate, but only very carefully.",,1-2 years,,"Nothing special, if Jee haven't the feature I want I create a little workaround and wait the next version of Jee :-) "
Turkey,Important,,Very important,,Very important,,Very important,,Very important,,Very important,,,Not important,Very important,,,Important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,,
Bulgaria,,,,,,,,,,,,,,,,,,,,,,,,,,,
Colombia,Important,,Very important,,Somewhat important,,Very important,,Very important,,Somewhat important,,,Very important,Very important,,,Very important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,It is OK for Java EE to standardize unproven ideas that seem promising.,,2-3 years,,
United States,Very important,,Very important,,Important,,I don't think we should eliminate EJB,,Somewhat important,There a several open source production quality JSON APIs like Jackson available. It would make sense to adopt one of those rather then reinventing the wheel,Somewhat important,,,Not important,Very important,,,Important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
Finland,Very important,Just silly to leave it out. Or perhaps they want to ditch EE?,Important,,Very important,,Somewhat important,,Somewhat important,You have many libraries that are easy to adopt. On the other hand a working standard would be nice.,Important,,,Not important,Very important,,,Somewhat important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Java EE is already well suited to building practical microservices.,,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
Germany,Very important,,Important,,Very important,,I don't think we should eliminate EJB,,Very important,Including HAL Support like Spring,Not important,,,Very important,Important,,,Somewhat important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,2-3 years,,
Denmark,Very important,,Very important,,Not important,,Important,,Very important,,Somewhat important,,,Not important,Important,,,Not important,Wait to see how well reactive is adopted in practical enterprise environments,,Java EE is already well suited to building practical microservices.,,Java EE should not standardize ideas that are not clearly proven.,,2-3 years,,
Czech Republic,Important,,Important,,Important,,I don't think we should eliminate EJB,This is important but in scope of Java EE 8.,Very important,,Somewhat important,,,Not important,Very important,,,Very important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,2-3 years,,
Dominican Republic,Very important,,Very important,,Very important,,Very important,,Very important,,Very important,,,Important,Very important,,,Very important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
France,Very important,,Very important,,Somewhat important,,Not important,,Very important,,Not important,,We also need a good replacement for jsp ,Very important,Important,,Too difficult : too many differences between nosql storages ,Not important,"Reactive is merely hype, nothing should be done",,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,We really need a good replacement for jsp Typesafe : compiled : clean syntax etc
United States,Very important,,Very important,,Important,,Somewhat important,,Very important,,Very important,,,Important,Important,,,Important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,2-3 years,,
Armenia,Important,,Very important,,Important,,Important,,Very important,,Important,,,Very important,Somewhat important,,,Very important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
Lebanon,Important,,Important,,Very important,,Very important,,Very important,,Very important,,,Important,Very important,,,Not important,Introduce significantly specialized Java EE APIs for reactive programming,,"Microservices is merely hype, nothing should be done.",,"Java EE should innovate, but only very carefully.",,2-3 years,,Maybe standardize cloud features like jcloud?
Slovakia,Very important,,Very important,,Important,,Important,,Very important,,Very important,,,Somewhat important,Somewhat important,,,Very important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,2-3 years,,
Italy,Very important,,Important,,Important,,I don't think we should eliminate EJB,,Very important,,Important,,,Somewhat important,Somewhat important,,,Important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,2-3 years,,
Greece,Very important,,Very important,,Very important,,Not important,,Very important,,Somewhat important,,,Important,Important,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,1-2 years,,
Indonesia,Very important,,Very important,,Very important,,Very important,Come on. Newcomers already confused about what the EJB is.,Very important,,Very important,,,Very important,Very important,,,Very important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,,
United Kingdom,Very important,,Very important,,Very important,,Very important,,Somewhat important,,Important,,,Very important,Very important,,,Very important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should not standardize ideas that are not clearly proven.,,1-2 years,,
United States,Important,,Very important,,Very important,,I don't think we should eliminate EJB,,Somewhat important,,Somewhat important,,,Not important,Not important,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,Java EE should not standardize ideas that are not clearly proven.,,1-2 years,,
Germany,Very important,,Important,,Important,,I don't think we should eliminate EJB,,Very important,,Somewhat important,,,Not important,Important,,,Important,Wait to see how well reactive is adopted in practical enterprise environments,,Java EE is already well suited to building practical microservices.,,Java EE should innovate in the same way that non-standard products do.,,2-3 years,,
India,Very important,,Important,,Very important,,Important,,Very important,,Very important,,,Important,Very important,,,Very important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,It is OK for Java EE to standardize unproven ideas that seem promising.,,2-3 years,,no 
Estonia,Very important,Async communication over HTTP,Very important,Backward compatibility,Somewhat important,,Important,,Very important,Protocol definitions,Very important,Standardization ,,Somewhat important,Very important,,,Very important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",To avoid ad hoc legacy designs ,"Java EE should innovate, but only very carefully.",,1-2 years,,
Netherlands,Very important,,Very important,,Important,,Somewhat important,,Very important,,Important,,,Not important,Somewhat important,,,Not important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Java EE is already well suited to building practical microservices.,,Java EE should not standardize ideas that are not clearly proven.,,4-5 years,,"Good survey, hopefully JEE will stay alive. It would be a shame otherwise."
Sweden,Important,,Very important,,Very important,,Somewhat important,,Very important,,Important,,,Not important,Important,,,Somewhat important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Wait to see how well microservices is adopted in practical enterprise environments.,,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,,
France,Very important,,Important,,Somewhat important,,Not important,,Important,,Somewhat important,,,Not important,Not important,,,Somewhat important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Java EE is already well suited to building practical microservices.,,"Java EE should innovate, but only very carefully.",,2-3 years,,
Poland,Important,,Important,,Important,,Very important,,Very important,,Very important,,,Very important,Very important,,,Important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
Philippines,Very important,,Very important,,Very important,,,,Very important,,,,,Important,Very important,,,Important,,,,,,,,,
Germany,Important,,Very important,,Very important,,I don't think we should eliminate EJB,,Very important,,Very important,,,Very important,Very important,,,Somewhat important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,1-2 years,,
Colombia,Important,,Very important,,Very important,,Very important,,Very important,,Important,,,Very important,Very important,,,Not important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,2-3 years,,
Ireland,Very important,"HTTP/2 can give a bussiness a cutting edge compared to their competitors. Java EE, must not only take their developers into consideration but the clients that the developers work for.   If the developers don't have access to the latest technologies, then the people they work for are at risk of being competively behind, this puts the developers job at risk.",Important,"Keeping them aligned reduces complexity, the Java language is already being called verbose, to not have Java EE 8 aligned with Java SE 8, which has been out for a while will gain Java another reputation that it doesn't want and thus loose market share.  For me personally Date/Time is probably the most important feature. Date and Time API's gained Java a bad reputation in the past and should be removed as soon as possible to get rid of this bad preception that some Developers have about the Java Language.",Somewhat important,"Since I believe making the alignment with Java SE 8 to be more important than a new feature, this could become a second class citizen.  Most languages have simple extensible security, or none at all and frameworks are religed upon, so Java doing the same for another year or two wouldn't be much of a miss.",Not important,"Even if this was attempted, you would have to mark it deprecated in the API, to allow developers time to migrate.  The way this question is phrased is as if it could be done in one Java EE release, but this isn't actually possible.",Not important,"It is actually not important for Java to support JSON as much as people believe.  JSON support for Mongo DB and taking it from there in a JDBC connector might be as far as I personally would stretch the support of JSON.  Beyond that creating Objects directly from JSON and To JSOn just like JAXB annotation can do, ""might"" be usefull.   JAXB with JAXRS can already create the JSON for a Web App, so there really is only DBs that use JSON.",Somewhat important,"There are many many third party solutions that provide developers with these features, but this is still a nice to have, just to make it standard.","Beyond IOT and microservices, this is the next big market for Java, ignoring this MVC that integrates better with mordern Web App standards would be a fatail mistake.  This is a must have feature.",Very important,Not important,,"This is actually a difficult answer, even though I answered important, it is true that the NoSQL dbs are too diverse to create a standard.   Since they are likely to create their own standard eventually.   Creating a JDBC interface just for NoSQL and allow the developers of that particullar NoSQL DB to create the concrete class might force them to follow some standard.  I'll leave this to you guys, you know better.",Important,Wait to see how well reactive is adopted in practical enterprise environments,,Java EE is already well suited to building practical microservices.,Martin Fowler stated that you must be monolithic before you can even know that you should be micro.  So this means that there will be as many projects that need monolitch as micro-services.  Currently my project is monolithic and it would cost less to convert this project to microservices than to continue to procced with the monolithic.,It is OK for Java EE to standardize unproven ideas that seem promising.,"I think all the answers are incorrect.  Maintaining a standard costs, and takes man hours.   If you want to make something a standard in Java, the consider is it worth the cost of the standard vs it's value. This is the consideration needed.  By doing this very unimportant features, don't become standardized because they aren't that popular. Keep revisiting possible items to become standard and you will get the timing correct.  This question shouldn't have even been presented to the Java Community",1-2 years,"Release small, and Release often. 1-2 years was the smallest option here.  This is just a proven methodology.",
Germany,Very important,,Important,,Important,,Not important,,Important,,Somewhat important,,,Somewhat important,Very important,,,Important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Java EE is already well suited to building practical microservices.,,"Java EE should innovate, but only very carefully.",,2-3 years,,
India,Very important,,Very important,,Very important,,Very important,,Very important,,Very important,,"I don't about prime faces, but it is very important to have support with angular js and other js, because client side framework are evoling like anything decreasing burden on server",Very important,Very important,,It may be difficult but our EE should provide some support,Important,Wait to see how well reactive is adopted in practical enterprise environments,,Java EE is already well suited to building practical microservices.,,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
United Kingdom,Very important,,Very important,,Very important,,Not important,,Important,,Important,,,Important,Important,,,Very important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,,,,,
Austria,Very important,,Very important,,Very important,,Very important,,Very important,,Very important,,,Important,Very important,,,Very important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
Burkina Faso,Very important,,Very important,,Very important,,Important,,Very important,,Very important,,,Important,Very important,,,Very important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
France,Important,,Very important,,Important,,I don't think we should eliminate EJB,,Important,,Very important,,,Very important,Important,,,Important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should not standardize ideas that are not clearly proven.,,2-3 years,,
United States,Very important,,Important,,Very important,,Important,At the current technology level no need for pooling. Objects creation efficient enough. No need for ejb anymore ,Important,You can make Jackson as standard. Most of us use it anyway,Very important,,For God's sake please either eliminate JSF or don't waste any more time on it. New generation of programmers will never use it,Important,Very important,Important for the cloud deployment ,,Very important,Introduce significantly specialized Java EE APIs for reactive programming,"Reactive is the reason why Java EE loses to lightbend, node js and the like","Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",Those so called pundits barely have any real corporate experience. Look at success stories at Netflix and Amazon. ,Java EE should innovate in the same way that non-standard products do.,Remember you are fighting for your survival. No one cares what current or past generations use. You need to worry about newer generations. They would not care about standard but more about hotter tech,1-2 years,Otherwise you will become irrelevant.,I know Java has a very rich set collection APIs. But it would not hurt if someone took clojure's immutable and persistent APIs and included in jdk. Those would very useful with Java 8 style functional and massively parallel processing 
Germany,Very important,,Very important,,Very important,,Very important,,Very important,,Somewhat important,,,Very important,Very important,,,Not important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
United Kingdom,Very important,,Very important,,,,,,Very important,,Very important,,,Very important,Very important,,,Very important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
Poland,Somewhat important,,Very important,,Important,,Very important,,Somewhat important,,Important,,,Not important,Important,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,Java EE is already well suited to building practical microservices.,,"Java EE should innovate, but only very carefully.",,1-2 years,,
Canada,Important,,Very important,,Very important,,Somewhat important,,Very important,,Important,,,Very important,Somewhat important,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,Java EE is already well suited to building practical microservices.,,"Java EE should innovate, but only very carefully.",,2-3 years,,
United Kingdom,Very important,,Very important,,Very important,,I don't think we should eliminate EJB,,Very important,,Very important,,,Very important,Very important,,,Very important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,2-3 years,,
United States,Important,,Very important,,Important,,I don't think we should eliminate EJB,I think we should eliminate EJB eventually. I think large enterprises aren't ready to be off yet so actually removing support doesn't feel urgent.,Somewhat important,,Somewhat important,,I put not important because so many people don't use JSF now. There's alternates in the MVC space so it isn't as big a pain point as other areas. (aka the above),Not important,Somewhat important,,,Not important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,Java EE should not standardize ideas that are not clearly proven.,,2-3 years,There's also an aspect that each release of Java EE requires updates to app servers.,
Serbia,Important,,Very important,,Important,,Very important,,Very important,,Very important,,,Important,Very important,,,Important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,2-3 years,,
Canada,Very important,,Important,,Important,,Important,,Very important,,Very important,,,Not important,Important,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,2-3 years,,
Brazil,Important,,Somewhat important,,Very important,,Not important,,Very important,,Somewhat important,,,Very important,Very important,,,Very important,,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,2-3 years,,
United States,Very important,,Very important,,Very important,,Somewhat important,,Very important,,Somewhat important,,,Somewhat important,Important,,,Somewhat important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,,
Brazil,Very important,,Very important,,Somewhat important,,I don't think we should eliminate EJB,,Somewhat important,,Somewhat important,,,Somewhat important,Important,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,2-3 years,,
United States,Important,,Very important,,Very important,,I don't think we should eliminate EJB,Don't destroy working code!,Very important,,Important,,,Important,Important,,,Important,Introduce significantly specialized Java EE APIs for reactive programming,Real users expect web pages to work this way.,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,1-2 years,"Multiple years is too long. People start using proprietary solutions and real problems remain unsolved, unnecessarily. If a feature misses the release train, then it should just go out the next year.",JavaEE servers should be pre-package and easily configurable in Docker containers.  Better standard monitoring hooks without JMX security issues would be great.
United States,Important,,Very important,,Important,,I don't think we should eliminate EJB,,Very important,,Somewhat important,,,Somewhat important,Somewhat important,,,Important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Java EE is already well suited to building practical microservices.,,"Java EE should innovate, but only very carefully.",,2-3 years,,"I would like to see individual technologies release independent of the larger EE spec.  If Servlet 4.0 is ready to go now, it shouldn't have to wait for CDI 1.3 (or 2.0, whatever). This might take more planning but should allow more frequent releases."
India,Very important,"When modern browsers support http2, we really should endorse it.",Important,,Very important,,Very important,CDI has a bunch of awesome features which are also easy to use. Extending the api makes sense. ,Very important,,Very important,This is really important.  Current jpa integration with cache (eclipselink) is not straight forward and this can really help. ,,Important,Important,,,Somewhat important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.","It's important for standardisation , for large organizations to adopt them without concerns, as they always fear lack of support in the longer term for non standard features. ",Java EE should not standardize ideas that are not clearly proven.,,1-2 years,,
United States,Very important,,Very important,,Important,,Important,,Important,,Not important,,,Somewhat important,Somewhat important,,,Not important,"Reactive is merely hype, nothing should be done",,"Microservices is merely hype, nothing should be done.",,"Java EE should innovate, but only very carefully.",,2-3 years,,
Germany,Important,,Very important,,Important,,Somewhat important,,Very important,,Very important,,,Somewhat important,Important,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,,
India,Very important,,Important,,Very important,,Very important,,Very important,,Important,,,Important,Somewhat important,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,It is OK for Java EE to standardize unproven ideas that seem promising.,,2-3 years,,
Brazil,Important,,Very important,,Somewhat important,,Very important,,Very important,,Somewhat important,,,Very important,Not important,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,1-2 years,,Maybe a rpc standard
United States,Important,,Very important,,Very important,,Very important,,Very important,,Important,,,Important,Somewhat important,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,2-3 years,,
Brazil,Very important,,Very important,,Important,,Very important,,Very important,,Important,,"Basing the MVC spec in the jax-rs instead of servlets its a mistake that cannot be reverted. MVC spec should be abandoned, or rethinked. ",Not important,Somewhat important,,,Not important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,1-2 years,,
United States,Important,,Very important,,,,Important,,Very important,,Important,,,Important,Very important,,,Not important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Wait to see how well microservices is adopted in practical enterprise environments.,,Java EE should innovate in the same way that non-standard products do.,,2-3 years,,
Poland,,,,,,,Very important,,,,,,,,,,,,,,,,,,,,
United States,Somewhat important,,Very important,,Important,,I don't think we should eliminate EJB,,Very important,,Important,,,Somewhat important,Important,,,Very important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,2-3 years,,
India,Very important,,Very important,,Important,,Very important,,Important,,Very important,,,Not important,Important,,,Somewhat important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,2-3 years,,"Functional, reactive and lightweight are three things that may still keep EE alive for some longer time. Modularizatiin is another important feature."
India,Very important,,Very important,,Very important,,Very important,,Important,,Very important,,"If this is reactive in nature, it adds more context",Very important,Very important,Very very useful when migrating to higher environment,"As industry is moving towards it, it can be used as de-facto standards",Very important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should not standardize ideas that are not clearly proven.,,2-3 years,,
France,Very important,,Very important,,Very important,,Important,,Important,,Very important,,,Very important,Very important,,,Not important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,2-3 years,,
South Africa,Very important,,Very important,,Very important,,Somewhat important,,Very important,,Very important,,,Important,Very important,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,,Improve EJB remote lookup. Introduce non-point to point remote lookup. If EJB features are moved to CDI then also include this as well
Switzerland,Very important,Quick adoption of external standards is very important imo.,Very important,It would help companies also going forward with jana 8 se and later and stop sticking to java 7. From code side improvements are significant as well.,Very important,Security is the most painful area as of now especially regarding application portability.,Important,Usind cdi wherever possible simplifies the platform and also allows essier integration with se since cdi 2 also will support se.,Somewhat important,There are plenty of good frameworks out there on oss. No big pressure having a standard imo here.,Somewhat important,,,Somewhat important,Very important,,,Somewhat important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.","Perhaps we should make a separation inti draft standards, where we can more innovate and final standards where bachwards compatibility is more in focus.",1-2 years,,
United States,Very important,,Very important,"JPA: DateTime, Stream, Optional etc. JSF: DateTime JAXRS: DateTime, PUT method, Future/CompletableFuture(more async support)",Very important,1. declarable annotation approach is great. 2. programmatic manual way is also in my dream. such Spring Security like configuration(fluent DSL configuration builder).,Important,"I hope: 1. transaction, JMS/MDB, can be used standalone with CDI POJO. 2. EJB.next is only for distributed transaction/JTA?",Very important,"But currently I used Glassifsh/Wildfly I can configure JSON ser/deser via its APIs, is there some standard way to configure JSON provider and ser/deser rules?",Very important,And do not forget to update JPA 2nd Cache to this API.  Also like Infinispan fluent DSL configuration builder for programmatic config.,"I have tried this mvc, for me, it is not good, not bad.  I hope the Servlet spec can add more security control...CORS, CSP, XSCF",Somewhat important,Important,provides profiled based configuration for all specifications.  like Spring Boot configuration.,"Hibernate OGM, and EclipseLink have done the great work. No need extra standards for NoSQL.",Very important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,"Accept the reactive stream standard.  improved the servlet, Jaxrs and JPA, JMS for async execution, and provides RxJava like APIs.  such as return Observerable< Entity> in Jaxrs, process it via JMS , and find by JPA(return related).","Microservices is merely hype, nothing should be done.","Microservice is a practical pattern, it is no need to standardize it in Java EE.  Spring Boot/Netflix, Wildfly swarm have done great work. ",Java EE should not standardize ideas that are not clearly proven.,I think it should be careful to standardize ideas...,3-4 years,"a big upgrade is very important, but some maintained improvement should be accepted.   Such as, Java EE7 is released, some alignment with Java 8 can be done in a maintained version.","java.net is shutdown soon, I hope all community driven reference implementation can be moved to a new website, a central community for all developers and container providers. And Java EE container ref(Glassfish) could be released more frequently, I hope there is 3~4 updates per year."
Europe,Important,,Very important,,Important,,Somewhat important,,Important,,Important,,,Very important,Important,,,Somewhat important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Wait to see how well microservices is adopted in practical enterprise environments.,,Java EE should innovate in the same way that non-standard products do.,,2-3 years,,
,Very important,,Very important,,Very important,,Very important,,Very important,,Very important,,,Very important,Important,,,Very important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,3-4 years,,
Hungary,Very important,To late already,Very important,,Not important,,I don't think we should eliminate EJB,,Important,,Important,,,Somewhat important,Not important,,,Important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
Netherlands,Very important,,Important,,Somewhat important,,I don't think we should eliminate EJB,,Important,,Somewhat important,,,Important,Important,,,Not important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,1-2 years,,
Germany,Very important,,Very important,,Very important,,Not important,,Important,,Important,,,Not important,Important,,,Very important,Wait to see how well reactive is adopted in practical enterprise environments,,Java EE is already well suited to building practical microservices.,,"Java EE should innovate, but only very carefully.",,1-2 years,,
Italy,Very important,,Important,,Somewhat important,,Not important,,Very important,,Somewhat important,,,Somewhat important,Very important,,"It is much more important to enable providers of NoSQL databases to offer APIs that integrate smoothly with JavaEE. For me it doesn't make sense to use JPA with a graph database for example. I'd love to exploit its features through a proper API instead. JCA seems to be to heavyweight, I am missing resource providers for OrientDB or Neo4j.",Not important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,Java EE should not standardize ideas that are not clearly proven.,"Making it easier to add upcoming ideas in applications, not necessarily in the frameworks would do.",3-4 years,New standards should help solve common problems frequently addressed by diverging solutions.,
Netherlands,Very important,,Very important,,Important,,Not important,,Very important,,Important,,,Somewhat important,Important,,,Very important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,1-2 years,,
India,Very important,We need the support for the multiplexed HTTP rather than the older version which requires multiple TCP connections for loading the resources.,Very important,With the enterprise frameworks like Spring going for Java SE 9 support with the launch of Java SE next year it is imperative SE 8 support is provided for Java EE. THe use of lambda and streams will improve the readability and also the reduction in JVM footprint will be advantageous to the community.,Important,,Somewhat important,"This can be taken care gradually, it's important but not something I am concerned from the delivery aspect of the application.",Very important,With the mobile applications and thick client era of Angular 2. We need JSON support which is strong and flexible.,Very important,"With distributed caching becoming the order of the day, it is important Java EE provides it out of the box.",Not important. With Angular 2 and React the UI will be dominated by these frameworks. It's the enterprise side we must concentrate.,Not important,Important,,"The developer community has multiple resources. So having a standard API is not going to serve the purpose, with so many variants of NO SQL.",Not important,Wait to see how well reactive is adopted in practical enterprise environments,,Java EE is already well suited to building practical microservices.,,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,"Frankly Java EE takes care of most of the practical problems of an enterprise solution. So with these improvements of HTTP 2, JCache and JAVA SE 8 support. We should be able to provide a robust solution."
United Arab Emirates,Important,,Very important,,Very important,,Important,,Very important,,Somewhat important,,,Important,Important,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,Java EE should not standardize ideas that are not clearly proven.,,2-3 years,,
Qatar,Very important,,Very important,,Somewhat important,,Very important,,Very important,,Very important,,,Important,Important,,,Very important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,"I love to see java ee moving forward. However, as a  Spring user, i am very happy and pleased with the support and innovation it provides."
Sweden,,,,,,,Very important,,Very important,,,,,Very important,Very important,,,,,,,,,,4-5 years,,
Belgium,Very important,,Very important,,Somewhat important,,Somewhat important,,Important,,Important,,,Not important,Somewhat important,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,,
Germany,Very important,,Important,,Very important,,Not important,,Important,,Important,,,Important,Very important,,,Important,Wait to see how well reactive is adopted in practical enterprise environments,,Java EE is already well suited to building practical microservices.,,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,,
France,Somewhat important,,Important,,Very important,,Very important,,Very important,,Important,,,Very important,Very important,,,Somewhat important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,2-3 years,,
Australia,Important,,Very important,,Not important,"Unless you're going to be building things in such a way that it's hard for people to screw up and build insecure stuff, I'm not sure I'd support this.  Things I'd suggest:  - encouraging people to use something like bcrypt for password storage - providing for (temporary) account lockout after n attempts - auditing authentication attempts (audit event handler?) - making sure the DB identitystore provides a credential that can be used to enforce result set restriction on subsequent queries  Personally, I think it'd also be worth investing in the JPA spec to allow for things like Hibernate's Filters (to allow automatic query restriction and prevent users from reading or updating data that they don't own).. ",Important,,Important,,Somewhat important,,"As I'm reading more and more of these questions, I'm starting to realise that Java EE probably isn't really aimed at me, despite the fact that I'm writing web applications in an enterprise environment.  Modern web applications are converging towards SPAs; decoupled (largely RESTful/JSON) services, combined with HTML5 / web-components (eg. polymer, react, angular) front-ends which are built with nodejs-based tooling.  JAX-RS is great - although it's a lot easier and faster to spin a server up using spring boot or dropwizard than it is to get things running in a heavyweight container.  If JavaEE can offer anything in the web space, it seems that it might be a way of constructing scalable, stateless, performant, manageable, enterprise-ready services, and a set of best practices for putting this stuff together.  More-or-less formalising what the spring-boot and dropwizard teams have been up.  Combined with what's been going on in the devops space - infrastructure-as-code, immutable phoenix servers etc - the benefits of deploying apps to heavyweight, centrally managed servers are becoming fewer and fewer :/ ",Not important,Not important,,See spring-data-* for examples of nice data abstraction layers. ,Somewhat important,Introduce significantly specialized Java EE APIs for reactive programming,"Reactive is the future. Invest in this. Encourage people to write event-sourced, CQRS based systems.  Don't re-invent things; throw your weight behind the technologies and ideas that exist already.  ","Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.","Again, the spring guys have a massive head start on you here, with spring boot + the ecosystem around it.  Microservices are, IMO, essential for delivery of complex systems while maintaining a high cadence of delivery, which is increasingly expected by customers - both internal and external.","Java EE should innovate, but only very carefully.","Do things once, do them well :)",1-2 years,,"Basically, I think JavaEE should be driven in a direction that encourages developers to build secure, reliable, maintainable, supportable, and where possible rapidly delivered software according to an aggregation of industry best practices.  In my industry, support for HTTP/2, websockets, streaming data, and reactive streams are important, but like so many other things, these have been quite well solved by non-EE frameworks and libraries already.   I don't care too much for CDI - I've got spring for the bits I care about, although if I could have a super lightweight container for this I might be convinced, as spring is a bit on the heavyweight side.  I don't care much for JSF/JSP/... - I'd rather use proper front-end tooling to build the web part of my app, and where possible, have it delivered entirely independently as a static bundle.  I don't care much for stateful EJB's; I'd rather be stateless.  All the best with defining the spec.  I fear though that it's going to be almost impossible trying to please everyone, and I can certainly accept that I'm perhaps not your target audience here, so I won't be disappointed with whatever outcome eventuates. :)"
Colombia,Important,,Very important,Se necesita sacar provecho a la agilidad de las corrientes de datos ,Important,,Important,,Somewhat important,,Very important,,,Somewhat important,Very important,,"Se necesita acceder a data no relacional, como bigdata, sistemas automáticos de información, etc.",Very important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",No se debe tratar de controlar todo,2-3 years,"Las soluciones empresariales no se pueden actualizar cada que haya una nueva versión, porque cuesta mucho dinero",¿Se tiene claro quién seguirá al frente de la estandarización de Java?
Slovenia,Very important,,Important,,Somewhat important,,Not important,,Very important,,Somewhat important,,,Very important,Very important,,,Important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,2-3 years,,
United States,Very important,,Very important,,Very important,,Important,,Important,,Very important,,,Very important,Important,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,,,"Java EE should innovate, but only very carefully.",,3-4 years,,
Czech Republic,Somewhat important,,Important,,Somewhat important,,I don't think we should eliminate EJB,,Important,,Important,,,Not important,Somewhat important,,,Important,Wait to see how well reactive is adopted in practical enterprise environments,,Java EE is already well suited to building practical microservices.,,"Java EE should innovate, but only very carefully.",,2-3 years,,
France,Very important,,Very important,,Important,,Very important,,Very important,,Not important,,,Important,Very important,,,Important,Introduce significantly specialized Java EE APIs for reactive programming,,Java EE is already well suited to building practical microservices.,,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
United States,Very important,,Very important,,Important,,Somewhat important,,Somewhat important,,Somewhat important,,,Not important,Somewhat important,,,Not important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,1-2 years,,
United States,Very important,,Very important,,Important,,Important,,Very important,,Somewhat important,,,Important,Important,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,1-2 years,,
Sweden,Somewhat important,,Very important,,Very important,,I don't think we should eliminate EJB,,Very important,,Important,,,Somewhat important,Somewhat important,,,Important,"Reactive is merely hype, nothing should be done",,Java EE is already well suited to building practical microservices.,,"Java EE should innovate, but only very carefully.",,1-2 years,,
Czech Republic,Important,,Very important,,Not important,,Important,,Important,,Important,,,Somewhat important,Important,,,Important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
Brazil,Important,,Very important,,Somewhat important,,Somewhat important,,Very important,,Very important,,,Very important,Important,,,Important,"Reactive is merely hype, nothing should be done",,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,,
Canada,Very important,,Very important,We need a Fork/Join that can deal with blocking IO operations.,Not important,"It's a terrible API, putting queries in annotations. That's what AOP is for.",Not important,,Somewhat important,,Important,Improving this API would go a long way towards what people use NoSQL for.,Not Java's problem,Not important,Somewhat important,I'm all for a better configuration API (like preferences for the desktop apps) but I'm not sure if the dynamic nature is that critical especially given the move towards immutable infrastructure.,It's not possible to do a good job here frankly. Focus on JCache and you won't need NoSQL.,Not important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,The JDK moves too slowly to keep up with this field.,Wait to see how well microservices is adopted in practical enterprise environments.,Keep focusing on modularization--being able to start up with only the relevant Java capabilities deployed--and microservices will be well-served for the time being.,Java EE should not standardize ideas that are not clearly proven.,,1-2 years,JEE is pretty irrelevant these days frankly because it moves so slowly.,
Canada,Very important,,Important,,Somewhat important,"If you can't learn from acegi/spring security and/or apache shiro and other majour players, then this initiative would venture into the tar pits.  Perhaps carve off a smaller piece of ""security"" and ask the question again?",Somewhat important,I agree in principal that ending EJB in favour of more modern solutions could be a good direction.  I object to spending the time and energy to create new standards and re-write all of the EJB services.  If this was a guiding direction and services were replaced with alternatives in a phased approach it would be much more appealing.,Somewhat important,Java standards committees made a damn meal of xml parsing the first time around even though there are fine de-facto standards (xerces) around.  Hopefully they don't do the same thing with json parsers.  We have tools that work today (jackson and friends).,Very important,,It is more important the good quality server side code can be written and tuned efficiently in java and served up over standard protocols like http and jms.  Maybe it would be a good idea to leave the front end to the browser in this day and age?,Not important,Important,,,Somewhat important,"Reactive is merely hype, nothing should be done","This initiative is pointlessly broad.  If there is a real problem to solve then yes, please spend time on it. rxjava is interesting if you are trying to write an event based program.  Doesn't need to be in jee at this stage.","Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.","Improving the tooling and libraries around building real-world apps is worth spending time on, microservices or not.",Java EE should not standardize ideas that are not clearly proven.,Maybe change the process and include incubator ideas that are not ratified standards?  The open source community is healthy and there are a wealth of libraries to choose from.  Is there a way to fund or promote those projects that are doing it better than java itself?,1-2 years,,"I think some of the biggest functional areas where JEE could help and does not are around batch processing and enterprise integrations. I am happy to see that the survey authors were aware of apache camel.  Spring integration and spring batch are also interesting directions that could save many hours in the field given some improvements.  What kinds of applications are most people build with JEE?  Webapps rightly get a lot of focus as they are the majourity, but backoffice apps are complex and underserved by the specifications.  Would love to see refinements of JSR 352 and some thinking about how JEE could work better with EIPs."
France,Important,,Very important,,Very important,,I don't think we should eliminate EJB,,Important,,Very important,,,Somewhat important,Important,,,Very important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,2-3 years,,
,Important,,Very important,,Important,,I don't think we should eliminate EJB,,Important,,Very important,,,Important,Very important,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,Java EE is already well suited to building practical microservices.,,It is OK for Java EE to standardize unproven ideas that seem promising.,,2-3 years,,
United States,Important,,Very important,,Somewhat important,,Not important,,Somewhat important,"JSON-B and JAXB necessarily have areas of overlap.  This redundancy should be eliminated, to reduce the effort to support both XML and JSON.",Important,,"Just my opinion, but I think action-oriented frameworks are obviated by JAX-RS.",Not important,Important,Security role/group mapping.,,Very important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",Not all of the features.  Discovery is an area that needs more support.,"Java EE should innovate, but only very carefully.",,1-2 years,,
Egypt,Very important,,Very important,,Very important,,I don't think we should eliminate EJB,,Very important,,Important,,,Not important,Very important,,,Not important,Wait to see how well reactive is adopted in practical enterprise environments,"I believe the reactive approach has yet to proof itself in large/complex applications, so there is no need to add it to the API as the frameworks are sufficient for now","Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should not standardize ideas that are not clearly proven.,,3-4 years,,
Ecuador,Very important,,Very important,,Important,,Very important,,Very important,,Very important,,,Somewhat important,Very important,,,Important,Introduce significantly specialized Java EE APIs for reactive programming,,Java EE is already well suited to building practical microservices.,,"Java EE should innovate, but only very carefully.",,2-3 years,,
India,Very important,,Very important,,Important,,Important,,Very important,,Very important,,,Important,Important,,,Important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Java EE is already well suited to building practical microservices.,,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
Australia,Very important,,Very important,,Important,,Very important,,Very important,,Very important,,,Very important,Very important,,,Very important,Introduce significantly specialized Java EE APIs for reactive programming,,Java EE is already well suited to building practical microservices.,,"Java EE should innovate, but only very carefully.",,2-3 years,,
,Very important,,Important,,Somewhat important,,Very important,,Very important,,Very important,,,Very important,Very important,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,Java EE is already well suited to building practical microservices.,,Java EE should innovate in the same way that non-standard products do.,,4-5 years,,
Japan,Not important,,Very important,,Important,,Somewhat important,,Very important,,Very important,,,Very important,Very important,,,Important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,1-2 years,,
Switzerland,Important,,Very important,,Somewhat important,,Not important,,Very important,,Important,,,Important,Not important,,,Somewhat important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
Switzerland,Very important,,Important,,Very important,,Not important,This would have a MASSIVE impact to a lot of applications out there. Therefor the complete elimination in Java EE 8 is more than questionable. ,Important,,Very important,"JCache is very important, but I'm not sure if the current state of the spec is good enough...",,Not important,Important,,,Very important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.","Even if I agree, that we can already do ""Microservices"" in Java EE we still lack of Runtime Spec. So any progress in this direction is welcome...","Java EE should innovate, but only very carefully.",,2-3 years,,"As mentioned unter 12, Java EE should standardize the runtime in order to provide more benefit of such a spec. "
Romania,Very important,,Somewhat important,,Important,,Very important,,Somewhat important,,Somewhat important,,,Very important,Important,,,Somewhat important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,Java EE should not standardize ideas that are not clearly proven.,,2-3 years,,
Germany,Very important,,Very important,,Important,,Not important,,Important,,Important,,,Very important,Important,,,Not important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",Java EE should not start to standardize all named features at once but maybe start with uber jars.,"Java EE should innovate, but only very carefully.",,1-2 years,,
Romania,Very important,,Very important,,Important,,Very important,,Very important,,Important,,,Very important,Very important,,,Important,Introduce significantly specialized Java EE APIs for reactive programming,,Java EE is already well suited to building practical microservices.,,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,,
Sweden,Important,,Important,,Important,,Somewhat important,,Very important,,Somewhat important,,,Very important,Somewhat important,,,Somewhat important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Wait to see how well microservices is adopted in practical enterprise environments.,,Java EE should innovate in the same way that non-standard products do.,,2-3 years,,
Switzerland,Very important,,Important,,Important,,Somewhat important,,Very important,,Very important,,,Important,Important,,,Important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Java EE is already well suited to building practical microservices.,,"Java EE should innovate, but only very carefully.",,2-3 years,,
United Kingdom,Important,,Very important,Developments in jee and Java language need to be fairly well matched. Enterprise Java should be an opportunity for showcasing Java language features; otherwise the latter are relegated to small projects and student assignments. ,Important,,Very important,"In my organisation when we can afford to do so, EJBs are replaced with CDI when an opportunity presents itself. This means we have legacy modules with EJBs and are slowly phasing them out. I suspect this is happening elsewhere too. Deprecation mechanisms exist so they should be used in ee 8 to properly phase out EJBs and do for the jee community what it is already slowly doing itself. ",Important,,Important,,,,Very important,"Many aspects of an application depend on customer specific config and requiring restarts of an application server every time a single config changes is outdated, slow and painful.",No need to try and standardise something that is itself not standardised. ,Not important,Wait to see how well reactive is adopted in practical enterprise environments,Jee is not a leader here. No point trying to bolt on standards for it. Orgs that are building reactive apps do so using other frameworks and other languages. ,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",Providing help to modularise applications is always a good idea. Introducing micro services to the jee environment as a standard can only help jee users create more stable systems. ,"Java EE should innovate, but only very carefully.","No need to just be a follower, but when something makes it as a jee spec it is there to stay (at least for a long time) so decisions should not be taken lightly.  One thing that should also be kept in mind is speed of implementation. How many compliant commercial jee 7 providers are there ? When was the spec released? ",2-3 years,,
France,Important,,Important,,Somewhat important,,Important,,Very important,,Important,,,Somewhat important,Somewhat important,,,Not important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,3-4 years,,
Germany,Very important,,Very important,,Very important,,Somewhat important,,Important,,Somewhat important,,,Somewhat important,Somewhat important,,,Important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Java EE is already well suited to building practical microservices.,,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,,
,Important,,Very important,"Although some things can be done with Java EE 7 without a lot of pain (date/time apis, 'simple' lambda expression), already done code with for example, java streams, will be very much problematic when trying to use that code with Java EE 8 without those pieces. Please, fully align Java EE with Java SE 8.",Somewhat important,,Somewhat important,,Somewhat important,"JSON is almost just XML using braces and braquets, althought is important to have at least a basic API on Java EE 8.",Somewhat important,,,Somewhat important,Not important,,,Important,Wait to see how well reactive is adopted in practical enterprise environments,,Java EE is already well suited to building practical microservices.,,"Java EE should innovate, but only very carefully.",,2-3 years,,Maybe JavaFX features on the server ? Not in GUI-aspects but on observable-listeners-property thing.
Netherlands,Not important,"I need data form webserver. Dynamic html? That is static, on client side it becomes dynamic. So no advantage of using http2. Servelts should de be decoupled from transport protocol. Http is the worst protocol ever invented",Very important,Mangers are too stupid. They don't understand java 1.8 se doesn't support java 1.8 ee. So your are not allowed to upgrade 1.7.0_25  jre tot 1.8.0_x. Lucky for me oracle announced eol on 1.7.  Hope the will announce eol on managers too...,Very important,Jaas should die. Security managers are of NO use at all. Java EE didn't had any security in the first releases. Security was retro fiitted in the wrong way. Best thing to do? Ditch java and start over again and use 25 years of knowledge how not to program ,Very important,"Transactions??? Http is stateless. Transactions don't scale. If you need transactions, the design is wrong. Eliminate ejb and cdi",Very important,Xml should die. Pojo should serialize to json by default,Not important,Chaching is never needed. Period. Not using caches makes results real time and thus predictable ,Redering of data to the user should be done on the client. It's only needed there. Jsp jsf etc missed the html5 train. ,Not important,Very important,"Xml config should die. Everything should be done with annotations. They are documented, so a ide can present what should be entered. Web.xml etc programmers have to guess what to type? It 2016 not 1980!!!",But implement it in a new way. Persistence api is a wrong concept. I more intelligent than a dumb wizzard creating named queries. Persistence api is too slow and caching is wrong.,Very important,"Reactive is merely hype, nothing should be done","Blocking? A single transaction lasting for 2 seconds is not blocking. If you need asynchronous things, the design is flawed. Start writing high performance queries.","Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",But weblogic like webservers are not micro at all. Micro means a full 723x rfc compliant webserver included into the jar. Only one jar. Starting that jar means deployment. Osgi etc is not needed for microservices. Every microservice uses 1 tcp tls port,Java EE should innovate in the same way that non-standard products do.,Enterpise computing and innovation don't  mix. You cannot walk with dinosaurs ,1-2 years,"Hope jigsaw will make innovation modular, step by step, releases every week","Java should support stand alone functions. Most of the stuff isn't a object and should be forced into an object. Static main should become just main. Stop overuse of interfaces, inheritance and abstractions. There is no such thing as an servletrequest"
Germany,Very important,,Important,,Very important,,Somewhat important,,Important,,Important,,,Very important,Important,,,Very important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,2-3 years,,
Turkey,Very important,,Very important,,Very important,,Important,,Very important,,Very important,,,Very important,Important,,,Very important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,Java EE should innovate in the same way that non-standard products do.,,1-2 years,,
United Kingdom,Important,,Very important,,Very important,,Very important,,Very important,,Somewhat important,,,Somewhat important,Somewhat important,,,Important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,1-2 years,,
United States,Very important,,Very important,,Important,,Somewhat important,,Very important,,Somewhat important,,,Somewhat important,Not important,,,Not important,Wait to see how well reactive is adopted in practical enterprise environments,,Wait to see how well microservices is adopted in practical enterprise environments.,,Java EE should not standardize ideas that are not clearly proven.,,3-4 years,,"Above all else, retain backward compatibility to support legacy deployments as far as practicable."
Norway,Very important,,Very important,,Somewhat important,,Not important,,Very important,,Important,,,Somewhat important,Very important,,,Not important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,,,"Java EE should innovate, but only very carefully.",,1-2 years,,
Brazil,Very important,,Very important,,Very important,,Very important,,Very important,,Somewhat important,,,Very important,Not important,,,Very important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,It is OK for Java EE to standardize unproven ideas that seem promising.,,2-3 years,,
Brazil,Very important,,Very important,,Important,,Important,,Somewhat important,,Important,,,Somewhat important,Somewhat important,,,Somewhat important,Introduce significantly specialized Java EE APIs for reactive programming,We need JDBC non-blocking.,Java EE is already well suited to building practical microservices.,,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,,
United Kingdom,Somewhat important,,Important,,Somewhat important,,I don't think we should eliminate EJB,,Somewhat important,,Somewhat important,,,Not important,Important,,,Not important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,2-3 years,,
Brazil,Very important,,Very important,,Important,,Important,,Important,,Important,,,Very important,Important,,,Important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,1-2 years,,
Bangladesh,Very important,,Very important,,Very important,,Not important,,Very important,,Very important,,,Very important,Very important,,,Not important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,"Java EE should innovate, but only very carefully.",,1-2 years,,
Poland,Not important,,Very important,,Very important,,Very important,,Very important,critical,Important,,,Important,Very important,,,Very important,Wait to see how well reactive is adopted in practical enterprise environments,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,,Add more security support in jvm level like authenticated object access
South Africa,Very important,,Important,,Somewhat important,,Important,,Somewhat important,,Important,,,Not important,Somewhat important,,,Not important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",,1-2 years,,
Bangladesh,Very important,,Very important,,Very important,,Very important,,Very important,,Very important,,,Somewhat important,Very important,,,Very important,Introduce significantly specialized Java EE APIs for reactive programming,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,,,2-3 years,,
United States,Very important,Things that can help performance and productivity are very welcomed,Important,"Not sure I understand ""streams currently cannot be safely used in Java EE environments"". ",Somewhat important,The timeline of Java EE releases does not lend itself well to changes within the security landscape. It might be somewhat nice to revamp existing API. Some of the existing frameworks respond faster to new security needs.,Important,I guess there are existing workarounds. These services can be achieved without EJB today,Important,Again can Java EE respond to the needs of developers community at a faster rate?,Important,"I think this is important. The idea of standardized API and multiple  implementations sounds good, but I think JCache JSR if need be can be enhanced to address concerns or needs of developers where required.  I am not sure of what might be preventing developers from leveraging JCache in JEE environment today.",Seems too late in the game. Can it evolve at the rate other opensource frameworks are evolving? Will it be as feature rich as existing tools and innovate within this space? I would rather efforts and resources be channelled into areas that are most beneficiary to developers. ,Not important,Somewhat important,Not sure what dynamic configuration means here. But I have leveraged JMX to achieve something I think might be close,Allow communities respond to innovations within the nosql space. An half baked API isn't what is needed.,Not important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,Wait to see how well microservices is adopted in practical enterprise environments.,,"Java EE should innovate, but only very carefully.",Be an enabler,1-2 years,Tools out there are responding faster to needs with multiple releases.,"Standardize where necessary, but create a platform that enables innovation."
Slovakia,Important,,Very important,,Somewhat important,,Not important,,Somewhat important,,Important,,,Not important,Important,,,Somewhat important,Continue making ad-hoc improvements to support reactive programming in each Java EE API,,"Java EE should standardize features such as uber jars, metrics, discovery, circuit breakers and bulkheads.",,It is OK for Java EE to standardize unproven ideas that seem promising.,,1-2 years,,
Colombia,Very important,,Important,,Very important,,Very important,,Important,,Important,,,Very important,Important,,,Very important,Introduce significantly specialized Java EE APIs for reactive programming,,Java EE is already well suited to building practical microservices.,,It is OK for Java EE to standardize unproven ideas that seem promising.,,2-3 years,,