Let’s say you have interface Driveable:

public interface Driveable {
 public void accelerate();
 
 public void brake();
 
 public void tuneRadio();
}

Awesome. Now let’s say you have class AbstractDriveable:

public abstract class AbstractDriveable implements Driveable {
 public void accelerate() {
 Window.alert("Vroom vroom!");
 }
 public void brake() {
 Window.alert("Screeeeeech!");
 }
}

Totally cool.  And then you love your favorite FM station in ConcreteDriveable:

public class ConcreteDriveable extends AbstractDriveable {
 public void tuneRadio() {
 Window.alert("Rockin' the oldies!");
 }
}

Then we launch into development mode with whatever our application is, and…something explodes.

So we debug, and upon looking at the code that cleverly calls tuneRadio polymorphically – we notice that our debugger drops into a catch block for a NoSuchMethodError.

It appears that GWT seems to lose track of this common idiom – use an interface to define behavior, realize that interface on an abstract class to create default behaviors, and then strategize those behaviors in concrete implementations.

The workaround is simple: redeclare your unrealized interface method in the abstract class. But this is a pretty nasty little bug. The GWT guys know this, but it’s rather critical to GWT that it follow the practices of Java as best as possible. Otherwise it’s YAL.

While I’m still yet to try on some of the AJAX support – something that makes or breaks a web framework these days – Wicket‘s clear separation of concerns and robust architecture for MVP (right, ‘P’, as in Model-View-Presenter) has really impressed me.  Generally speaking, I have not been one to embrace convention over configuration in frameworks like RoR, simply because it seems non-scalable.  But given it’s pure focus on UI and it’s total flexibility to do whatever the hell I want with my middle tier, I’m feeling that when restricted to the presentation layer – the paradigm works.  Wicket is pretty programmer-centric, so unlike RoR, you’re not going to get off the ground without some skills or a scaffolding framework like Wicketopia, but I’m not at all convinced this isn’t a bad thing.

There are a couple of things that I could get enthusiastic with around Wicket, were someone – including myself – to improve them.

1. Documentation. Look, I hate documenting things as much as the next guy – but in as much as I’ve enjoyed the fruits of my labor in Wicket, I have not enjoyed chasing down information to all ends of the globe.  I love the fact that this is working software, and the curve isn’t too steep – but try finding stuff on form validation, or the entire concept of mounting URL paths.
2. Callbacks, anyone? So, forms in Wicket generally appear to be processed by the onSubmit() method of the Form class.  You override this in your child class of form.  This is the very object-oriented way of doing things, but it seems a touch limiting out of the box to not be able to register callbacks on this method.  My Form class exists so that I can have more than one of these per page, no doubt (take THAT ASP.NET), but I still think that I’d like to be able to actually register callback handlers as I wish in each Page, thus allowing Forms to have different behaviors dependent on where they are used.  I’m pretty sure this isn’t the 80% use case, but I still am left with only one alternative out of the box, and that’s to keep extending the class hierarchy.  It’s nice to embrace strategy pattern and all, but to me this is where we really need an observer.

   So I was able to fudge this myself by creating a FormSubmitListener interface, subclass Form and implement it’s onSubmit() to call the formSubmitted() method from my new interface, it’s own implementation registered through the constructor on my Form subclass – but I think in an MVP or MVC framework, I still would like the ability to use OOP to handle the quirks of the page lifecycle (yeah, yeah – Wicket is unmanaged), but allow observers to actually handle pseudo-user events.

These two things aside, I feel pretty at peace with Wicket as my web framework for Java projects going forward (sorry Seam).

Another note – I’m really interested in the possibilities of packaging all of the resources for the web project in the JAR file.  While WAR’s are fine for deployment, JAR’s make the application open for truly modular design.

Now to refresh my memory on getting JTA running in a pure servlet container…

All in all, I’m very pleased.

The m2eclipse plugin is marvelous, finally.

The day has finally come where I’m no longer fighting Eclipse to build projects using Maven, as it should be.  Maven ties far too many niceties of the world together, and to not have it as the underlying, portable build tool within the IDE has always frustrated me.  The ability to quickly start a new Maven project, apply an archetype and go is fantastic.  The fact that it doesn’t require special jazz to get a WTP project up and running is even better.

Hey look, working with my database and some JPA implementation is really easy!

…well, almost easy.  I created a project for my middleware just using the quickstart archetype.  I was just going to throw Spring on top of it and avoid spoiling the good experience so far with EJB insanity.  The next thing I wanted to do was load up my database tables as ORM classes via Hibernate.

For whatever reason, this was cool on my Mac.  Project Properties…JPA Tools…Generate entities.  This is somehow not the way to do it over in windows.  So instead I tried to add JPA as a project facet.

My first problem was that I didn’t have Hibernate set up as my default JPA provider.  Unfortunately, you can only do this through the Maven-managed dependencies.  It has to be an Eclipse user library.  So I download the Entity Manager and wire it up into Eclipse.  Add the Java Facet (somehow not a default, probably Maven’s fault), added the JPA Facet (and am told I need to add the Utility Facet, so I do that).

Further configuration required.

Ok.  So I click into this further configuration and it reasonably wants to know how I connect to the database.  Fair enough.  I do all this, and it still won’t let me apply the change.

Eventually, it appears you need to add the Java project facet first, and then and only then can I reopen the properties page and apply the JPA facet.  A frustration point, but I figured it out.

