-
In the first part of this article, I began briefing you on optimizations I made to maximize the responsiveness of a JSF application that I developed out in the field. I cited performance problems caused by casually accessing components from a JSF view, then presented a set of best practices to eliminate this unnecessary overhead. Despite the progress made by the end of the first part, you had not yet witnessed the two orders of magnitude in performance improvement that was promised.
-
JavaServer Faces (JSF) has a reputation for having poor performance. Some claim that this "runtime tax" is simply the cost of using a component-based abstraction layer. After focused research, I have determined that by following a handful of best practices, you can get your JSF data tables to perform almost as well as hand-crafted HTML while still being able to retain the benefits of developing with an event-driven programming model. I begin by identifying some performance problems that occur when using JSF UI components, Seam components, and the EL carelessly, and then present, through a series of four lessons, ways to eliminate these problems one-by-one until you have observed a remarkable, two orders of magnitude improvement.
-
How would you implement a Plugin-system for your Java application?
Is it possible to have an easy to use (for the developer) system which achieves the following:
Users put their plugins into a subdirectory of the app
The Plugin can provide a configuration screen
If you use a framework, is the license compatible with commercial developement? -
So we know that all injected properties of a component are dynamically injected prior to business method execution. This means every time a business method is invoked whether or not those properties need to be re-freshed all of the properties marked @In are re-fresh/re-injected. So let's take a hypothetical case. Say we have 20 Seam components that need to be injected into component Foo. Would it not be more efficient to use Component.getInstance(C1.class) instead of the unnecessarily repetitive and time-consuming "swarm" of dynamic injections? For a particular business method, you get the component you need at that exact time. Instead of getting all 20 of them when you may only need one of them for that particular business method. That's overkill. Use @In except when absolutely necessary like injecting SMPC and Log instance via @Logger.








Comentarios recientes