Anyone Care to Share Experience Porting a Large Java/J2EE App

Hello all,

I am in the process of evaluating different UI frameworks to replace our aging UI in our product. Our product is a very large J2EE app (probably about 200 screens). I was wondering if anyone has gone through a similar updating process, choosing Vaadin, and if they can share their thoughts about how easy it is to get Vaadin running along side existing code.

Have you gone through this process of replacing a UI technology in a large J2EE app? If so, I am very interested to hear about your experiences.

I’ll try again… Sadly, the previous response I wrote was lost with a “No Permission” type of error and doing a BACK in my browser lost all of what I had typed. Not good!

Anyway, I’m sure no two projects will have the same experiences, but Yozons essentially ported our older product that relied on a JSP+Servlet UI when we created Open eSignForms. We used the opportunity to not only put in a more modern UI, but we also changed quite a bit in our back-end to support new capabilities as well as better support Vaadin itself and a new UI in general.

We evaluated Dojo, YUI, ExtJS, GWT and SmartGWT before we settled on Vaadin. It was actually a snide comment in one of those forums from a brainiac with no social sense that mentioned Vaadin, which I’d never heard of. Of course, his opinion was that Vaadin was an oddball, server-centric UI that could not compete with a true JS front-end.

We didn’t have lots of JS experience, and in our evaluations, we had lots of work with DTOs, using JSON, implementing the event models to transfer the data back and forth, etc. It was a lot of work, but was doable. It may even be easier today, since it was 1.5 years ago we did that eval.

However, when we discovered Vaadin, it felt more natural to us as it still does most of its magic on the server where we feel we have more control, better security, etc. I guess the security side remains to be seen since we don’t really know how easy/hard it is for someone to mess with the UIDL to try to do an operation a user wouldn’t otherwise be allowed to perform. Then again, a lot of JSP/servlet programmers probably failed to check the security of operations and the validity of all params coming in, assuming that users were not tampering with the POST data (a bad assumption if your app needs to be secure).

We still have not settled whether we prefer to use JavaBeans with the related BeanItem/BeanItemContainer, or just use the Vaadin Item/IndexedContainer for most of our work. The beans seem easier, and they are for simple stuff, but we found when porting that a lot of our java classes were not well suited to be used directly, so we ended up created new javabean classes for the UI interface. This felt like the DTO issue all over again, especially since a change to the bean wouldn’t then automatically be pushed into the items/containers. Similar issues with Selection lists arose because we made more use of Lists than the Set interface chosen by Vaadin, so we had to essentially create adapter methods for those. In the end, once you get used to Item/Property, they can be used directly with ease, and seem to require no more code than javabeans unless your existing classes all match up nicely for UI needs.

One concern we had was with performance of the UI since it requires the server to generate it all, but we’ve not had any real issues. It seems faster than when we used JSPs. Obviously, if you have a UI-intensive widget, it’s best if that can all be done in JS in the browser to avoid lots of server communications. We don’t have much, but we did integrate CKEditor, and we found it works fine because most of the work remains in the JS code of CKEditor, and we only have to deal with the server to load the initial state, and then handle the SAVE button, so it remains responsive to the user.

Our old system used a common JSP list of items and you’d click on them to bring up another JSP where you changed it. This maps nicely to the Table+Form model of Vaadin, but with a splitpanel, you can avoid the page swaps that the JSP did. Of course, you should reconsider some UI design items since you can now make use of components like a TreeTable and drag & drop, a feature we really like for re-ordering lists, an ugly concept in a JSP world!

Good luck with your project no matter your decision regarding the use of Vaadin. We are still happy with our decision, though we’ll never know if we’d have been happier with any of the others since that’s a path never taken!

Wow, thanks for the lengthy reply. It is certainly helpful to hear from someone that has been using the framework for a while.

Any memory consumption issues? Latency issues? Have you compared the framework to ZK, which seems very similar?

We did not compare with ZK, but there are comparisons I’ve seen out there.

You can also search the forums for Vaadin memory/session issues. They seem comfortable no real issues arise.

We have not encountered any issues ourselves yet, but of course a web 2.0/ajax type app tends to not have quite the same browser feedback a lot of users recognize for latency issues. We find the system pretty snappy, but have no real metrics. As for memory, I’m sure Vaadin uses more since they keep the state of all open windows, so if you have a container holding thousands of results from the DB, I believe that data stays in the container and in memory until the user closes that view that references the container. But for some instances, this improves performance by not having to re-run queries when multiple buttons operate on the data results (like we have a report query button that does the work, but after that can present download buttons that can provide that data without having to run the report query again).

Our experience may not be the norm, though, since our apps are deployed many times, but each may have 1-100 concurrent users. I guess some apps are deployed only once and have thousands or more concurrent users.

Thanks David. Your input is certainly appreciated.