Hey, nothing special to get a project with the Wicket archetype running in WTP.

I start a separate web project and use the Wicket archetype, interested in tackling what looks to be a nice, lightweight UI package for Java (though it looks like Spring integration isn’t trivial – which is basically unacceptable these days).  I start the project, I add a server configuration, and deploy…

Holy crap, it works out of the box!

I have a ways to go, but things feel more turnkey with Eclipse than I’ve ever experienced.  I did up some JUnits with Mockito, and that was easy, indicating that if I were to set up Cruise or some other CI tool, I could quickly get going with a full Agile project.  Exciting stuff.

1. Has Java gotten boring?  If you’re a web developer, Java has always been like 6AM – too early to really be interesting, too late to convince you to go back to sleep;
2. Java’s middle tier absolutely blows anything else out of the water.  I like LINQ, but comparables like ActiveRecord for RoR or PHPYii simply can’t do the things that JPA can do;
3. IoC/DI in Java, open source or JEE, is still better than anything anyone is doing today – Castle included.

Dave points out that the “write-once, run anywhere” paradigm may have lost out to virtualization.  Call me when virtualization is native to all of the major OS’s, Dave.  Until then, the JVM is still the closest thing we have to a platform independent environment.

I’ve looked at the EE6 spec, and he’s right though.  Omitting things like Web Beans is certainly a disappointment.  The fact that we still don’t have great native dependency injection in the EE platform leaves us always falling back upon Spring.  All of these things are rather frustrating.

JavaFX – just terrible.  Adobe did it right with AIR, even if adoption is seemingly limited to hundreds of Twitter clients.

If Sun wants to start pushing the envelope instead of follwoing the leader – how about embracing a cloud computing platform through JEE?  JAX-RS is promising, but why not unify the JAX-WS and JAX-RS spec to provide a single platform for all web-based SOA?  At the very least, that would put them on par with WCF.

I haven’t been architecting Java solutions for a living in nearly a year now, and last I checked the state of the world was more or less:

• EJB had assimilated Hibernate and other ORM solutions as something now called JPA, which was neccesary and useful to standardize;
• EJB had also taken elements of Spring to invert the once ubiquitous locator pattern and adopt dependency injection as the standard for satisfying collaborator relationships.  Of course, the Sun solution aimed to solve specific problems in EJB, and had less interest in solving the more general need for standardization around DI-based application frameworks;
• JSF was crashing and burning in the web tier, with Gavin King once again trying to pick up the pieces and simplifying the entire stack through Web Beans.

So to distill it down – middleware in Java was actually a pleasurable place to work, and the web tier was still a torture chamber.

Note: I’m leaving Velocity, Struts, Spring, and Tapestry out of the mix here.  That’s not to say that there isn’t value in some of these frameworks.  Tapestry was architecturally sound but hinders rapid development.  Struts and Spring both require siginificant configuration, and Velocity is…like Smarty for PHP.  All of them did so many things differently that it would be difficult to standardize around any one of them.  Additionally, the only one that could arguably be standardized within the exiting JEE stack is Spring – which attempts to solve many of the problems of front and middle-tier integrations.

Per my post from the other day, I really feel that the age of the server-based Web UI framework is dead.  MVC will always be a necessity, but re-usable controls and architectures that try to solve all of the world’s problems with different delivery mechanisms be it HTML or JSON are at a dead end – it’s simply not scalable.  So my attention turned to an article by James Strachan about JSR-311 and how he feels it could be the standard to solve much of the worlds problems.  JSR-311 addresses the JAX-RS standard for delivery of RESTful services.  This has long been needed from Sun given the narrow nature of the JAX-WS spec, but James has the right idea.

…Having had a horrid time using Tapestry and Hibernate together on some projects in the past, I’m kinda over the whole concept of server side UI web frameworks personally (I’m putting my flame-proof suite on now). I kinda think if you want to do complex rich web UIs, use wizards or complex flows, just use GWT or JavaScript on the client (or Flex/Flash for video or crazy highly graphical widgets) and keep the server side fairly simple and very RESTful….

So, I’m not the only crazy one out there.  That’s comforting.  But is a standard that serves as the foundation for tools to deliver RESTful services the answer?  From an architecture perspective, I’ve always been of the mindset that RESTful services, particular with its HTTP metaphors is just a DAO pattern exposed as services.  This is a pretty fine grain for me, but as Seam in Java and LINQ in .Net are beginning to prove – the value of coarse grained business services as provided typically by Session Beans in EJB may be a bit overstated.  So, does it make sense to build web frameworks that are really geared towards SaaS, and allow frameworks like Spring or Velocity or, hell even simple XSLT – take the helm when more traditional request-response mechanisms are needed?

And even more so, a cursory review of the JAX-RS doesn’t really present any options for consuming the services produced by implementers.  That’s somewhat understandable given that the product is typically vanilla XML or JSON or Text or whatever.  When I wrote my own RESTful service implementation using Spring a few years back, I made sure that XSD was attached and available when the service was XML.  This made it easy to write JAXB clients if your consumer was another Java application.  Slowing down development by forcing homogeneous consumers to parse the response as DOM seems like a likely outcome of not having SOME way of addressing this issue.

Taken together, I’m on board with the idea that JSR-311 could be a good foundation for a web framework that treats the client as being smart, rather than the dumb terminal approach of the past.