ryan norris

Okay, so maybe it’s always been this way and I’ve just not been paying attention – but it appears that GWT 2.0 now requires one to make RPC objects that will go across the wire explicitly implement java.io.Serializable.

A bland RPC implementation that was based on past work I’ve done was barfing all over me at GWT compile-time today:

Rebinding com.ryannorris.staffing.client.project.ProjectCreatorService

Invoking com.google.gwt.dev.javac.StandardGeneratorContext@9b32fe

Generating client proxy for remote service interface 'com.ryannorris.staffing.client.project.ProjectCreatorService'

[ERROR] com.ryannorris.staffing.client.Action<T> has no available instantiable subtypes. (reached via com.ryannorris.staffing.client.Action<T>)

[ERROR]    subtype com.ryannorris.staffing.client.Action<T> is not instantiable

[ERROR]    subtype com.ryannorris.staffing.client.project.ProjectCreatorAction is not assignable to 'com.google.gwt.user.client.rpc.IsSerializable' or 'java.io.Serializable' nor does it have a custom field serializer (reached via com.ryannorris.staffing.client.Action<T>)

[ERROR] com.ryannorris.staffing.client.project.ProjectCreatorAction is not assignable to 'com.google.gwt.user.client.rpc.IsSerializable' or 'java.io.Serializable' nor does it have a custom field serializer (reached via com.ryannorris.staffing.client.Action<T>)

I can’t say I ever had the pleasure of dealing with this bit of attention to detail from the GWT Compiler in the past.  And while I will readily admit I haven’t read every change to the underlying architecture that comes with 2.0, this would seem to be a piece that might be worthy of some special mention.

It is, of course, nearly common sense to make sure that your RPC objects can go across the wire in the proper way, and thus simply respecting the semantics of java.io.Serializable the same way we would in EJB per se, is pretty reasonable.  Just a little more heads up would have been nice.

Update 1: There seems to be some mention of fixing compiler feedback around RPC serialization here.  But this defect doesn’t suggest changes that might have actually altered behavior or requirements of the compiler since 1.7.

I’ve been writing a bit about Google Web Toolkit lately. It undeniably is disrupting traditional browser-based RIA development. But it does lack some features out of the box that most developers have grown accustomed to from frameworks like Flex and Ext. Field validation is one such feature. While the gwt-validation project exists to solve this very problem, an approach leveraging a good chunk of the existing GWT infrastructure can give you a robust, test-driven, and MVP-friendly approach for validation. (more…)

For a while now, interpreted languages have reigned.  They were fast to develop in, cheap to build teams around, and were less strict about the rules of the road than many of their more strongly-typed brethren.  But as the modes of web application delivery have changed – indeed, as the modes of any sort of software delivery has changed – the era of the interpreter is likely in decline.  As platforms are stretched to their limits and developers look for new ways to deploy high-performing, scalable web and mobile applications – an old friend emerges from the fog of battle to demonstrate why it was such a valuable innovation 50 years ago.  Compiled software is back – this time to once again relegate a past generation of development platforms to the same museum as assembly.

(more…)

As much as I love automated testing, I have come to live with the fact that teams migrating from waterfall approaches to development to SCRUM often try to maintain the team structures they are familiar with.  At times, this typically means an engineering staff that sucks at writing tests, and a QA staff that is still very much attuned to the finer grained edge and corner cases.  Each of these parts of your team adds value to a SCRUM project.  Integrating them to avoid bottlenecks, stay lean, and deliver with quality is a clever trick.

(more…)