Earlier this month, the Jakarta EE community members were invited to participate in the Jakarta EE Community Voices document, which focuses on technical innovations for Jakarta EE specifications. Contributions in this document reflect participants’ personal perspectives on areas where they hope to contribute time.
However, it is important to mention that they do not represent hard commitments and they are not intended to imply community agreement or deadlines. There were 24 participants and 78 answers, as well as over 6.000 words used to describe members’ opinions and expectations regarding the direction of Jakarta EE.
See the stats here.
WE WANT YOU, COMMUNITY!
We’d like to formally invite all community members to participate in #JakartaEE Community Voices document focused on technical innovations for Jakarta EE specifications!
More info: https://t.co/eQJtl23R42 pic.twitter.com/uJ8u2v6fjC
— Jakarta EE (@JakartaEE) 10. Oktober 2018
Jakarta EE Community Voices: Highlights
tl;dr
- CDI Alignment is a strong area of focus with the community with the most vision and excitement.
- Java 11 and Modularity is the most actively asked question in the Jakarta EE community
- MicroProfile, Microservices & Cloud remains a strong topic
- Expansion of the ecosystem with Jakarta NoSQL
Modularity
One of the questions included in the document was about the fact that there are no specifications in Jakarta EE that leverage modularity. Are there any opportunities in the specifications where participants plan to contribute for modularity, functional APIs or new JVM language features to play a role? Let’s find out.
Tomitribe CEO David Blevins argued that “a very compelling use case for functions exists in the Bean Validation specification where Predicates could play a great role in eliminating boilerplate associated with writing validation rules. A second opportunity exists in the EJB Timer API, which executes code at a given schedule or time. Allowing for functions to be passed as the targets of such timers is a now painfully obvious improvement that really needs to happen along with the greater effort to free the Timer API from being an EJB-only feature.”
Markus Karg, JAX-RS Eclipse Committer Member revealed that the JAX-RS API already provides a pro-forma module descriptor since 2.1 and they are planning to add module declarations into that in a future release.
Both JSON-P and JSON-B define modules, added Werner Keil, while Reza Rahman believes that “the work to align with Java SE 8 still remains incomplete in terms of adopting repeatable annotations, the Date Time API and CompletableFuture in APIs like EJB, Concurrency Utilities for Java EE and WebSocket. Most of this is so trivial the community could pick it up. I also think as many Java EE APIs as possible need to provide support for Java SE and the Java Module System. In fact, the Java Module System can become another modularity option for Java EE centric runtimes.”
Reza claims that by doing this, Java EE will be a truly disruptive technology in the enterprise Java space. He expressed the same opinion in our Understanding Jakarta EE series, where he stated that “the lack of modularity in Java EE is one of the key reasons Java EE has always been conservative about endorsing hype and not adding unproven technologies.”
Personally, I would like to see modularity achieved through JPMS as well as standardized options for thin wars, fat jars and hollow uber jars. I can say I think Open Liberty does a very nice job in this regard although they have not added JPMS support just yet. I think a corollary to modularity support is making as many APIs as possible standalone and more Java SE friendly. Another key to modularity I believe is having a Servlet only Core Profile that does not include CDI (indeed the core can even be thinner like a Netty style network protocol layer that’s a subset of the current Servlet functionality).
Nathan Rauh revealed that they are prototyping a way to create CompletableFuture/CompletionStage from a managed executor in MicroProfile and they hope that it will be adopted into the EE Concurrency Utilities specification.
Sebastian Daschner opined that there’s a huge opportunity in supporting new JVM language features such as Java 8 lambdas throughout the specifications and argued that boilerplate code will be reduced if developers are allowed to define and pass functions as part of programmatic declarations. However, there are still many open points where EE standards can improve the support of features that have been introduced in JDK 8, including CompletableFuture, repeating annotations, or the Date Time API.
Although modularization is not required, one cannot deny its importance. According to Dmitry Kornilov, they have JPMS modules to support in Helidon, JSON Processing, JSON Binding and Yasson. Standalone JAXB, JAX-WS and SAAJ are also modularized, EclipseLink modularization is in progress. If more projects start working on it, the Jakarta EE platform could become fully modularized.
Free: BRAND NEW DevOps Whitepaper 2018
Learn about Containers,Continuous Delivery, DevOps Culture, Cloud Platforms & Security with articles by experts like Michiel Rook, Christoph Engelbert, Scott Sanders and many more.
Microservices and cloud
What opportunities do participants see for specifications to better support microservices and cloud? For starters, JAX-RS will be extended by features for Cloud, Microservices and Edge Computing step by step, said Markus Karg. The first step was made with the addition of the non-server Java SE bootstrap API which allows to startup a microservice within one second (JAX-RS 2.2), which comes in handy when an industrial device is used as an on-premise edge tool. Furthermore, “this feature already includes optional support for Microprofile Config API to externalize the complete configuration for example cloud setups and is planned to be released right after the trademarks contract with Oracle allows it,” he added.
Josh Juneau opined that Jakarta EE web UI specifications could be built out for better cloud and microservices integration and noted that “Project Mojarra is already positioned well to work as a front-end for microservices, as it is now very well integrated with CDI and suitable for use with stateless views. However, right now there is no standard way to call upon remote services such as those served via JAX-RS. Although it is fairly easy to utilize a JAX-RS client to pull in data from external sources, it would be nice to have a formal and more standard means of setting up a JAX-RS client in Mojarra and Eclipse Krazo controllers,” he concluded.
Kenji Kazumura claimed that “Java is not always the best language to be used for Microservices and Cloud,” which means Jakarta EE will have to collaborate with all the polyglot languages such as Go and Python which can make fast and small systems. Meanwhile, IBM’s Emily Jiang believes that Java is “the perfect language for developing cloud-native microservices, especially with the support of MicroProfile programming model.” She also added that the combination between Jakarta EE and MicroProfile will take microservices to the cloud.
We’ve only scratched the surface and there are a lot of great thoughts in there so I warmly invite you to read the entire document.
Last but not least, don’t forget to check out the Eclipse Foundation Specification Process draft, which leverages and augments the Eclipse Development Process (EDP). The EDP defines important concepts, including the Open Source Rules of Engagement, the organizational framework for open source projects and teams, releases, reviews, and more.
Confused about what’s going on with Jakarta EE? Check out our Understanding Jakarta EE series
- David Heffelfinger: “I wouldn’t like to see Jakarta EE tied to any specific container orchestration tool”
- Markus Eisele: “I strongly believe there is a lot to do to make Jakarta EE ready for the future”
- Josh Juneau: “The platform needs to evolve more dynamically than it had done in the past”
- Werner Keil: “Jakarta EE should become more modular than it is right now”
- Ondrej Mihalyi: “MicroProfile is paving the way for better microservices support in the Jakarta EE ecosystem”
- Reza Rahman: “Modularity is key to faster release cycles”
- Dmitry Kornilov: “Jakarta EE APIs should be more cloud-friendly”
- Arjan Tijms: “Recognizing the importance of Kubernetes likely means a further reduction in the importance of running multiple applications on a single Jakarta EE server”
- Richard Monson-Haefel: “Jakarta EE 9 will begin the transition to a simpler, lighter, and more flexible platform”
- Otávio Gonçalves de Santana: “Jakarta EE tools should support Kubernetes”
- Guillermo González de Agüero: “MicroProfile saved Java EE & will have a key role in its cloud-native transformation”
- Michael Hofmann: “Combining Jakarta EE with MicroProfile could slow down the progress of MicroProfile”
- Mark Struberg: “JakartaEE should allow intermediate ‘bugfix releases’”
- Scott M. Stark: “MicroProfile’s purpose will still be useful even after Jakarta EE is fully functional”
- Markus Karg: “While Jakarta EE 8 does not add much functionality on top of Java EE 8, people should adopt it ASAP to provide feedback”
- Rudy De Busscher: “The MicroProfile specifications can fill the missing gaps of Jakarta EE if you want to use microservices today”
- Sebastian Daschner: “Jakarta EE should address some of Java EE’s past shortcomings”
- Steve Millidge: “MicroProfile has made excellent progress in experimenting with Microservice APIs built on a foundation of Jakarta EE APIs”
- Christian Kaltepoth: “User feedback is of central importance so that Jakarta EE can go in the right direction”
- Thilo Frotscher: “The platform must support cloud and container operations better”
- Thorben Janssen: “The integration of Kubernetes should be a priority for Jakarta EE”
- Mark Little: “If MicroProfile and Jakarta EE tried to merge now, both would suffer”
The post Jakarta EE Community Voices: What lies ahead for Jakarta EE? appeared first on JAXenter.
Source : JAXenter
