Giovani Salvador's Blog

Java Architectural Knowledge for Job Interviews. Are we prepared?

I already interviewed lots of Java developers during hiring activities. As part of the interview, besides other things, I like to understand if the person being interviewed has understanding of the applications he/she develops as a whole, I mean, not only understands business requirements but also understands the entire architecture of the application and, most important, why that specific architecture is in place for that application and its specific needs.

So below a typical dialog between a candidate (C) and I regarding architecture of a Java EE application.

- So, could you please describe, from your perspective, what should be a typical Java EE architecture for, let's say, a medium-size web-based application?
C - Of course. Well, typically I will have in place a lightweight container like Spring and persistence mechanism like Hibernate. Spring will do everything for me.
- Alright, let me be more specific, I believe my question was not well-built. Imagine if the end user is about to submit a form data. What will be the flow that data would take to be persisted in database? Describe to me the building blocks, all the path of the data, which objects will apply business rules, which objects will handle web requests, etc. Feel free to draw this architecture if you think it is better for you.
C - Not necessary. Well, I would put Spring MVC in place to handle all the requests. For persistence, Spring DAO with Hibernate support.
- hum, I think you haven't got the point. Forget about Spring. forget about EJBs. Forget about lightweight or heavyweight containers. Forget about Hibernate. Imagine you don't have these technologies to assist you. You have to propose the architecture without using any specific product. What would you do? Remember, no products. Just give me building blocks.
C - .....
C - .....
C - In the presentation layer an object will take all data submitted and...
- Which object?
C - hum...... maybe a Servlet object or .....
- Or a managed bean, something like this? Ok, go on. Once data is retrieved from the UI, what will happen?
C - ... ok, data will be sent to an object and this object will perform business rules and after that data will be persisted.
- Could you please be more specific? Do you have in mind any design pattern that could assist you for this architecture? What would be the structure for the domain layer? And Persistence layer?
C - ...
C - Man, I would work with Spring, it does all those things for me.
- Alright, that's good for me. Thank you.

Let me say somethings about this dialog.
First: I don't have any problems with Spring. In one of my posts I said that I never used it because I never had to. We need to find solutions for our problems and not create problems for given solutions. By the way, comments in that post were great.

Second: The candidate never asked how many transactions per minute, hour, etc, how many concurrent users, if it is a critical application. That dictates the architecture. We can't have silver bullet and it seems today most of the "architects" have silver bullets. And, even worst, relying on specific products. Also, based on the non-functional requirements of the application we could see if clustering would be needed. But no, no question about those kinds of things at all.

Third: The lack of knowledge on some typical design patterns is also something to take into account. Façade? DAO? Value Objects? Application Controller? Even if we don't need all of them, candidates should be prepared to use them when necessary.

I know it is hard in an job interview to remember all those things. And I really don't have answers for all problems, most of the times we just can't propose an architecture whitout digging deeper in the details, in the business requirements and having lots of discussions with peers and even business team.
But as developers and architects we can't be relying on specific products, we need to be able to understand architecture as a whole and what are the options we have to better propose a scalable architecture and build a solid system.

Here a few basic references about all this stuff.

Java BluePrints - Here some good stuff for JAva Enterprise Applications.
Java EE Design Patterns: Core J2EE patterns are here also
Patterns of Enterprise Application Architecture, from Martin Fowler.
Head First Design Patterns.

There are lots of other good books and articles. Please, feel free to comment here adding more references.
Also, what do you think would be the basic understanding developers should have nowadays? Any other specific skill?

Refactoring for Performance

I was working on a kind of Outlook entirely based on the web and written 100% in Java. I was part of a team responsible for maintaining that application for thousands of users and performance was a critical piece. Actually, still is a critical piece because the application still exists and it is there for almost ten years.
I joined the team after the application has been released and being used for about 20,000. At that time, the team was not fully aware of helpful frameworks or design patterns that could help themselves to build a reliable, scalable software. Application was performing well but one of the parts of the application (a listing) was taking too long to process. Some users were complaining on that piece and I joined to help team specially on that part of the application.
First thing I decided to do was to put in place some tool to help us understand what was going on. At that time my IDE was Jbuilder Enterprise Edition and I had a license of Optimizeit. By plugging in it to the application I quickly noticed that building and access to lots of HashMaps instances were the culprit.
Then I had to understand the application's architecture:
The data layer was responsible for processing SQL statements sent to it, create HashMap instances for each record found and add each instance to a collection. Each column of the records found turned to a pair of column name and value.

The problem was that the application didn't have in place Transfer Objects or Value Objects. It was relying on maps and the application was facing performance problems on building those maps and suffering when accessing get methods of those maps, specially in those days where the load was so huge. That's what Optimizeit was telling me.

So I decided to make a small refactoring in my local environment after assessing the application with Optimizeit. I switched from maps to Transfer Objects in all layers of that piece of the application. Instead of making maps and collection of maps I created Transfer Objects and made them being accessed by the listing page. The Facade was responsible for returning the collection of Transfer Objects instead of a collection of maps.

When I ran Optimizeit again I noticed a gain of 20% in performance. After showing the results to the team we decided to release to production after some tests in Development Environment.
One day later I received a call from one of the users who originally complained about the performance:

