“There is always an alternative in IT” - Dmitry Alexandrov (T-Systems) about Java EE / EE4J

Recently, there has been a lot of hype around Java EE : first, the release of the eighth version, then the news about the transition to the Eclipse Foundation and the renaming. But many news discussions boil down to what people think about the new EE4J name. We decided not to limit ourselves to this and ask Dmitry Alexandrov (the leading expert programmer at T-Systems): he deals with Java EE in his work, and is active in the EE community, and gives EE reports at conferences. So we asked him questions both from the point of view of “applicability in your work,” and from the point of view of “what the community as a whole thinks,” and at the same time about the reports: he will be speaking at Joker tomorrow.



- To what extent is Java EE 8 a large-scale and long-awaited event for the community, and what of its innovations causes the greatest response?



- I generally agree with the official Oracle infographic below:

')





Now there is a huge demand for everything related to REST, HTTP / 2 and JSON, and EE here follows trends. The need for JSON-B was obvious, and I think everyone is very excited about her appearance. This will greatly facilitate the entire development. Much attention is paid to asynchrony / reactivity, plus, of course, security. Consideration of all changes will draw on the whole article, but, of course, the release of Java EE 8 was very much expected. Now it is an absolutely modern platform that provides all the infrastructure for modern enterprise development.



- What do you feel about your own practical work? Is there something in the G8 that is clearly useful in T-Systems projects? And how soon do you feel the changes?



- For some new projects, we will definitely need to use the MicroProfile + JSON-B stack, and, possibly, MVC. We have a lot of asynchronous and event-s, and here EE 8 will make our life much easier.



And about time - in such large players as T-Systems, such changes are not immediately felt. We have a lot of projects that are several years old, and the transition to the latest platforms does not always happen instantly. Often this is a fairly lengthy process associated with a lot of pre-testing and sandboxing. Stability and safety above all.



Nevertheless, we always strive to apply the latest releases, but without breaking the head, "because it is fashionable."



- How is the EE transition in Eclipse estimated in the community? Approving remarks are mostly noticeable, but there are also skeptical ones like “Oracle gets rid of ballast” - what do they think in the community and you personally?



- Of course, this is a cosmic scale event. Imagine - a platform of 25 years was under the control of just one corporation, and here this huge part of it breaks away from it and goes into independent navigation. ITS is so massively distributed and the community is so great that what happened is absolutely natural. But I would not call it “getting rid of ballast.” It should only be glad that it has become public domain.



In my humble opinion, this should have happened sooner or later. But I did not expect this to happen so soon, and at the moment I am watching all this with interest.



“Last year, the community complained that under Oracle, the development of EE was slow. But will it now turn out that without the Oracle wing it will not accelerate, and slow down even more, and we will still ask Oracle to return everything back? :)



- Definitely not. I am confident that this event will only spur a more rapid development of this platform for the needs of the industry. Moreover, EE will become even more universal and portable, since the main vendors are interested in this - server developers. Now it will be easier for them to sit down and agree on how to standardize it. MicroProfile is a good example. Several server vendors simply sat down and agreed on how they want to see this subset EE, consulted with the public and implemented. Immediately surfaced all the shortcomings, and the committee promptly responded. For me, this is just great!



- Not everyone knows about MicroProfile. Since you are already sure that it will come in handy in T-Systems - can you let those who have missed describe what the project is all about? And what are the perspectives of MicroProfile now, when they want to move it to EE4J?



- In a nutshell, its appearance is due to the huge popularity of microservices. It is noteworthy that this is absolutely a community initiative. So, sometimes, to raise one REST endpoint, it was necessary to raise the entire EE infrastructure — both persistents, JSF, and so on. You understand, this should not be so. And here are a few vendors of EE-servers gathered and decided: let's throw out all unnecessary and leave only JAX-RS, CDI, JSON-P. This is generally enough to run microservices (although this is still subject to discussion). So it turned out MicroProfile!



The distribution of the servers themselves becomes very compact, and is often packaged in 1 executable jar. The sizes of such fat jar are rarely more than 40 megabytes. I am glad that in the Bulgarian JUG, of which I am a co-leader, we are actively participating in the development of MicroProfile, we have active committers. Moreover, we made the first hands-on lab on this topic, where during the workshop we create a web application consisting of several microservices, each microservice running on its own server from its vendor. And considering that all this is a single standard, everything works together great! Pretty exciting!



