Java EE 8 will see improved, easier-to-build architecture, better servlet support, and non-blocking IO, though breaking down monoliths will still be a problem.
Today, we’d like to talk about one of the hottest topics among all Java admirers – the upcoming release of Java EE 8. Within the SouJava initiative [Java EE 8 – The Next Frontier] , Jelastic CEO and co-founder Ruslan Synytsky gave an interview to Elder Moraes sharing his thoughts regarding the adoption of Java EE 8, what significant possibilities it may provide, and what bottlenecks you need to be aware of while working with Java.
Watch the full video interview below, and/or check out the transcript below it.
Good news: Container and microservice adoption are growing among Java developers. So we see many more developers looking for microservices, immutable applications, and more scalable solutions.
However, there’s an issue with adoption, because as we know, at the beginning, Java was not designed for these kinds of things. And in some cases, it is really hard to migrate existing Java applications to containers, or to redesign them to microservices. And our mission is to help people to figure out what is the best way to do it.
I hear such advice from some experts: Don’ t rewrite applications, don’t migrate applications – just make new applications, write cloud-native applications. And, of course, the best way of moving to the cloud is to start writing for the cloud. However, it’s not an easy task for many enterprises. They cannot do it in the short term. Second, it’s very expensive for small and medium-size businesses. Our goal is to help people to figure out which is the best way: To redesign applications, or to write new ones.
And we do a lot of research related to the decomposition of legacy applications to full Java EE servers and migrating them to containers and to the cloud. So we have really good, successful use cases, but still, it’s not obvious today how to do it – there’s no clear guide on how to make it happen. So I hope altogether we can build some joint knowledge and share this experience among Java developers and our community.
I’ve heard in the past that Java is dying, but that should not happen. We put all our efforts to help end customers believe in Java and continue to use Java, specifically in the cloud. As you know, the cloud was born from the hosting industry, and if you analyze it, there’ re not so many hosting providers or cloud service providers that are Java-focused. The majority was focused on PHP and other scripting languages. We saw many startups trying to solve this issue, but they were not able to solve the core problem, and they don’ t exist anymore.
However, Java continues to evolve, and I believe it can be even better if we improve the speed of evolution and start releasing much more often – maybe with smaller parts but giving new features back to the community faster. I hope this movement to a GitHub repository will help to speed up development. There are millions of Java GitHub users already, and this helps them to be closer to the source code, to subscribe to the updates, to contribute back something new. And I’ m sure this will speed up the evolution of Java.
However, we need to understand why Spring Boot got such big traction. And we need to understand the core problem. From my understanding, the problem is the complexity of deployment, complexity of scaling, clustering, and high availability. In Java EE, it’s difficult to figure out how the deployment process works. In many application servers, it is a black box. It’s very hard to control and customize. It’s even hard to find details about specifics – I mean how deployment works.
Recently, I started to collect this kind of information to build some guide for people and to share it with the community. And it’s really hard to find the details. I have to ask experts – how do application servers behave when you redeploy the application, or when redeployment fails, and so on?
With Spring Boot, this problem doesn’ t exist because this built-in deployment solution doesn’ t exist at all. You have to manage it on your own. Of course, it brings much more work to you, but in many cases, it gives you much more control. You can control this process, you can design this process on your own.
To be honest, in Java EE this deployment mechanism was not developed for a long time. I do believe we need to pay attention to this, to simplify this, and to clarify how it works.
Today, people have started to move to standalone servers. They just spin up several standalone servers and they do replication with Hazelcast or a database, then they put a load balancer on top of it. They develop their own clustering, high availability, and deployment to the cluster. It can be adjusted in Java EE, and it will definitely improve adoption and trust. Because even with Spring and microservices, you need to have some platforms that manage all the stuff, like an orchestration platform that does container management, service discovery, and so on. In the past, full Java EE stacks had something similar already inside. They have a discovery mechanism, they have the high availability inside. It was just not clear how it worked. I believe this is the core problem and we need to solve this at the beginning.
