Jacob Heric

A Java, Spring, Hibernate, Spring-MVC, RESTful services, JSON, Ext JS starter app…

Last year, I put together a little homebrew starter Spring webapp with a Flex frontend (writeup here). Over the last year, I’ve written a few Java Spring webapps with Ext JS frontends. So, I decided to revisit my youbrew starter app to create an Ext JS version.

For those that would rather get cracking with the code than listen to me blather on about it, here you go: https://github.com/jacobheric/youbrew-extjs.

For those of you who just want to see it running, here you go: http://jacobheric.com:8080/youbrew-extjs.

Ext JS

For those of you that live under a rock, Ext JS is a javascript UI component framework. Check it out over here: http://www.sencha.com/. As far as javascript UI component frameworks go, I think Ext JS is without peer. They offer good API documentation, healthy forum support, and an example component gallery that is very impressive and compelling: http://dev.sencha.com/deploy/dev/examples/. They’ve also moved into the mobile space with an HTML5 touch offering that’s really interesting and could eventually provide a viable alternative to writing native mobile apps for a variety of platforms (Android, iOS, etc.).

Ext JS is offered under a dual license. It’s open source (GPL v3) if you’re developing an open source app. Otherwise, you’ll need to purchase a commercial license.

I’ve knocked out a few of these Ext JS java spring webapps in the last year. I’ve also developed in parallel at my current contract with another team working on similar Ext JS apps. I’m settling into an architecture similar to what you see in this starter app. My first project made heavy use of JSP tag libraries to manage the Ext JS components. Generating javascript in JSP tag libs is not pleasant and I would recommend avoiding that approach. I’ve found that it’s better to pitch Java based view component technologies altogether and work with a pure javascript front end.

You’ll see that this app brokers information to the view using RESTful JSON services. Ext JS components play very well with JSON (see the JSON data store component for example). Later versions of Spring MVC offer easy annotations based RESTful service setup and very slick Java/JSON serialization/deserialization (with the help of Jackson). The result is a nice match of technologies to marry the pure Javascript fronend to the “enterprise” Java backend. JSON is a perfect fit for sending data back and forth to a rich web app. It’s easy to work with. It’s clean and lightweight and fast. Communicating with the frontend using RESTful JSON also provides a nice platform for dropping in additional (or replacement) UIs and offers you a set of ready-made APIs for systems integration.

Read the rest of this article »

As I mentioned in an earlier post, I have some architectural reservations about using JSF as a platform for Rich Internet Applications. Flex, on the other hand, has some features which make it an attractive alternative platform for RIAs, namely:

• Client management of UI components (e.g. in-client MVC for UI)
• Flash runtime addresses cross-browser issues of javascript/xhtml/css solutions
• UI builder tools (Flex Builder, IntelliJ, etc.)

Now I realize that point number two may be a con rather than a pro for open source purists. This is a legitimate point. The Flash player is not open source. However, most of the specs surrounding Flash/Flex are in fact open source, including the SWF file format, the AMF protocol (which I use in the example below) and Flex framework itself. Here’s an (unofficial) note from Adobe on the state of the open source and Flash. I’ll leave you to judge for yourself the merits of the justifications outlined there for keeping the runtime closed (e.g. proprietary video codecs).

Another interesting long-view consideration for Flex adoption is Apple’s refusal to support Flash on its mobile devices (iphone, itouch and nascent ipad). This is another legitimate consideration. But, I believe we’ll have to wait and see how this plays out before we allow it to impact the decision to implement a Flex RIA solution. In the near term, if we want to provide a decent experience for Apple’s mobile devices, I think we’re talking about developing native apps for those devices. And as far as considering HTML5 as a suitable replacement for Flash, that’s definitely another long-term consideration which warrants little more than a wait and see approach.

But enough speculation on the merits of Flex and Flash.

The real point of this post is to report on my test of Spring Flex Integration using BlazeDS. I’ve been very loosely following the BlazeDS project for a couple years now. It has attracted me because it offers us JEE type developers the potential and promise of essentially tacking an additional RIA onto our existing enterprise Java back ends.

So, with that in mind, I headed on over to the Flex BlazeDS Integration page at Spring to see if it was really that easy to use BlazeDS to implement a Flex RIA against our Spring managed components.

