When I thought about it, I noticed that there were few easy-to-understand explanations. I thought that many people might be confused, so I dared to write the truth (what I think) gently without fear of misunderstanding. (If you have any misunderstandings or mistakes, please let us know.)
The first thing I thought about in 2017 was the article about Java EE being transferred from Oaracle to the Eclipse Foundation. It's been a long time now, so I feel like I can understand a little. The background is that there was a big trend of cloud native.
The emergence of systems like docker (2013) and Kubernetes (2015) was a big opportunity. It is an epoch-making product that predicts the future of enterprise system development. However, Oracle's movement was sluggish and I could not see any motivation, so in response to this, the community formed Java EE Guardians (2016) and worked on Orcle. And while Microprofile (2016) is coming, Java EE 8 is finally coming out.
A big paradigm shift is likely to occur at the edge of the Java world, but Oracle is slow to move, which is probably the main reason why such a dilemma has triggered community activities and led to the birth of Jakarta EE. ..
Java EE has been upgraded with versions 5 (2006), 6 (2009), 7 (2013), and finally Java EE 8 (2017). Java EE has achieved great results by advocating ease of development, but in addition to the previous versions, EE 8 has improved JSF and CDI, JPA java 8 support, HTTP 2 support, and security API. It ended up with small changes such as additions. The addition of MVC was also postponed, but it seems that he dared to avoid major changes in anticipation of the transfer to the Eclipse Foundation. After being transferred to the Eclipse Foundation, the migration work was so huge that it was difficult to release the next version, but Jakarta EE 8 was finally released in 2019. However, no new features have been added, and it is positioned as the Jakarta version of Java EE 8. The next EE 9 was December last year, as we had to put an end to our rights relationship with Oracle to add functionality. This area is not only due to the corona wreck, but I think Oracle has been too obsessed with its rights. However, since it is a for-profit company, it may have been unavoidable.
Functionally, it is no different from Jakarta EE 8. So, three years after Java EE 8 in 2017, almost nothing has changed. Really? No, the libraries starting with Java x. (All Java EE libraries) are gone and replaced by the libraries starting with Jakarta. This is a big change. jakarta EE 9 is a version made for this.
Oracle didn't approve the revision of the javax library, so at a minimum, it had to be renamed to add new features. However, as you can easily understand, renaming the library will make it incompatible with past products. Under Jakarta EE9 dependencies, Java EE as well as Jakarta EE 8 products cannot be compiled. The impact extends to third-party middleware products such as PrimeFaces and OmniFaces, which can only be used with Jakarta EE 9 (as of January 2021, PrimeFaces remains unsupported). Products that use third-party products also need to be watched in that direction.
With such a large impact and widespread use, the Jakarta EE 9 was developed as the starting point for the new Jakarta EE. So the rebound of Jakarta EE, which regains the lost years, is about to begin. In fact, the enthusiasm of the community has been considerable, and I hope that Jakarta EE 10, which will be released this year, will start a raging march (?).
It is a common sense that it is moving toward microservices. But don't be surprised to see and hear the various jargon that is currently flooding the Java world. It's still a developing jungle, but it should eventually be commoditized into a clean system. Otherwise, it cannot be widely used.
The basic idea is simple. It means dividing the system into small services and putting them together into a large service. Therefore, Jakarta REST (RESTful Web Service) will be the basic unit of development. Jakarta REST doesn't have a user interface, so it's not possible to create something like a JSF application. The user interface can be made of anything. Of course, there is a client API, so you can also create it in Java. You can make it with JSF, and when the MVC system comes in with the time version, it will be one of the big options.
The big difference from the past is the ease of maintenance. The range of defense of one service is small, and the roles are clearly divided. So when you try to revise, you don't get lost in the code maze of what to do. Also, usability is a part related to the UI, but since each is independent, it can be remade anyway. You can even rewrite it in another language.
It's full of good things, but the only difficult thing is the coordination between services, which is included in the microprofile. This part is currently in progress and is developing steadily. Also recently, a community group has been set up to discuss integration into Jakarta EE. I think the next phase will begin when the results are released.
Recommended Posts