Marc Palmer

So this Monday we had to launch a new website with Grails 1.0.2 to a site with an existing Gails 0.5.6 application running inside a single Tomcat instance.

We had the box’s ram upgraded from 1GB to 2GB to cover the anticipated extra drain – the existing app had seemingly needed 1GB for itself.

So the RAM or the extra CPU load was making the box croak and was showing up a Linux kernel 2.6.9 bug related to unlock_kernel() calls and we were getting up times of circa 50 minutes before the thing locked and needed a reboot. Also possible the RAM was faulty and the hosting company swapped it out for us pronto.

Anyway… when it was working many pages would come back blank. Logs showed OutOfMemory errors and we played with Tomcat heap settings as the problems were native thread allocation. Then the alarm bell in my head rang and reminded me that Java gives this OOM error not just for memory exhaustion but also not being able to allocate a new native thread.

Our sys admin looked into it and found that ulimit was 100 processes, a leftover from when I hacked the box to be secure with Bastille. The limit was removed – after all we need hundreds of threads in the Java VM for any level of traffic with 2 apps running.

Bingo – server runs beautifully with both apps withing 1GB Java heap. It runs better than it ever did with the single app and the hosed ulimit. Duh.

It is not surprising that Sun is making such a fuss about trying to get Java onto the iPhone / iPod Touch platform. They must be thinking "Holy crap, if iPhone and iPod touch replicate the success of iPod’s 72% mp3 player market share (excludes mp3 player phones), Java will be dead in the water on mobile". Too damn right.

The mobile handset market is completely different to the mp3 player market, where figures typically exclude the market made up of mp3 playing phones, but Apple might just pull it off.

I am a former J2ME developer of games, and now I’m a Mac user and iPhone owner. Java on iPhone/iPod Touch is a crap idea. People who think iPhone needs Java are failing to understand the Apple approach. The fact is that Sun/J2ME almost definitely needs iPhone to survive once Apple roll out cheaper mass-market handsets.

J2ME produces, much like J2SE, crappy applications on every platform. The Apple experience is about polish, about remaining uncomplicated, reliable and confidence inspiring. J2ME is about trying to average out all phones and at least get our app out there in some form no matter what compromises we have to make. This is exactly what happens in the J2ME space: "We spent $$$$$ developing our J2ME reference build, now we need to cash in by porting to as many devices as possible. Who cares what the thing ends up looking / running like, if we’re not on phone X we might miss out on 10% of the market because it’s so popular."

Now, take a look at Skype’s new Java mobile client. it looks like they haven’t done a bad job on the UI but it definitely isn’t great. The point is the UI will not fit in well with the existing phone UI and it will look different to every other J2ME app on the phone, and it therefore requires different understanding to use it. It will also probably chew your battery like there’s no tomorrow. It will also not have access to any recently invented (probably circa 2 years lag) features the phone might have – as without standard J2ME APIs which take years to approve and roll out among handsets, developers have to rely on proprietary APIs and that means yet more R+D, yet more individual ports and yet more QA.

Then you have people like Innaworks who say they can automatically port J2ME apps to iPhone. Dream on guys! You might get something running but it is going to look like crap on the device, won’t use natural UI paradigms, and will likely require certain coding conventions in the J2ME app. The problem is that executives with no clue look at offerings like this and tell their coders/porters "Hey don’t worry we can just get it all automatically converted by these guys, no need to learn Objective C!". I’ve been there in the past with "automatic" porting tools between J2ME handsets. If these things are good, and they have been on the market for years, why do all the mobile companies still have huge numbers of staff dedicated to porting and QA? How do their converters magically scale images to look good on new higher resolution displays. How do they make text align properly on the screen according to the layouts you’ve used in your reference build?

These poor quality automated ports are for people who don’t care about quality of the ported product, and that is EXACTLY the kind of application you don’t want on an iPhone.

Java – I love you on the server. On the desktop you suck a bit. On mobile… you facilitated a games industry. On iPhone… you will just let in a bunch of crappy apps and games that look crap and perform like crap, and use up loads of iPhone battery running non-native code.

Game developers in the J2ME market will not have any major difficulty getting one or two coders to do ports from scratch to iPhone with Objective C. It just means that some of the companies will need to actually use some braincells to get some decent infrastructure in their development environments, which means smart build systems, decent data structures that scale to different devices etc.

Hopefully everyone will see come June that native apps will beat J2ME apps into the ground on iPhone and iPod Touch.

At long long last I’ve released my authentication plugin for Grails.

Check out the documentation here

My mission is to make authentication and authorisation as simple as possible. I just don’t get on with the complexity of Acegi etc, and they just don’t feel very Grailsy. So I chose a simple event model. You override the events you want, and provide your own domain or backing store class for user info if you want.

However out of the box in the immortal words of our favourite fruit, "It just works". You just add login/signup forms using the supplied auth:form tag and check if the user is logged in in your code using authenticationService.isLoggedIn(request) in your controller or filter, or use authenticationService.filterRequest in a filter to have it "do the right thing" and just ask your app via the onCheckAuthorized event which passes you in all the info you need to decide if the user can access the requested resource.

We’re already using this in production and it has gone through several iterations over the past year. There will be bugs, but there is also documentation. Which may have errata also. Let me know!

To install it use: grails install-plugin authentication

OK so it’s wet outside and I’m in my nice new shed… which reminded me of this great piece of Cardiacs rehearsal footage, which I have not embedded in my blog yet so thought I’d give it a try. This is such an old Cardiacs track but a great favourite… with such an excellent thrash up 6 minutes in which accelerates after ska bit.

Following from the update of the ModelTagLib (which I mustn’t forget was derived from an original ModelTagLib somebody posted on grails.org a long time ago) I posted on grails.org, there will be some new developments.

I’m going to refactor the taglib bearing in mind some comments from Graeme and some cleaning up I’ve wanted to do, and add some new features.

Then it should become part of Grails core in 1.1 as the "bean" taglib. We should even be able to refactor Grails scaffolding to use the tag and save a shedload of code. Of course we’ll need to write a whole bunch of unit tests for the tags. Any volunteers? (Lazy? No I’m busy… and… and… it’s better if the author of the tests isn’t the author of the code – right?)