hungtang.com

Just a thought here. Who’s willing to bet that we’ll soon see overuse and reliance on annotations? Don’t get me wrong; I think they are great to a certain extent. However, you now have several frameworks (most recently released Google Guice) that proclaim loudly annotations are the best thing ever that could happen for Java. The scary part is that I expect the number of existing and future frameworks to follow this paradigm shift as we are witnessing for better or for worse. My problem is now seeing too many annotations in my source. Recently, Seam introduced another annotation called @AutoCreate used simply as a marker for a component to be created automatically. I was shaking head. Ugh. I mean they could easily just extend the @Name annotation (I honestly think they should rename that to something more meaningful), and added the auto-creation attribute there instead of creating a whole new annotation thereby inevitably inviting users to ask what does that annotation do. Whatever. Someone should write a book on annotation-driven development (ADD) because it looks like it’ll be impossible to get things done one day without it. Funny I can already see it. We’ll be back to the discussion of wanting something simpler. When will this ever end?

I have been putting off looking at Stripes for awhile because I haven’t had the need to look elsewhere. But since majority of Stripes’ users marvel at the ease-of-use and simplicity of Stripes, I became curious and finally delve in the other day. Well after just only 30 minutes looking at Stripes, I have come to my own conclusion that it is a well designed, small, simple, compact but powerful MVC request-driven framework. Here are some other observations. Note that I’m coming from, primarily, a Seam user.

Good

• Small. 350K for the stripes.jar. No other non-standard dependencies required.
• Simple. Should expect zero-to-low learning curve for someone who is coming from MVC/Struts background.
• Annotations over XML for configuration. Seems like Annotations is fashionable nowadays in Java land.
• Conventions. e.g. URL–action mapping => easy to locate source files.

Bad

• JSP. (I just don’t like them)
• Validation redundancy in UI and domain layer.
• Rich conversational-model support lacking (although support is available for Wizard-like forms)
• Stateful component management still require much code (compared to that of Seam)
• Not purely POJO-based (hard dependency implementing ActionBeanContext)

I came out of my brief tour to appreciate the simplicity of Stripes. It definitely packs a lot of punch in such a compact framework. I can certainly see why and how it gets a lot of praises. So what did I get out of this? Just nice to know Stripes maybe my request-based framework of choice some day whenever that might be.

Whilst Intel is preparing for 80 cores some day, you got to be thinking that the field of Concurrency and parallel programming will garner much attention from current and prospective developers now, if not very soon. Yes, I know– Concurrency is damn hard and a majority of developers probably dread and fear the thought of ever writing a single line of multi-threaded code for their entire career. Or maybe they think they can get away by favouring towards the multi-process model which, arguably, can work just as well (see PostgreSQL). However, I don’t doubt this impending phenomenon is real and have started to embrace this new way of thinking before it gets too late. Imagine your boss orders a brand new, expensive 80-core server machine for the business and asks you to take full advantage of it. Don’t tell me your answer to him would be along the lines of “I don’t know how”. Yikes

Fortunately for Java, it is blessed with Doug Lea’s java.util.concurrent package which does an excellent job at simplifying concurrent programming–and I do wholeheartedly mean that. As well, I highly recommend Java Concurrency in Practice by Brian Goetz. I don’t buy many technical books nowadays, but found this one particularly engaging to read.

Update 3/15/07: A related discussion on TheServerSide on The Multi-Core Dilemma

Not long ago, I experimented with NIO API to build a prototype server/client application based on multiplexors (other names include observer, publish/subscribe, event-driven). After the experiment was over, I was extremely happy with the performance and scalability achieved through such an architecture that is drastically different from that of the traditional one-thread-per-request model. The benefits were tremendous. One thread could sit on a multiplexor of many client connections and serve their requests swiftly as they arrive. When I double the thread count to 2-4 (each sitting on their own multiplexor) to take advantage of SMP, it allowed even more connections to be adequately handled by the server. At one point, I counted over 10,000 concurrent sessions established with the server, and the memory usage did not exceed over 1GB. In contrast to the one-thread-per-request model, I would be lucky if I can support one-fifth of that many concurrent sessions and not have to deal with memory-usage problems due to numerous thread creation and performance problems due to incessant context-switching.