My app is very large and can easily have 5000+ users per deployment, so I will probably have to do some testing to figure out how the memory consumption scales with number of pages/components and users.

Is that 5000+ concurrent active users, or just 5000+ users for a deployment of the system?

It is certainly possible to scale to a very large number of users of a Vaadin application if the application is designed not to hold onto large data structures in the session - see e.g.
this scalability study
. Although the state of a Vaadin application is on the server side, Vaadin itself does not need a lot of memory per user, but e.g. data containers used in your application may do so.

Yes, I saw that study, so I realize that it can scale well with concurrent connections. However, my app is very large, so I will probably have to do some investigation about how well it works for the combination of lots of users and lots of pages.

In most cases - even large applications do not consume too much memory if you: 1) try to share data-model between users where possible instead of copying and storing duplicates of data model parts in memory per user, 2) you initialize you application lazily - there is no need to initialize all the possible view when the user logs in the application.

Application size does not matter that much. I try to explain why.

Let’s say you have an application with hundreds of views (or screens if you wish). Typical design is that you instantiate those views lazily on the need basis. In practice this means that the server-side will only contain those UI components that the client-side (browser) has visible in any given period of time. So, your client-side (browser) and server-side typically contain one view including all visible components in the view and main layout which might contain e.g. a header bar with a menu. When user makes an transition from view A to view B then view A is typically garbage collected and view B is instantiated on the server-side. When UI changes on the server-side, all changes are automatically synched to client-side which manipulates DOM accordingly. So, both in client-side and server-side you have only tiny part of components consuming your memory when comparing huge amount of components in your full application. It is easy to conserve memory consumption both in client-side (browser) and server-side. The other part here to consider is that with Vaadin you do not have to send your full application UI + logic into browser and stress it to the limits in case you have a huge application.

Now, your lead developers might start using the following design. By default all views are instantiated lazily and views are garbage collected (+ their data containers) when navigating out from the view. Still, for certain use cases you might wish to keep some views in the server-side (and client-side) constantly on your memory. This consumes some resources but will give you lightning fast view transitions on the browser even if your views are very complex. Caching views this way is very easy with Vaadin but to make them work fluently in multi-user systems may require extra coding depending your use cases, I can share my experiences on that later.

Last, if you are binding large datasets into Vaadin components you should either 1) use lazy server-side containers by which you can control how much memory is used (bulk loading with less I/O vs. lazy loading with more I/O) and 2) even use static containers for your datasets which are shared for all sessions (=users). Using static containers is a nice trick but depending your use case you might need small amount of extra coding such as simple lock when updating containers. Notice that you can bind any container multiple times to different UI components. Anyway, it’s on the server-side so you have lots of possibilities here.

Notice that Vaadin inherently does not have a View concept. It’s a matter of couple classes with two hundred lines of code and then you have a lazy instantiated View concept in your project which will move unused views for garbage collection to handle. The philosophy in Vaadin is that we do not wish to dictate any MVC, MVP or such model for our users, select your own :slight_smile:

Best of luck selecting the best framework for your company :slight_smile:

Vaadin does security checks on the server-side for every client-side request on a component based level. E.g if a Button is disabled but it still exists on the server-side / client-side, user may tamper with POST data and still request push event for that Button. Vaadin would throw an error on the server-side and deny execution of such event.

End users can of course do what ever they want with their browsers, this is why you must not trust client-side code.

I’d say that when your developers start pushing logic into client-side, then you need to be more aware of security concerns. At least you would need to perform all security related checks on the server-side too. This also means you must perform all kinds of logic checks such as validation on the server-side because end user can skip any client-side code execution, validation included.

This is getting too technical for this thread, but two small precisions nevertheless:

To be clear: the container interface would technically allow sharing of Container instances but standard container implementations that come with Vaadin cannot really be shared without potentially introducing memory leaks through listeners. However, data models underlying containers can often be shared when developing custom containers, and e.g. JPAContainer provides a separation between the Container instance and a lower-level data access layer that can be shared.

… but there are several add-ons that provide the concept of views, navigation etc.


as part of a research & development project we did with some partners for the DLR ( German Aerospace Center) in 2010, we had the opportunity
to update our application framework, form our old servlet based api, to something else.

We evaluated JSPs, JSFs( Richfaces, Openfaces, …), ZK and GWT. Finally we decided to use JSF. After about a month, I came across
Vaadin, and was impressed from the first moment onwards. I decided, to switch from JSFs to Vaadin, and i don’t regret the decision.

Although we had to solve some issues with vaadin( Spring Integration, Multi-Window, Navigation inside an application, Basic Architecture, i18n),
Vaadin is now our main ui technology, and we did about 10 projects with Vaadin so far.

On migrating legacy projects:
We just converted an very old asp application with around 50 pages and world wide users to vaadin, and everybody seems very happy.

On navigation:
For navigation we used the the Navigator addon, but extended it with Spring, what seems like a very good combination for building large scale applications.