Java, Web Applications, Work

Better, Faster, Weaker

I went to the Developers and Startups Meetup last week (look it up on Meetup if you’re interested it was a good event). One thing that struck me was that all the entrepreneurs were mostly interested in PHP and Ruby on Rails (there was a significant rump of ASP and .Net which I can only put down to C#’s language hotness at the moment). Java in particular was poorly regarded.

I was intrigued by what was causing the negative vibe as while I can understand that Ruby on Rails is the new tech hotness I couldn’t really see the appeal of PHP over something like Java that has a decent stack that is practically free. Talking to a few people I got the sense that PHP was seen as a “getting things done” language. Something that got you to a tangible real product very quickly. Rails seemed to have much the same quality but I think a lot of people felt that Rails skills were more expensive and in a lot of cases they wanted a thin web layer over an existing service backend that already existed.

Of course both PHP, Rails and the Java Web Stack all make various compromises to do what they do. Where Rails is opinionated, Java probably isn’t opinionated enough. If you put all your code into page (Model 1 stylee) then I’m pretty certain that writing JSPs in J2EE 5 is probably as quick to put something together.

Of course one thing that hugely hampers Java as a productive web stack is the compile and deploy loop. There is none of the immediacy of something like RoR that allows you to make changes very quickly in response to feedback. The tradeoff is of course that the code needs to be interpreted and you have to add some kind of caching to avoid the performance hit of always having to evaluate code.

But given that there are a group of people who need to have code quickly so they can sell something to their customers or investors and that they are willing to make all kinds of compromises about scale and maintainance costs is the Java platform really out of the question? I ask this because I think I have been involved in quite responsive Java web teams where feature changes have been matters of days not weeks or months.

I think that perhaps the issue is partially just mental. Enterprise software development tends to take place in a risk-adverse environment where certainty or process is valued over rapid delivery. “Best practice” in this environment tends to sacrifice timeliness. In the smaller business space this might well be a practice turned into dogma.

That said though some Java Frameworks introduce major barriers to just getting stuff done. Any framework that forces you to produce XML based interaction flow is probably distracting you from generating functionality that people want and will pay for. Routing isn’t a trivial part of an application but that’s all the more reason to box clever with it. Any framework that doesn’t make it simple to inject services into classes is making life too hard. Ditto any framework that forces you to work with a particular Expression Language or Templating product.

I am wondering if what I am looking for is actually the weakest Java framework. Rather than having functionality for all circumstances (and having to configure and setup it all up) I want a very basic REST framework which I can then add templating and persistence according to my need. It still wouldn’t have the nice scaffolding of RoR but it would mean that each element of the web app would be absolutely vital to its function. Weakness would generate the power of vitality and reduce the obfuscation of bloat.

Standard
Java

Deploying JBoss 4.2.2

I recently set up JBoss 4.2 on a Staging environment. The Production environment uses JBoss 4.0.3 SP1 and there was a hanging question of whether the application could be transferred to the newer series or not. The obvious advantage of the migration would be to move EJB3.

Well it took a lot of work but I am happy to say that if you have a J2EE 1.4 application you can move it to JBoss 4.2 and EJB 2 and 3 deployments all live together happily in the container.

However there is an important bit of behaviour that has changed and that is that JBoss no longer binds to all adaptors automatically. Instead it binds to localhost by default (I think). My deployment machine was a virtual server with a NAT internal IP and an external IP linked to its DNS alias. Therefore I knew I had issues with binding as in addition to the different IPs I also do not actually have any physical network I’m binding too.

However despite noting the issue in the JBoss wiki documentation I then proceeded to fluff the configuration. Despite having the web containers up and running, along with the JMX Beans I could not get my web tier to talk to my service tier. Instead I was getting obscure messages like Object not in table or a connection timeout.

What I had failed to realise from the documentation is that specifying the --host parameter to the run.sh script is not like defining the system property jboss.bind.address. Superficially they may seem the same, indeed they are so similar that you can in fact stop and start JBoss quite happily using this parameter. However your RMI connector will have be been bound to something else and therefore all RMI calls from outside the server will get routed to /dev/null (geek joke; I have no idea what happens to them but judging from the error message the JNDI lookup fails to connect to any object in the pool capable of servicing the request, the handle lookup probably returns null).

Essentially on a non-production machine you always want to pass

--host=0.0.0.0

to the start script otherwise the services will bind to different addresses and you will have erratic behaviour where connecting to your host by it’s DNS name, the localhost alias and by 127.0.0.1 will all have different results (normally only one of them will actually have the service).

The only other issue is that the AS Log4J configuration has been renamed to jboss-log4j.xml. While this causes some short term pain it was only when I read the release note that I thought: “hey it is weird that we configure all our logging via the container’s configuration file”.

Standard