The drawback? Complexity. It did take awhile to learn and understand the non-blocking semantics imposed by NIO. It also requires embracing a new way of thinking that may not seem natural at first when dealing with an event-driven architecture. One technique that was very helpful in getting a grasp of it all was thinking in execution states. NIO seems to really encourage state-driven design which seems, sadly, to be a forgotten tool in many developers’ toolbox. Concurrency is also a major consideration and, inevitably, have to be dealt with at some level. Having said that, I still feel that NIO will contribute to a large degree to many popular server implementation in the future. Already, I see Glassfish and Jetty are using some NIO for their container implementation. It’ll also be interesting to see how Grizzly will pan out as well.

Wow…News has it that Seam is experimenting with a hot redeployment feature that enable changes to Java Bean components without container restart.

This will certainly make development with Seam that much more pleasant than it is currently. Right now, I’m using an exploded deployment but it’s such an annoyance to force an application restart (”touching” a top-level deployment descriptor in JBoss AS) each time I make a change to my classes. Redeployment could literally take minutes depending on the size of the application. The good thing, at least, are the changes to Facelets .xhtml don’t require a container restart.

Being the curious person that I am, I did an update from Seam’s CVS and looked at the initial implementation of the hot redeployment. Basically, a Filter is used to check for timestamp changes in a special directory used for component (re)deployment at the beginning of every web request. If changes are detected, then Seam will create a new class loader with the updated component classes and force a new initialization.

Nice. I wonder how this affects the decision to use EJB3 with Seam since this feature supports only Java Bean Seam components. Ahh, it’s still early. But nevertheless, this feature is hot!

OpenID is getting a lot of press lately as being the end-all solution to the single-sign-on problem. But I’m curious as to how the public will react to this specification in the immediate and distant future.

The Good:

If OpenID ever gets accepted, we will not have to register a separate account to use a website’s service (e.g. posting comments on blogs). That’s just one particular use-case, but is being used as the prime example of the type of problems that OpenID is invented to solve. We just need to own and register an identifier (e.g. blog.hungtang.com), and we can use this ID when requested by privileged websites to take advantage of various services offered without requiring to register a membership with them. Yes, I like the idea that it saves me a lot of time.

The Bad:

But is it conceivable that we will ever need one identifier for OpenID? I don’t think so. I think it’s likely that we’ll have to maintain several OpenID identifiers just to appease the corporate world much like how we are maintaining separate email addresses for personal and business use. So are we that much better off? While OpenID may solve the single-sign-on problem partially, it doesn’t solve it entirely nor would it be in the best interest of the public for it to do so. I still want a sense of anonymity, and by having one identifier to use for accessing all the services offered on the Internet will detract from that goal. How will people react to the idea of having their movements tracked by online agents (e.g. search engines)? It’ll be interesting to observe the development of this specification.

The jury is still out there. If OpenID ever becomes ubiquitous, you can bet that domains will sell like hot cup cakes. I wonder if there are any public companies that are domain registrars. I might just get a share or two from them one day.

When Spring 2.0 was about to be released last year, I was eager to try out the revamped AOP semantics but I encountered a baffling problem to get Spring AOP to work. I learned that I had to use ClassPathXmlApplicationContext instead of XmlBeanFactory, but the reference documentation didn’t mention the differences between the two container classes with respect to Spring AOP.

Well, I delve right into Spring’s source code to get the answer. Here’s the interesting finding. XmlBeanFactory didn’t work because it does not invoke any bean post processors. XmlBeanFactory reads and loads all the bean definitions specified from an XML resource but no actual “proxy”-ing is done during initialization. On the other hand, not only does ClassPathXmlApplicationContext read and load all the bean definitions, but it also invoke a set of bean post processors which is necessary for enabling Spring AOP. One of the post processors will actually do the “proxy”-ing of the beans required for AOP. This all happens during an application context refresh, which takes place when a ClassPathXmlApplicationContext instance is constructed.

