Removing Bloat With Java EE In Brazil

Heliton, could you please introduce yourself?

Hi Adam, my name is Heliton Filho, I'm an Enterprise Architect with technological expertise in Java EE. I currently hold TOGAF 9, OCMJEA 5 and 6, and SCJP 1.4 certifications, and have been working in the IT field for 22 years and as a Software Architect for the last 12 years. In these years I've led and helped teams design and develop many major systems for some of the largest government agencies, telecom companies, military, banks, and oil companies in the country.

How popular is Java EE in Brazil?

It's very popular, specially among medium to large enterprises who worry about and take seriously issues like maintainability, availability of important decision-making information, reuse of components and services, ease and speed of development, nice looking UI components ready for use, and security. Having worked for many years in the aforementioned companies, I could see first hand how the vast majority of their systems were all backed by Java EE, and how many migration projects are sprouting to convert legacy systems to the Java EE Platform.

You were able to remove a lots of code with Java EE. Please tell us the story.

I've always had a big focus on modularity and maintainability, even back (and specially then) in my C days, so it's always been a big priority for me to write as many systems and modules as I can with as little code as possible, always striving to make it readable and reusable. By applying common sense, experience and design patterns, specially the ones in your green book and in the Clean Code book, we managed to cut, just in my last project, over 50% of the LOC in v1.0 (I got in the project after it had released its first version), most of the fat being in the Model part of the system.

By not using DAOs and having Fat Entities, the code was more lean, concise, understandible, and the objects had more accountability. We were able to use inheritance and interceptors to give entities the CRUD usability they required, and by removing facades and just using BCE in the leanest manner possible, the readability and maintainability were improved in a way that the client's technical team were so impressed by the hard fact statistics in the Sonar dashboard they started to refactor their projects to use these design patterns and gain the leanness and consistency they had seen in ours.

What are the ingredients of an efficient Java EE architecture?

Start small and grow the architecture organically. Always keep in mind the two basic principles, KISS and YAGNI, and focus on the business needs, and not on what you think looks good on a UML diagram or what will impress the client in a presentation but will be a burden for everyone else later along the line (in here I include developers who will use the architecture, operations people who will have to care for the deployments and general infrastructure you designed, and the end user/client who will actually make use of the system).

Java EE is already a great platform with so many features out of the box, so if unless there really isn't an equivalent to something you want to do in that environment you can use, keep it vanilla and your deployment times, your developers' learning curve and cross-framework bugs will all be kept to a minimum and everyone will thank you in the end.

Which Java EE APIs are you using in your project?

Java EE 7, JPA 2.1 (the native handling of stored procedures was a godsend), JSF with PrimeFaces, JAX-RS, JAX-WS, CDI, JAAS.

Which application servers, tools and IDEs are you using?

WildFly 9, the WSO2 platform (IS, DSS, ESB, etc) for SOA and SSO, ThoughtWorks Go for Continuous Integration and Delivery, Sonar, Nexus, Maven, JBehave, PMD, Checkstyle, JUnit, Git, and Netbeans for development, of course ;)

How important is the Java EE standard to you? Is your code dependent on application server specific features?

It's critical, and Java EE's most important feature for me, specially in the latest versions where they're finally removing the AS specific artifacts and really applying a standard for deployment. In a project I worked 3 years ago in a huge government client, the contract required that the projects developed under our architecture, without any modification, be deployable in all the AS they had, which were WebSphere 5 through 8, WebLogic 10 and 11, and JBoss EAP 5 and 6. Back then the architecture used Java EE 6, and it was virtually impossible to comply with what was sold because some of those AS didn't even support Java EE 6, and others (JBoss to be specific) required some customization in the deploy file because of classloader problems with some of the external frameworks used, solved with the creation of the jboss.xml deployment descriptor, so we eventually came to a compromise, which I can tell you some key stakeholders weren't very pleased.

Another big problem was Oracle's decision to cripple the Java EE 6 Maven dependency (already very well discussed in your blog), so we had a huge amount of work keeping the versions up to date and the dependencies sane.

In my latest project we started it with Java EE 7, and it's just been great. The Maven POM is very lean, we've used your archetype as a template for our own and have deployed the JARs to JBoss, Wildfly, WebLogic, all using Continuous Delivery, and without any hiccups or extra server-specific files.

Is Java EE productive? What is your opinion?

It's as productive as you make it to be. I've seen time and time again development teams working with the latest version of a framework but with an outdated knowledge to do so (out of the many horror cases I've seen throughout the years, the worst was one developer, using Java EE 6, actually reading the JSF page from disk into memory using IO and replacing all the variables "on the fly" with String.replace(), then using response.getOutputStream().print() to send the page to the browser). In these cases, the role of the architect as a mentor is very important, otherwise all the work you did creating a lean and efficient architecture can go down the drain when people don't know how to use the tools you've given them. I personally always hold workshops both in teams I work with and with the client's technical teams to level the knowledge in areas like latest design patters (like yours), best practices, clean code, new features in Java EE, etc. It's only when the technical team is as sharp as it can be that Java EE really shines and sets it apart from other frameworks and platforms.

Is you company hiring Java EE developers?

Yes, to some extent. Brazil right now is in a major economical and political crisis, so hiring is very limited, but yes, it's investing in Java EE projects and workers.

Any links you would like to share with us?

You can find out more about me on my LinkedIn profile at I always welcome healthy discussions about architecture in all its forms, best practices, new tools and frameworks, and just technology in general.

I'd like to thank you, Adam, for this amazing opportunity, I've been following your blog for around 8 years now, and your contributions to the Java community, be it in the form of blog posts, seminars, youtube videos or in the JCP and JSRs have been an inspiration and a beacon for those of us seeking to improve our skill set.

Heliton thank you for the interview and keep going with the code annihilation and Java EE! :-)


> By not using DAOs and having Fat Entities, the code was more lean, concise, understandible, and the objects had more accountability. We were able to use inheritance and interceptors to give entities the CRUD usability they required

Could you explain that? Would this just duplicate all of your entities? And how would interceptors are used to give the entities the CRUD operability?

Posted by Ich on February 22, 2016 at 06:49 PM CET #

Hi Ich,

Why would it duplicate my entities? Could you elaborate on that? Anyway, the answer is no, it didn't at all.

As for the other questions, check out the Fat Entity design pattern from Adam's Green Book (Real World Java EE Patterns), it describes how to pass the EntityManager from the Boundary to the entities so they can do CRUD functions.

What we did in our case was to have an abstract class (AbstractCRUD) that would have basic CRUD operations (find, insert, delete, update) with generic exception handling and the received EntityManager and have the entities extend them. Therefore the entities would only handle more business related requests for data (eg. findClientsFromBrazil), decoupling the physical data knowledge from the Boundaries and Controls.

Hope this helps :)

Posted by Heliton on March 06, 2016 at 09:07 PM CET #

Post a Comment:
  • HTML Syntax: NOT allowed
...the last 150 posts
...the last 10 comments