- User: Hey, have you guys modified anything in the application?
- Why Sir?
- User: Because the listing is performing much better now.
- Actually, we did sir. We did a small modification on that piece.
- User: Alright, I will notify other users about that. Thanks for the work performed.

You guys may be surprised with this. Today, almost all applications rely on Transfer Objects, not on hashmaps. But at that time, with the knowledge of the former team, that's what was being used. The bottom line here is that small modifications may affect user experience. We don't need to make big refactorings to achieve that. Simple is better.
And you guys know the value of an user calling you to congratulate you. This is the most important piece.
Also, to put in place profiling tools like the one I had used is also key for the success of the project. You guys may be surprised with lots of things such tools may reveal about your code.

but I would like to know from you:
Has any of you some example on small refactorings that made the difference? Simple modifications that helped applications to improve performance. Please, share over here some real world facts about refactoring.

Java and the need for Dependency Injection

I was talking to some of my team mates in Austin regarding the usage of Spring as opposed to "Heavy Weight Containers". They asked what I think about using Spring in the new features of an application they are working on. I have to admit that I never used Spring. Why? Because I never had to. All that I needed to do was supported by EJB Containers or the so called Heavy Weight Containers. Maybe I don't how happy I can be if I use Spring but so far services provived by Java EE containers were enough. And with clustering!!!

I also have to admit that previous versions of EJBs were almost untestable (It's horrible to have to mock an EJB) but at the same time put business logic into EJB (here I am talking about Session and Message-driven EJBs) is something that I don't like that much. I always used POJOs for business logic also to be more testable. My EJBs just acted as a facade to provide remotability. Anyway, when I asked to one of them what was the need he answered me: "I want productivity with Dependency Injection". And more, he told they were going to use Spring integrated with the EJB Container to take advantage of the existing services provided by the container. What? Hum, a self-called lightweight container integrated with a heavyweight container. This sounds interesting. He wanted to have the advantages of dependency injection but also taking advantage of the container's services.

So here I don't take any conclusion despite I have my own opinion on using one or antoher. I just would like to know everybody's opinion on this.

- How are you guys using Spring?
- Has someone already integrated Spring and Java EE container? To take advantage of what?
- And for those who are using only Spring, what are the pros and cons?
- Are you using only the framework or also Spring Portfolio?
I appreciate any comment on it. :)

Are we becoming Java Dinosaurs?

I was trying to think specifically when a developer, who codes in a specific programming language, is starting to become a dinosaur. It's not his/her age because there are lots of old guys working with new technologies and even creating them.
But when I was reading this post from Bruce Eckel (it has been discussed here as well) I was thinking that when a technology stops doing new things then that technology is in process to make its "followers" as dinosaurs. Of course, Bruce Eckel is not fully suggesting Java should stop adding any feature. His point relates for adding features when we really need them.

But if Java starts the process of becoming, as he says, "stable" then does that mean we are becoming dinosaurs?

Let's analyze some things:

When a programming language stops adding support to new technologies then how that technology will have new people working with it? Imagine if Java has not provided any answer on SOA (through JBI or Web Services)!? Nowadays is all about SOA. But how would developers make their applications "SOAble" if they could not find in the language they are using a support for that feature? They would migrate to new programming languages or technologies that can offer such approach.
Would the same developers create applications in that "old" language even if language support all the application's features? I don't think so. How many C/C++ applications are being created compared to technologies like Java and .Net?
I don't have the answer but at least in the world I live I don't see that much (I would like to say none at all!!!).

Another interesting thing is that today in JCP, the number of JSRs in Review Stage is 0 and there is only one Early Draft Review.

If Java (JCP) starts the process of reducing the number of new features added to the language (or being "stable") then I really believe I am in the beginning of the process of becoming a Java dinosaur.

JUG's challenges

I really don't know what are JUG's structures around the world (maybe you could provide me a feedback about it) but most JUGs in Brazil face almost the same problem: Coordinators who need to spend considerable time to work for the JUG. Let's not forget that working for a JUG, according to my opinion, should be volunteer job, which means that you are aware that sometimes need to spend your time and maybe some money to work for the JUG.

Some JUG's activities include:

- Build Strategic plan for the year
- Organize affordable events
- Make the link between community and job offers
- Create and maintain a mailing list so community can share ideas.
- Organize open meetings so community folks can join

As you can figure out, there is an considerable ammount of job to be done for the JUG. but what are the advantages for those who work for a JUG and don't receive any money for that?
I can tell some:

- Visibility: As a JUG coordinator you join lots of important meetings with people who are interested in participate JUG's events
- Networking: This is the most important for me. You know lots of people. You know directors, managers, developers and create a very good relationship with those people.
- To keep yourself aware on what is happening in the Java world.

And what about money?
No, you won't probably receive any money. Some JUGs are working together with User Groups organizations (In our JUG we work together with SUCESU, the main organization that represents lots of User Groups for IT) and saving some money as a result of events to somehow spend this money organizing more events or send some people from the community to larger events like Javaone and No Fluff Just Stuff.
Maybe this is an approach that should work for most of the JUGs. In my case, our JUG is really needing some fuel to continue to work for the community as it did very well in a couple of years ago.
I really believe JUGs should follow examples of SouJava and DFJUG, two of the most passioned JUGs in the world.
But what else coudl we do? Maybe some new structure (what is your JUG's structure)? Maybe work closer to User Groups organizations or even Sun?
What else? What do you you think? What about your JUG?