By the way, I do not like the name EE4J, but I am sure that this initiative is the place!



- There was a story that Oracle first cut the MVC project from Java EE and the community picked it up as a separate task, and now it is merged back into EE4J. Oracle refused because of “nobody needs it” - but according to your feelings, how relevant and relevant is it? Is there a demand for this in the community and specifically in your work?



- I would say this: MVC is good. It is very good in itself to have an alternative to JSF, because there are many tasks for which JSF is hard and too “standard”. Moreover, this model has proven itself in Spring. So far, judging by the polls and the general noise, the people still have not really accepted it in HER. But, as I said above, we at T-Systems are thinking of applying MVC in one of our projects.



“The Java EE community The Guardians always talk loudly about everything related to EE, but from the side it’s not obvious: is it really a powerful community of like-minded people, or is it really Reza Rahman and a couple more people?



- Reza is definitely one of the pillars of EE. Just recently, I was his co-speaker at one conference, and we were just talking about the future of HER. And the Guardians are not a couple of people. You look at the list of their participants - starting with James Gosling, the creators of EE servers, heaps of JCP experts, and ending with simple “users” of EE. In fact, the Guardians were one of the first to notice the stagnation in IT, began a movement to "debunk" myths about its gravity, and contributed to the evolution of the platform to meet the new needs of the industry.



- To the question of myths. Now there are sentiments “to whom this EE in the heyday of Spring may be needed now”, it turns out to be “unfashionable” - and how does this look from the position of a person working with EE?



- In fact, everything that can be done on EE can be done on Spring. Moreover, Spring even has more “sugar”, so for prototyping or some quick development, it is sometimes preferable. But then you become a “hostage” of this decision. Migrating to something else will be extremely difficult. There is always an alternative in EE, on which server everything will work. Moreover, some EE-vendors offer an absolutely comparable set of "sugar".



But if EE were “unfashionable”, it would not be so common. I have always said: HER - this is all the best that was once invented both inside the platform and on the side. This is the essence of an enterprise that is worthy of being standard.



- At the past Joker, you gave us a report about JBatch from Java EE 7 - do you use it yourself?



- We used it twice, and this saved us a lot of extra effort, since the approach is as standard as possible.



- Why was it asked: although JBatch seems to save a lot of effort, it is very rare to mention it. Why it happens? Do people inertia make bicycles, even when it is no longer required?



- Yes, I myself call JBatch “forgotten API”. But I continue to see how people, as stated above, invent bicycles. Many people consider the task so simple that why even think? Wrote a couple of cycles and in production. And then you yourself know what follows. And when you have to write parallel code, everything becomes as sad as possible. But if the task seems a bit more complicated, then, naturally, it is customary to take something from the HYIP, which often leads to unnecessary difficulties. As for the shortcomings of JBatch, the main one is its uncertainty. It is clear that this is not an ideal tool, but, with a suitable formulation of the problem, it saves a great time. Moreover, knowledge of the presence of such an API will help with the design of the architecture of a particular application.



- Finally, let's take a little bit of the EE topic: at the upcoming Joker, you will have a report on “Java and GPU”, and they rarely talk about this, like JBatch. Is this atypical topic also based on personal experience?



- Have you noticed that I like to talk about all the exotic? I have been fond of GPU as such for several years now, and, yes, I will tell from my personal experience, although examples will be more general. The direct experience of the application was in my previous work, where it was necessary to quickly read a lot of heatmap. And now in our innovation group in T-Systems, we are considering the possibility of using a GPU for our needs, including in the clouds. I do not think that this should be applied massively, since the very "nature" of computing on video cards limits the use of them everywhere.



- Ok, this is not for everyone. But is there a feeling that those who would now benefit from using a GPU with Java now often do not?



- In my opinion, the GPU is now especially appreciated against the backdrop of rapid growth of cryptocurrency and everything associated with the blockchain. Java is very well represented in finance and banking. In fact, it dominates there. But there are many other tasks in this area that fit the class of mass-parallel - ideal for the GPU. Moreover, I am sure that it will be interesting and useful for programmers to be able to communicate with the GPU in principle. Nowadays, in my humble opinion, a developer and an architect simply need the ability to determine how specific a task is parallelized, and on the basis of this implement it on the most appropriate device. Personally, if I see that the task is appropriate, I will naturally try to use the GPU. Moreover, this resource is now increasingly available.



- Thank you, we will wait on Joker for both you and T-Systems.