So if you are wondering why Spring AOP is not working, and you are using XmlBeanFactory, try changing it to ClassPathXmlApplicationContext. Hopefully, this explanation will save you some time from delving any deeper into the source for the answer.

I frequently visit various technical forums online to keep myself abreast on the continual development of various technologies that interest me. These forums have serve me well over the years as I would be able to learn from many interesting discussions, ideas, and solutions that kept me incessantly active. Nowadays, I try to give back to the community more than before by answering questions that users may have. However, is it me or are there many people who don’t think before they post? I think, paradoxically, many people want to have their questions go unanswered, or how else can you explain the myriad of questions out there that are lacking important ingredients to get a meaningful response. For me, I look for posts that are meaningful, diligent and, most importantly, concise.

A meaningful question should clearly state the problem. This isn’t so hard, is it? Yet, many posts I encounter don’t make that obviously clear. Usually, I scan very quickly for the meaning in the first few lines of the post, then I might skip to the bottom of the post to find it, if it wasn’t already found. If it’s hidden somewhere in the middle, then you can bet that I will hit the back button or close the tab to save myself the headache from decipherment. My recommendation is, obviously, state your intention clearly and early.

An diligent question should not rely on readers to make assumptions. Don’t post a generalized question because I don’t know where to start when I’m responding to it. Be specific! The post should demonstrate sufficient understanding, research and analysis on the matter under discussion. That means include source code (gawd, don’t include your entire program) and stacktraces if the question is about why a particular Java program is not working, for example. Don’t make the readers do any more work than necessary.

Finally, a concise question is exactly that–short and to the point. Write as few words as possible, but include the most relevant pieces of information. Seriously, I can’t emphasize that enough. If I want to read a novel, I’ll go to the bookstore or the library. If you believe that the inclusion of your country of origin presents a substantial significance to the goal of the post, then leave it intact. Otherwise, omit it.

So if you have any trouble getting any meaningful responses to your posts on forums, maybe try following some of these simple guidelines to help me to help you figure out exactly what is your problem.

When I first looked at JBoss Seam, I thought it would take over the Java web-framework space someday like the same way Struts did. I developed this intuition just after spending a day looking at the examples, and was amazed how little code was written to gain a significant amount of functionality. Interestingly, that was enough to get me hooked because I love writing terse code, and Seam helps tremendously in that regard via contextual bijections. Then I read the documentation and thought deeply and hard about the conversation-model of Seam that made it so popular. It took awhile to “get it,” but now it’s difficult to not be able to think about conversations. The idea seems more evolutionary rather than revolutionary but nonetheless, it’s quite damn useful! I found Seam’s built-in extended persistence context, scoped to conversation context, is a nice extension to the framework insofar that it can eliminate completely the infamous LazyInitializationException familiar to many who develop Hibernate-based web applications. I don’t know of other existing frameworks that provide this feature out-of-the-box, but it’s nice to finally be able to do ORM association lazy-fetching without the limitations (think Open-session-in-view). I have also found Seam’s transaction management facilities useful for simplifying JSF data access coding.

What I found in the web layer, Seam provides a JSF phase listener that uses two transactions (one tx spanning from begin of RESTORE_VIEW to end of INVOKE_APPLICATION; the other tx spanning from begin of RENDER_RESPONSE to end of RENDER_RESPONSE) to help minimize isolation problems while increasing scalability through the use of optimistic transactions during a single web request.

In the application layer, declarative transaction management can be handled by the container using EJB3 or by Seam using POJOs (a.k.a Seam components). Seam POJOs, when attached with the appropriate Seam annotations, are proxied with a full stack of interceptors that add many Seam-related services including, but not limited to, transaction management. The key here is that this happens transparently. The demarcation strategies for Seam POJOs are basic and limited (a subset of those supported by EJB) but sufficient enough for many applications, and more importantly, in my opinion, it doesn’t tie you to a heavyweight EJB3/application container.

I had written a post back a couple months ago here about other useful features I find with Seam. Since then, Seam has grown quickly, adding new and interesting features like security, spring integration which has helped its adoption rate. It’ll be interesting to see in another year how Seam will fare among its competition, but I have feeling it’ll outgrow its counterparts in due time, whenever that might be.