We’ll have no casting here…

Spam, Spam, Spam, Spam, Spam, Spam, Spam.. Java’s Casts of Thousands More than any other programming language Java forces programmers to embed hard-coded knowledge throughout their code about the types of data items. The numerous explicit cast [Small Values of Cool]

Generally speaking, numerous explicit casts are a sign your design is a bit suspect. Chances are there’s some duplication to be removed (so numerous casts become just one), or the design is attempting to be too generic ie. ‘built for flexibility’, which often (ironically) results in a very brittle and inflexible codebase. I tend to find myself using casts when (a) dealing with the collections framework, and (b) writing framework code. Be suspicious if there are lots in ‘normal’ code.

Added later: having followed the post to its source, here, it looks like the code is suffering from from the ‘too generic’ problem. The Additive interface appears to be far too general to be useful. This is just my opinion of course, but I find that very specific and well defined interfaces lend themselves to flexible code far more than vague ones do.

J2EE Performance

I just got word from one of our developers, who have been testing our portal/CMS
product using WebStress. Turns out that with a combo of Apache/Tomcat/JBoss and
50 concurrent users (i.e. no “think time”) we consistently get an average page
rendering time of about 30-40ms, and this is on quite moderate hardware. Each
page has a bunch of portlets on it which displays texts, forums, images, etc.
I.e. a normal portal/website.

This is pretty good, but remember this: while the recent benchmarks of PetStore
was done with architectures that were optimized for performance, our
architecture is created entirely focusing on good design patterns and
maintainability. Plus, everything in our system is an AOP object (e.g.
Server,Site,Page,Forum,Message,Thread,Link,etc.etc., even a persistence manager
is an AOP object), so it’s pretty complex (yet simple). No corners have been cut
with regard to the design of our product. [Random Thoughts]

There is no substitute for good design (or excuse not to do it). “We must
strive to reach that simplicity that lies beyond sophistication.” – John Gardner
(courtesy of Russ).

Make it run, make it right, make it fast. I find that the third rule is often
not an issue if the first two have been followed.

Great stuff Rickard, now when can we get our hands on this monster you’ve
created? 🙂

CookWork WebBook

WebWork Advocacy.

People just don’t understand how damn cool WebWork is – so I’ve started my own mini-webwork-education-crusade.

The WebWork Cookbook  contains useful hints, tips and techniques that you probably didn’t know you could do from reading the docs. (Oh – and try to do that in another framework!)

Let’s call them ‘lessons from the trenches’

Got a use WebWork tip? Email it to me!

[rebelutionary]

Superb! This is just what I need.

Random Cliche

A brief aside from all the techno-babble.

You know how when you’re on the other side of the world and you say where you’re from people always say things like, “Oh, my second cousin Jake lives there, you must know them…”

Well in the spirit of the aforementioned, and in the knowledge that there are quite a few java bloggers in Sydney: My sister (Anna Hobbs) lives there and some of her friends are developers. Anyone reading this know her?

Hi Anna!

MegaMocks

JMock is your friend…

[Joe’s Jelly]

JMock does actually look quite similar to what I’ve done, but it is focussed more on the normal use of Mockobjects – ie. checking they were called with the expected values.

I’m not really doing Mocks at this point – its more like convincing an application that its running inside a real servlet container. Which means that I have to be able to understand that when I get a call like request.getHeader(“user-agent”), I need to return “Fakezilla”, but when I get request.getHeader(“if-modified-since”), I have to return a valid date string, or null. I’m not trying to assert how the mocks are called, just fake up a convincing looking environment. What I’ve ended up with is essentially a form of dynamic dispatch, as each mock has a collection of MethodReceivers in a Map keyed by method name, and each MethodReceiver has a Map of MethodReturn objects, keyed by an ArrayList of the arguments. Its then a case of calling getReturnValue on the MethodReturn object (confused yet?). I can therefore return different responses based on the actual values (not just type) of the arguments.

I can also simply make the Mock return a hard-coded response directly where I can get away with it (methods with no arguments for example).

There’s some syntactic ugliness in the setup code due to Java’s lack of enclosures – the closest approximation I’ve found is to implement an interface ‘in-place’ with an anonymous block. The alternative is hundreds of really tiny and very similar looking concrete classes.

The whole thing isn’t exactly generic or lightweight, as you have to know quite a lot about what your application is going to need in the way of parameters, and which methods its going to call on the request/response objects, but it has been quite illuminating finding out just how the application in question interacts with its environment.

And its nice to work on something a little off the wall every now and then 🙂

MockServletEngines

Spent the afternoon making a servlet based application run all by itself by mocking the HttpServletRequest/Response, ServletContext etc etc. interfaces. It was also a great opportunity to use dynamic proxies in anger for the first time. I ended up with a rather nice abstract implementation of InvocationHandler that contained a Map of method names and MethodReceiver objects for the calls I cared about. Using dynamic proxies saved loads of time – I could code up canned responses to the method calls I was interested in and ignore the rest. It was kind of fun being able to instantiate a servlet inside a TestCase, call doGet() and get all the HTML dumped to System.out.

I didn’t quite reimplement EasyMock from scratch, but there’s probably some synergy to be had there…