The short answer (if you don’t want to wade through the code samples below) is yes. I give Spring Flex integration high marks and would definitely consider it for any future RIA solution due to ease of use. If you have existing Spring managed components, especially using annotations based configuration, it’s pretty simple to drop a Flex RIA onto those and let BlazeDS (rather transparently) provide remoting services to the client.

Read the rest of this article »

I’ve built three or four JSF applications over the last couple years. I’ve used JSF with Seam and Spring. I’ve used both RichFaces and ICEfaces JSF component libs. After all that what do I have to say about the technology? I’m not going to go so far as to say JSF sucks (but if I were, I’d certainly try to do it with as fine a collection of resources on the topic as that fellow). I’d say that JSF is powerful and flexible. I’d also say that it’s complex. Ultimately, in the context of an AJAX laden rich client application, I’d say it’s too complex.

I dabbled only a bit in JSF 2. Not enough to know how well it has addressed the AJAX issues with JSF. Take a look here if you want a taste of how those rich component libraries synchronize view state with the server through all those AJAX requests. As an architect and developer, I shudder to consider the implications of managing “customized partial processing and partial rendering on the server.” It’s no wonder that the complexity of JSF proved too difficult for some of the developers I’ve worked with, especially those who did a lot of Servlet development or Struts development and never managed to get their heads wrapped around the JSF lifecycle.

In the end, it’s not the complexity of JSF that turns me off of it. From an architecture standpoint, if I’m building a rich client application, I don’t really want to resort to a server managed view component/interface technology. That’s what JSF is and that’s not the right approach to RIA. It’s been retrofitted to operate with rich clients. Yes, RichFaces and ICEfaces do an admirable job implementing client components despite the complexity. But, if I’m going to build a rich client, then the client should be managing view components. Yes, the server still needs to do some view related processing (namely validation). But view components should be managed by the client. Flex does that. So does EXT JS and other Javascript component libs (I’m going to refrain from mentioning GWT and save that for another post. Preview: I’m not super excited to write Javascript UI components in Java).

I’m sure I’ll work with JSF again and I’ll try to keep an open mind to the changes in the 2.* specs. But given the choice, I’m going to turn to technologies that are built right to fit RIA, not retrofitted to do so.

I’m not going to offer anything groundbreaking here. But having worked with a variety of teams of talent over the years, I wanted to articulate what I think makes a good Java developer. By putting these thoughts down, I hope to forge a little more of a formal idea of what I’m looking for the next time I run into new talent and have to assess it and work with it.

Unfortunately, the reality is you’re never really going to know what you’ve got until you’re working with a developer and you see him or her make that first critical decision in the project pressure cooker. Interviews help and code samples are great, but they are pretty highly controlled artifacts and evidence. They’re in vitro, not in vivo. Real life conditions for a developer are fractious. Deadlines loom, clients transmogrify, PMs hound and every developer action gets instantly tabulated in the ledger of present and future cost (how much technical debt did you just incur when made that lousy decision?).

Here are my few short and broad characteristics of good devs. I’ll follow up with a little discussion of how to spot these traits and why they are important. It might not be possible to know for sure you’ve got a good developer until you’ve worked with them, but it’s imperative that you know before you’re tearing out a third of your code base a month before your deadline.

A good Java developer…

• Has varied experience kept at an arm’s length.
• Has curiosity plus adaptability.
• Communicates persuasively.
• Prefers simplicity to novelty.

Read the rest of this article »

I spent the last couple years building rich internet applications in java. It’s been fun work but it’s a difficult, fragmented and rapidly changing landscape for Java web development. The release of JEE 6 brought a lot of powerful rapid development features into the fold (especially from Spring & Seam). But, the release does nothing to forecast any stability in the tech and tools for doing that kind of java development. In fact, the rise of the RIA and the return to a more client-server oriented application architecture signals that maybe the most crucial technologies for java web development (flex, javascript, etc.) have little to do with java and will never be incorporated into an EE spec.

So, while I rejoiced that a lot of the things I’ve been using over the last year (annotations configuration of web & data model components, dependency injection, JSF view templating) all made their way into the spec, I’m sure it’ll do nothing to slow the pace of new tech I’ll be learning in RIA over the next year.

If nothing else though, it’ll hopefully make doing things in a Spring and/or Seam way a lot easier when I get pulled back into the J2EE cob webs of larger shop jobs.