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

There has been a lot of buzz around Java EE lately : first the eighth version, then the news of the transition to the Eclipse Foundation and the renaming. But many news discussions come down to what people think of the new name EE4J. We decided not to limit ourselves to this and ask Dmitry Alexandrov (a leading expert programmer at T-Systems): he deals with Java EE in his work, and is active in the EE community, and makes 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 speak at Joker with us tomorrow .

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

- In general, I agree with the official Oracle infographic below:



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

- And what do you feel in connection with 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 in your work?

- For some new projects, we will definitely need to use the MicroProfile + JSON-B stack, and, possibly, MVC. We have a lot of asynchrony and events, and here ITS 8 will greatly simplify our lives.

And about time - in such large players as T-Systems, such changes are not immediately felt. We have many projects that are several years old, and the transition to the latest platforms does not always happen instantly. Often this is a rather lengthy process, associated with many preliminary checks and works in the sandbox. Stability and safety above all.

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

- How is the community evaluating the transition of EE to Eclipse? Mostly appreciative remarks are visible, but there are also skeptics like “Oracle gets rid of ballast” - what do the community and you think?

- Of course, this is an event of a cosmic scale. Imagine - the platform has been controlled by only one corporation for 25 years, and then this huge part of it breaks away from it and goes into independent navigation. ITS is so widespread and the community is so large that what happened is absolutely natural. But I would not call it "getting rid of ballast." Here we should only be glad that it has become the public domain.

In my humble opinion, this had to happen 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 the management of Oracle, the development of EE was slow. But will it not now turn out that without the Oracle wing it will not accelerate, but slow down even more, and we will still ask Oracle to return everything back? :)

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

- About MicroProfile not everyone knows how to. Since you are already sure that it will come in handy at T-Systems - can you describe for the missed ones what the project is in general? And what are the prospects for MicroProfile now that 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 an absolutely community initiative. So, sometimes, in order to raise one REST endpoint, it was necessary to raise the entire EE infrastructure - both persistence, and JSF, etc. You understand, this should not be. And here are a few vendors of EE servers gathered and decided: let's throw out all the excess and leave only JAX-RS, CDI, JSON-P. This is generally enough to run microservices (although this is still subject to discussion). And so it turned out MicroProfile!

At the same time, server distributions themselves become very compact, and are often packed in 1 executable jar. The sizes of such fat jars are rarely more than 40 megabytes. I am glad that in the Bulgarian JUG, of which I am a co-leader, we are actively involved 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, with each microservice running on its server from its own vendor. And considering that all this is a single standard, everything works together wonderfully! Pretty fun!

By the way, I don’t like the name EE4J, but I’m sure that this initiative is the place!

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

- I would say this: MVC is good. Having an alternative to JSF in itself is very good, 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 her in EE. But, as I said above, we at T-Systems are thinking of applying MVC in one of our projects.

- The Java EE Guardians community always speaks loudly about everything related to EE, but it’s not obvious from the outside: 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 a conference, and we were just talking about her future. And the Guardians are far from a couple of people. You take a look at the list of participants - starting with James Gosling, creators of EE servers, a bunch of JCP experts, and ending with simple "users" of EE. In fact, the Guardians were among the first to pay attention to the stagnation in EE, started a movement to “debunk” myths about its severity, and contributed to the evolution of the platform to meet the new needs of the industry.

- To the question of myths. Now there is a mood “who in general may need this EE right now at the peak of Spring”, it turns out to be “unfashionable” - but how does it look from the perspective of a person working with EE?

- In fact, everything that can be done on EE can be done on Spring. Moreover, Spring has even more “sugar”, so for prototyping or some kind of quick development, sometimes it is preferable. But then you become a "hostage" of this decision. Migrating to something else will become extremely difficult. In EE there is always an alternative 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 always said: EE is all the best that was once invented both inside the platform and on the side. This is the essence of an enterprise that deserves to be the standard.

- At the Joker past, you made a talk 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, its references can be met very rarely. Why it happens? Do inertia people make bicycles even when it is no longer needed?

- Yes, I myself call JBatch a “forgotten API”. But I continue to see how people, as mentioned above, invent bicycles. Many people find the task so simple that why think at all? 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 little more complicated, then, of course, it is customary to take something from a hype one, which often leads to unnecessary difficulties. As for the flaws of JBatch, the main one is its obscurity. It is clear that this is not an ideal tool, but, with a suitable formulation of the problem, it saves time great. Moreover, knowledge of the availability of such an API will help with the architecture design of a particular application.

- Finally, let's move away from the EE topic a bit: at the upcoming Joker you will havethe report "Java and GPU", and such as JBatch is rarely talked about. Is this atypical subject based on personal experience too?

- Have you noticed that I like to talk about all kinds of exotic? I have been fond of GPUs as such for several years, and, yes, I will tell them based on personal experience, although the examples will be more general. Direct experience with the application was in my previous work, where it was necessary to quickly count a lot of heatmaps. And now in our innovation group at T-Systems we are considering the possibility of using GPUs for our needs, including in the clouds. I don’t think that this should be applied in large quantities, since the very nature of computing on video cards limits the scope of their application everywhere.

- Okay, this is not for everyone. But is there a feeling that those who would now be useful to use the GPU with Java now often do not?

- In my opinion, the GPU is now especially valued against the backdrop of the rapid growth of cryptocurrencies and everything that is connected 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 - ideally suited 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, the developer and the architect just need the ability to determine how much a particular task is being parallelized, and based on this, implement it on the most suitable device. Personally, if I see that the task is suitable, of course, I will try to apply the GPU. Moreover, this resource is now more and more accessible.

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