Pavel, please introduce yourself
My name is Pavel Pscheidl and my role can be best recognized by “full stack developer”. I live and work as a Java EE developer. Recently, I’ve started Ph.D. studies at Faculty of Informatics, University of Hradec Kralove. Personally, I’m interested in automation systems used for decision support in daily life. Home automation and healthcare systems are my current focus. I’m also a passionate user of Mozilla’s Rust programming language.
What are you building with Java EE?
Commercially, my last allocation was at Zentity, where we built mobile banking backend systems, where all the business logic lies. Zentity’s main customers are big european banks and telecommunication providers. Our backend systems must integrate into existing bank environment, provide the necessary security layer, service orchestration, caching or load balancing. I used Java EE for these projects of course.
However, there is also plenty of space for Java EE at the University. First, Java EE is taught there very well and many things are explained to students - from basic understanding of application servers and the principle behind servlets to advanced stuff. It has it’s space in research projects as well. Home automation systems and Internet of Things projects are current projects with Java EE involved. We also have internal systems based on Java EE. Lately, we’re building lots of microservices with “very fat” business logic for home automation. JAX-RS is clear choice here.
There are also lots of other projects, both commercial or internal projects at the university. It is fair to say that I use Java EE 7 for a long time. We’ve flawlessly migrated older projects to Java EE 7 containers long time ago.
Can you share with us some geeky numbers like e.g. TX per seconds, heap sizes etc -- whatever Java EE devs might find interesting.
I’ve spent quite some time measuring the performance of REST APIs on my projects. The banking systems we built were tested to handle 10,000 requests per second. Benchmarked with both Resteasy and Jersey as JAX-RS implementation. It could actually be achieved with WildFly and it’s load balancing capabilities pretty easily and cheaply - I found that fact interesting. It depends how the request looks like of course. I can not discuss details publicly, but I can tell that one request could allocate up to 5 additional threads from the thread pool managed by the application server as it waited for other services and the whole request could last for up to a second. Typically between 150-200 milliseconds. Java itself and of course Java EE always proved to be very fast and easily scalable here. Under usual load, the heap usage is always under 1 GB per node and I’ve never seen it exceeding 2 GB on common projects. I can’t actually offer big, sensational numbers. And that is what I enjoy probably the most. Having a virtual machine with 8 threads and 2 GB of memory spawned in no time and letting it handle thousands of clients for several years without problems is what impresses me. Just yesterday, I was forced to restart WildFly 8 after a year and seven months of uptime due to CentOS upgrade.
Are you happy with Java EE so far? Is Java EE productive?
Very happy. Ease of development is the main reason. Everything is kind-of prepared and standard ways of doing things make sense, for example data sources and JNDI. Customers are happy with application servers, where everything can be set up easily via web interface in detail. There is no configuration hell and JAR hell. Everything required is already present at the application server. I commonly use few additional CDI extensions in every project that further improve simplicity. There are many, but I’d like to point out Apache Deltaspike. We even developed set of custom CDI extensions that are very specific for given domain - they do non-trivial work for developers and newcomers are not even aware of them. Overall, I like how Java EE reduces application’s complexity to bare minimum. Projects in Java EE 7 are highly domain oriented - this means there is minimum amount of configuration and new developers orient easily. In enterprise environment, this is actually a big deal.
Which tools or IDEs are you using?
Any Linux-like OS is what I strongly prefer - a proper terminal and a set of basic tools is a must (ab, curl, scp, ssh…). I use IntelliJ Idea for some Java EE projects based on Gradle. However, NetBeans is my strong preference. So for the majority of time, I use NetBeans + Maven rather than IntelliJ. When NetBeans comes with decent support for Java EE projects built with Gradle, I will probably stop using IntelliJ completely. Besides Java IDE, I always have Sublime Text 3 and Postman opened. I should also mention Enunciate - a tool to generate JAX-RS REST API documentation. That is pretty much everything I commonly need.
You migrated to Java EE 7 and WildFly. Are you happy with the decision? What was the outcome?
Yes, I am extremely happy with the decision. I migrated to pure Java EE 7 projects mainly because I started to seek an alternative. I developed projects using many technologies and frameworks. Some projects were in Ruby and I was even using Python + Django for websites. Mainly, I was using Spring. I was taught to use it by everyone “since Kindergarten”. I still do not get it - heavy marketing, fancy words, but the reality is different and ugly with many custom fixes and lots of custom code not oriented on the problem domain. I am awared that this is a controversial topic, but after the years I just feel this way. I soon dropped all of the previously mentioned and focused only on Java EE 6, later Java EE 7. And life became easier - which is exactly what I wanted. So the overall outcome of switching to pure Java EE 7 is easy living :) There are many open standards which reflect real world requirements in Java EE. Such set of open standards is then implemented and usually undergoes a process of testing, improving and bug fixing - bug free software is a myth. An application server represents a well tried, periodically fixed set of such libraries used by many. And when it is used and developed by many, it is usually more trouble free then solutions wired together individually. Wiring everything together on our own always ended up in troubles. The problem repeated across companies and developers. And I don't want that back. Projects are now tidy and domain oriented, no configuration hell, no dependency hell. Java EE has CDI, which I personally call “Java EE-core”. Majority of things in Java EE relies on Dependency Injection and design patterns built around/on top of it. And CDI is extremely well designed and feature-complete. I think it is the top reason why working with Java EE is so easy and understandable. With extensions, it is a pleasure to work with. Even Spring Data is now available as a CDI extension. But I’ve tried it and happily returned to Deltaspike Data. A real benefit is that projects are also actually transferable from one AS to another with little effort. The certification process helps here. In real world, the choice of application server proved to be of great importance. It doesn’t matter that much for the application itself, but the environment the application is deployed into matters. Servers often come with some additional functionality. For example, WildFly has great load balancing capabilities. I’ve used that several times and it was capable of literally saving client’s ass - for free. I also started to use Payara for both production and development not so long ago. Right now, I am exploring newest WebLogic, just to discover new possibilities. So I’m not a RedHat-centric person, but I found Wildfly/JBoss to be well documented and easy to understand for both developers and administrators. What I don’t like is the presence of Hibernate. EclipseLink is my strong preference. Hibernate sometimes requires special treatment when used as JPA implementation (e.g. LazyInitializationException). I have definitely faced some bugs and troubles, especially in the beginning. But everything was resolved quite fast and it was AN EXCEPTION, NOT A RULE - and this is what matters to me.
How big is your WAR?
Smallest ones are hundreds of kilobytes. Projects under 1 Megabyte are usually REST-based services connected to some kind of relational database. More complex applications are about 1-4 Megabytes with all libraries included. When the application is a website, the WAR gets bigger - all the graphics and styles take some place. My recent web projects were slightly above 5 MB. I took a quick look to my repositories and the largest project I could found is slightly over 7 MB. And that includes Primefaces themes, which we’ve also used on some projects.
Can you briefly describe the architecture of your application?
To my surprise, I do service-oriented architecture more than ever. In these cases, the complete system usually consists of < 5 WARs connected with REST interface (JAX-RS). There is no service hell, usually there is only the main application carrying all the bussiness logic and other applications oriented onto a different domain, for example security. Horizontal scaling can than be done independently. I am heavily influenced by domain-oriented design, so the components themselves are organized and named according to the problem domain. Projects created with domain-oriented design in mind proved to be much more easier to understand to other developers. For web-based applications, one WAR with JavaServer Faces is the golden standard. For projects based on AngularJS and simillar frameworks, a REST API is created (again using JAX-RS).
How important are standards for you? Does your application depend on application server specific APIs?
Standards are very important. But not everything can (and probably should ?) be standardized, I think... It is probably better to use new things in a form of external library or let’s say a CDI extension. If possible. As I stated earlier, standards represent a collective effor. And Java EE has very capable and enthusiastic people in it’s community. My applications do not use any application server specific APIs. Sometimes, they use specific APIs for databases, where I completely drop JPA and use for example Morphia for MongoDB, integrated via a simple producer.
Which Java EE APIs are you using in your products?
Many. JAX-RS, CDI, JPA, EJB, JSF and JAX-WS are the most commonly used ones. Also managed thread pool is accessed via Java EE API. Rarely, JMS is used.
Take a look at the Java EE 8 APIs. Which of the APIs are most interesting / important to you?
I am definitely most interested in JSR 372: JSF 2.3, JSR 370: JAX-RS 2.1 and JSR 375: Java EE Security API. Java EE has some security modules in a form of CDI extension and securing a JSF-based web projects is a piece of cake, but I believe the time has come for a standardized solution.
Can you share any resources (blogs, etc feel free to promote yourself) with us?
The best resource is currently my personal blog / website. There are few other resources as well: Faculty of Informatics, UHK, or our Home Automation System. I also have a personal GIT repository. More projects there are actually not a big secret, but hidden. My GitHub will be growing soon I hope, because we’ve decided to license all our university projects under GNU GPL and make them publicly available.
Real World Java EE Workshops [Airport Munich]>