days
-1
-2
hours
0
-6
minutes
-2
-7
seconds
-5
-3
search
Java EE fact-checking with Java EE Guardian Anatole Tresch

Java EE Guardians speak bluntly: “I would sympathize with continued development of Java EE within the ASF”

Hartmut Schlosser
Java EE
Anatole Tresch

Discussions about Java EE‘s future persist. We asked Anatole Tresch, JSR 354 Spec Lead (Java Money & Currency) and PPMC member, to interpret the current situation.

Update: Java EE Guardians’ official website and a petition titled Tell Oracle to Move Forward Java EE as a Critical Part of the Global IT Industry were recently launched. In the petition Oracle is asked to clearly specify how they intend to represent the interests of Java, Java EE and server-side developer ecosystems. The three demands are:

  • Clarify how it intends to preserve the best interests of the Java, Java EE and servers-side computing ecosystems.
  • Commit to delivering Java EE 8 in time with a reasonable feature set that satisfies the needs of the community and the industry.
  • Effectively cooperate with the community and other vendors to either accept contributions or transfer ownership of Java EE 8 work.

Whoever co-signs the petition automatically sends it to Oracle decision-makers Larry Ellison, Safra Catz, Mark Hurd, Thomas Kurian, Inderjeet Singh and Anil Gaur. Oracle has not yet responded to the petition.

But now back to our interview with Anatole Tresch, who, as head of the Java EE JSR 354 and PPMC member at the Apache Software Foundation, undertakes an interesting comparison between JCP and ASF.

“It‘s difficult for me to imagine a blossoming future for Java EE.“

JAXenter: How would you describe the actual state of Java EE 8?

I would describe the current state as quite disillusioning.

Anatole Tresch: I would describe the current state as quite disillusioning. Considering for how long Java EE 8 has already been running and how little output is currently tangible, or in what state some JSRs are, it‘s difficult for me to imagine a blossoming future for Java EE. In addition, classical functions of the Java EE ecosystem were moved into infrastructure due to the high level of automatization (Docker container, orchestration, automatic failover, software defined networking, distributed and resilient storage backends). And with server-sided Linux on one hand and HTTP/REST as communication mechanisms (followers of Microsoft‘s server technologies may forgive me) on the other, the „Write Once, Run Everywhere“ principle of Java also loses importance.

Many in and around the Java environment may be frightened by that, but in the end I also hope for positive effects, since the way I see it, Java mustn‘t be an island and the Java community would be well-advised to think about how and in what form it will respond to these changes and developments. Although backwards compatibility and stability of the Java EE platform also yield great benefits for companies, there is also much ballast.

Conclusion: The actual status of Java EE 8 is, in my opinion, quite critical, but I hope that the momentum within the community also leads to finding new ways and solutions to still use Java as a strategic component in companies.

JAXenter: Now a group called „Java EE Guardians“ has been formed and their goal is to push Java EE ahead. What activities could help accomplish that?

Anatole Tresch: That‘s a rather difficult question to which I still have no clear answer. Generally, I think we must have many conversations, especially with our partners at Oracle and other active companies in the Java EE environment. On the one hand, we have to underline the importance and distribution of Java EE as far as companies are concerned, but on the other, we also have to demonstrate why it‘s worthwhile to continue investing in Java EE. An opening or displacement of the specification sovereignty away from JCP should, in the meantime, also be addressed, as this would give valuable incentives for innovation. Both the Linux Foundation and the Apache Foundation clearly show that really complex and challenging problems can hardly be overcome by a single or a few companies alone.

JAXenter: Why did you choose to participate in the Java EE Guardians?

Anatole Tresch: I‘ve dealt a lot with Java solutions in enterprise environments in the past few years and, to this day, many companies still use Java EE as a strategic platform. But the acceptance and credibility of Java EE crumbles. For companies however, a stable basis for decisions (regarding their investments) is very important. Turning away from Java EE to completely different technology stacks is challenging not only in a strategic way, but also concerns resource management and know-how, and therefore it is not feasible overnight. Therefore, I think it would be best to help Java EE renew its vigor in order to address those pressing issues and needs.

JAXenter: Do you think it would be beneficial if Java EE was entirely developed by the community?

The technical exchange within the ASF is quite comparable to what I’ve experienced at JCP.

Anatole Tresch: Being an active Apache committer, I‘m naturally a little biased. But a major strength of the Apache Foundation is indisputably that it‘s not possible for companies to unilaterally influence projects. Community and consensus are, in a way, a fix built-in. Now, when I look at the influence of Oracle on Java EE, I would sympathize with the continued development of Java EE in the ASF.

And also from a business point of view, the open source community gained significant acceptance in recent years and a broader support would certainly recover some innovative energy and confidence. The technical exchange within the ASF is also very intense and quite comparable to what I’ve experienced at JCP. But all this will only work with the support of Oracle, so I‘m excited to see what happens at the next JavaOne in September.

JAXenter: What technological advancements should, in your opinion, be implemented in Java EE?

Anatole Tresch: For me, modularization would certainly play a central part. CDI, with its flexibility, thickness and the announced 2.0 support for Java EE, would in my opinion be a central JSR in a future version. All other JSRs, and therefore EJBs as well should thereby build on CDI. This would also reduce the unfortunate separation of Java SE and EE, as well as the complexity of Java EE in many use cases through approach uniformity.

The common binding of the transaction context is to be set aside here and to be replaced with a more flexible and contemporary transaction and execution management. Transactions can thus be used exactly where it makes sense to use them and could be specified as a separate concern. @Transactional was one of the first steps in this direction, but it didn‘t go far enough. And especially the EJB specification is, given its size, complexity and interweaving with the transactional context, I think, anything but lightweight.

I generally prefer explicit, flexible and service-oriented models, so that applications can be executed preferably without external configuration of administrative resources (as currently being considered in the present Java EE Security JSR). This made the server interchangeable, so it could revive the competition. It would also be important to define Class Loading or at least the visibility of certain resources, to further increase the application portability. And then there is, of course, a consistent configuration mechanism, as we proposed with Apache Tamaya.

Apart from the aforementioned Security JSR, mainly CDI 2.0 and JSR,  we should also consider the currently running JSRs. As far as the latter is concerned, progress is unfortunately very modest.

JAXenter: Thank you very much!

 

200-anatole-treschA​natole Tresch studied business informatics and was then several years active as Managing Partner and Advisor. In recent years, Anatole worked as a technical architect and coordinator at Credit Suisse. He is currently working as a Principal Consultant for Trivadis AG, as Spec Lead of JSR 354 (Java Money & Currency) and PPMC member of Apache Tamaya. Twitter: @atsticks

Author
Hartmut Schlosser
Hartmut Schlosser is an editor for JAXenter and a specialist in Java Enterprise-Technologies, Eclipse & ALM, Android and Business Technology. Before working at S&S Media he studied Computer Science, Music, Anthropology and French Philology.

Leave a Reply

Be the First to Comment!

avatar
400
  Subscribe  
Notify of