Java ME Mobile Phone Applications – The Good, the Bad and the Ugly

Shine Technologies Senior Developer Kon Katsaros has written an article entitled ‘Java ME Mobile Phone Applications – The Good, the Bad and the Ugly’. Inspired by the popular spaghetti western, he covers ‘the many highs – and a few of the lows – of developing applications for mobile phones’ using Java ME in the real-world.

You’ll find the article here.

JavaOne: JRuby & DSLs

I know JavaOne’s over now but there’s one talk that I attended that I haven’t yet got around to commenting on. It was entitled ‘Exploiting JRuby: Building Domain-Specific Languages for the Java Virtual Machine’ by Rob Harrop of Interface21. If you need some background on DSLs, I refer you to my coverage of another DSL presentation.

As well as being able to classify DSLs as ‘external’ or ‘internal’, Harrop introduced another distinction: ‘general-purpose’ or ‘business-specific’. ‘General-purpose’ DSLs are intended to address infrastructural concerns and are thus for use in a variety of business domains. These are the sorts of DSLs that I was talking about in my original blog – for example, Ruby’s Rake and XMLBuilder, or Groovy’s SwingBuilder.

‘Business-specific’ DSLs, on the other hand, are tailored to streamline and simplify the expression of business rules and concepts in a particular business domain. Harrop gave the example of a ‘corporate action’ that calculates entitlements to be issued to stockholders. To give us a feel of what a DSL might look like in this business domain, he gave the following example:

corporate_action :bonus_issue do |position, payout|
entitlement :stock => position.quantity * payout.rate

I’d be lying if I said I fully understood what he was talking about: as a relative newcomer to Ruby, it’s difficult enough for me to understand the mechanics of how this code works, let alone the business domain as well.

Almost by definition, business-specific DSLs such as this are only useful for describing complex business rules. If the rules weren’t complex, there wouldn’t be a need for a DSL. If you had a good grasp of the business domain, the code might read quite naturally. But it was a struggle for me.

When I came away from the talk I couldn’t help feeling that this usage of DSLs was perhaps a little more specialized than was being acknowledged, and that it might be a long time before the need would ever arise for me to use them in this manner.

Indeed, I see some potential parallels between the take-up of DSLs and the hype around aspect-oriented programming (AOP) a few years ago.

Let me explain: soon after the notion of AOP first became common, there was much talk about its application to business rules. Well, that was a while ago now. I personally haven’t written any business rules that use AOP and I don’t think I will be anytime soon. The only real-world application of AOP business rules that springs to mind is complex financial systems and I just don’t work in that area.

Don’t get me wrong: I think AOP is a useful idea; if anything for re-raising in our collective consciousness the concept of interceptors. However, I haven’t used it for anything more complex than basic method interception for infrastructural purposes – logging, transactions, security.

So just as I’ve used AOP for infrastructural concerns instead of business ones, I think it’s much more likely that I’ll be using general-purpose DSLs instead of business-specific ones. Furthermore, the only application of business-specific DSLs that immediately springs to mind is complex financial processing – just as it was for AOP.

I expect that there’s going to be a flurry of activity over the next year or so as every man and his dog sets out to write a general-purpose DSL. Consequently, I consider it unlikely that I’ll be writing one myself – although I do look forward to them making my life easier. And as for business-specific DSLs…whilst interesting, I consider it unlikely that I’ll have to use them very often…if ever.

JavaOne – Advanced Groovy

Well after a couple of days of blue skies we’re back to good old San Francisco weather as both Mark and I have known it in the past – cold, wind and fog. So whereas a couple of days ago it seemed a shame to disappear into the underground caverns of the Moscone center, now it’s a relief to get out of the cold.

Most of the demos I’ve seen at JavaOne haven’t elicited much response from the audience. In fact, a surprising number have at-least partially failed and/or been poorly prepared. But today both Mark and I saw a demo that earned repeated applause from the audience – and it was driven entirely from the command-line.

The topic was ‘Advanced Groovy’ and the presenter was Rod Cope, CTO and founder of OpenLogic. Essentially a consultant, he claimed that OpenLogic had built the largest (and probably one of the only) production Groovy installations in the world. I found him to be an engaging speaker.

He started by giving a quick overview of the language. Whilst there wasn’t much in this for me that I didn’t already know, I did learn one thing: you can actually compile pure Java source code with Groovy, and then move the code over to Groovy on a line-by-line basis. That’s how closely related it is to the Java language.

Next he moved onto more advanced language features. I personally find that kind of thing interesting but to some people it’s probably a bit of a snore-fest. He talked about Expando Dynamic Objects, SwingBuilder (which is a Groovy version of the sort of Swing framework I mentioned in DSLs and Dynamic Languages ), Dynamic Language Extensions (although because of the limitations of the JVM, both Groovy and JRuby cannot quite match the power of language extensions in pure Ruby), and finally, the curiously-named concepts of ‘currying’ (not enough room to go into here – suffice to say that whilst it was interesting, it was a little worrying when he confessed that he’d only found it useful for testing and made a public appeal to the audience to tell him of any other uses it might have).

But things got impressive when he went to the command-line and cranked up the Groovy shell – an interactive shell for executing Groovy code. Using the shell, he typed in about 4 lines of code for an XML-RPC server and started it up. Then he cracked open another Groovy shell and wrote a client in about 3 lines. He got the client to call the server and it worked without a hitch. This earned him his first round of applause. I’ve been able to create small client-server demos using Spring and RMI, but not that small, and not with XML-RPC.

But the best was yet to come. Using an optional Groovy module that leveraged the JACOB Java-COM bridge, he was able to pop-up Excel with one line of code, create a new spreadsheet in it with another line of code, put some values into the spreadsheet with a few more lines, put in some formulas with another line, then put a graph of the results into the spreadsheet. And he did this all remotely from the Groovy shell. Excel was in one window, the Groovy shell was in the other. That was when he got his second round of applause.

Next he wrote a few lines of SwingBuilder code to popup a separate Swing frame, got Excel to export its graph to an image file, and got the frame to display the image. And for his crowning achievement, he put a button on the frame that, when pushed, inserted random values into the spreadsheet – resulting in the graph being updated – re-exported the graph as an image and redisplayed it in the Swing frame. At this stage, the audience was truly impressed and let him know it.

Now whilst this may sound like a rather peculiar and contrived demo, let me say that having sat through three days of generally unimpressive demos – usually involving some IDE labouring over the generation of a dead-simple JSF or Ajax UI – this one was remarkable if only for the fact that it was typed-in directly from the command-line and came straight out of left-field. I’ve never seen the JVM interact so easily with a Windows app – in fact, I’ve hardly ever seen them interact at all. And whilst the bulk of the magic was done by JACOB – a framework that you could just as easily use from Java – the fact that Groovy made it possible in just a couple of lines of code, without any compilation and within a shell made it all the more compelling.

So hats off to Rod Cope. His unexpected but nevertheless impressive demo has opened my eyes to a whole new range of possibilities and will have me looking into Groovy some more.

JavaOne – Java Web Apps Vs Ruby on Rails: This Time With Tools

A day ago I attended a presentation run by a couple of young Sun engineers entitled ‘Java Platform Web Applications Vs Ruby on Rails: This Time With Tools’. They were big fans of Rails, and set about examining two important questions:

  • Can you develop a JSF webapp as rapidly as a Rails one if you have the right tools?
  • Is the Ruby and Rails tooling sufficient?

By ‘tools’ they really meant NetBeans, but this was understandable given that they are Sun employees.

They gave a little demo of NetBeans generating the skeleton of a JSF web application, in a similar manner to how Rails can generate an application skeleton. And superficially speaking, the resultant directory tree certainly looked no worse than that generated by Rails.

The chief concession they made was that with the Java solution you need several frameworks, whereas with Rails you get a full stack. What they didn’t mention was that with Java, support for important things like migrations, fixtures and integration testing is missing. This is where I think that Rails still has an edge.

They ran the server from NetBeans, demonstrating that compilation and deployment of JSF apps is now down to around the 10 second mark, making development speed on par with Rails a possibility. They did admit, however, that memory problems and server restarts are still an issue.

With regards to the Ruby on Rails IDE support, I think that NetBeans has definitely advanced the state of things. I’ve already covered the NetBeans Ruby support, but the Rails support is also pretty cool, although it’s really just a wrapper for the Rails infrastucture.

We already know that Rails offers a great environment for rapidly getting a web application up and running. Whilst we acknowledge that Rails may well be subject to the 80/20 rule, frankly I wasn’t convinced that the NetBeans JSF support was helping get a new JSF project very far at all.

As a framework Rails still seems more potentially productive. Consequently the real benefit of NetBeans that I see is not that it can build a great JSF app for you, but that it provides great support for Ruby and Rails – which is already a great framework.

JavaOne – Ruby on Rails Vs. JSF and jMaki

banner.JPGDay two at JavaOne and I’ve been amazed at how many times presenters (including many Sun employees) have advocated Ruby on Rails during their presentations, be it running on JRuby or the native C Ruby implementation.

The thing that I’m curious about is if and how this support fits in with JSF and jMaki. Are Sun intending that JRuby on Rails be a lightweight alternative for building small apps, whilst JSF and JMaki are for the big boys? Or are they just going to sit back and see what happens? I think it’s a good idea that they’ve embraced JRuby, but their support is certainly low-key compared to what they’ve done for JSF in the past. It’s almost like they’re hedging in case JSF and jMaki fail.

Not that this is a bad thing. It’s not like JSF has taken off. I’ve always been interested in what it was theoretically capable of, but frankly it wasn’t until ‘JSF in Action‘ came out that I was actually able to understand it. The same can be said of jMaki: in theory it’s seemed like a promising integration of JSF and Ajax. But when Mark attended an introductory session on jMaki today he came away disappointed. For at this point in time, when it comes to building a rich Ajax interface, jMaki comes up short compared to RJS templates or GWT.

JavaOne – Rails, Sails, Trails, Grails, Snails (ok, not Snails)

Both Mark and I attended a presentation last night that covered a variety of frameworks inspired by Rails – known collectively as the ‘*rails’ frameworks. Core to all of them is that they promote the convention-over-configuration approach pioneered by Rails.

We began with the grand-daddy of them all: Rails itself. Frankly this was the fourth time at JavaOne I’ve had somebody give me an overview of Rails and whilst in some ways this is indicative of a good thing going on, it was starting to wear a little thin for me personally.

Next, the presenter gave us a 10-minute overview of the Sails framework…before confessing that the project was actually dormant – apparently most of the core developers have gone to Rails. I just wished he’d told me that at the start so I could have done something different with my brain for that 10 minute period.

The third framework covered was Trails. This was an interesting one in that it pulls together Tapestry, Hibernate and Spring in a pre-packaged framework. At the time of the presentation, it was announced that it had just gone to 1.0. However, being based fully on Java it seemed to lack some of the expressive power of frameworks built on more dynamic languages.

Finally, we learnt about Grails, a Rails-like framework that uses Groovy. The chief selling-points of Grails are that:

  • Groovy’s resemblance to Java purportedly makes it easier for Java programmers to learn than Ruby.
  • Grails integration with Hibernate and Spring means that experience with these frameworks can be leveraged as well.
  • It easily integrates with any other Java code that you may have.

Grails provides code generators that are very similar to those provided by Rails. And Groovy’s dynamism allows for a Ruby-like conciseness in your code.

Of the frameworks presented, Grails presents the most feasible alternative to Rails. It’s too early for me to comment in any more detail on it. However, with a few more Groovy and Grails-related presentations to go, hopefully I’ll be in a better position soon to comment.

JavaOne – DSLs and Dynamic Languages

JavaOne PavilionBig day at JavaOne today with the keynote. There are a lot of people here. Mark’s already covered the keynote, so all I’ll say is this: that room was so big I reckon you could fit at least two Boeing 747’s end-to-end in it.

Straight afterwards I went to a presentation on Domain-Specific Languages (DSLs) by Neal Ford of ThoughtWorks. Thanks to Martin Fowler I already had a basic understanding of these, but this talk helped flesh things out for me. And it also explained how dynamic languages can build better DSLs.

First, some background. For those who don’t know, DSLs are small psuedo-languages targeted at very specific problem domains. Put simply, they aim to make the code for solving a particular type of problem more natural to read.

There are actually two ‘types’ of DSLs: internal and external. Internal DSLs are built on top of some existing language – for example Java or Ruby – and leverage that language’s syntax. External DSLs are full-blown languages in their own right with their own dedicated syntax and are built using compiler generators like Antlr. I’m going to be talking about internal DSLs here.

You can build a DSL in Java, although it’s not the best language for it because it’s so highly structured. Good examples of Java frameworks that provide a DSL are JMock and Hibernate’s Criteria Queries. Each of these APIs is still Java, but in each case the API has been contrived to make reading the code a little more natural to the particular problem domain.

DSLs are often used for things that are better expressed in a declarative manner instead the standard imperative approach that most popular languages promote. Whereas up until recently we all used XML – with all of its attendant problems -for declarative coding, now we have the opportunity develop more customized solutions on a case-by-case basis.

One of the key messages I took from Neil’s talk was that as we move along the spectrum of language ‘dynamic-ness’ – from Java through to Groovy, then on to JRuby and Ruby – the ability to construct concise, natural and expressive DSLs increases.

Ruby has already proven itself as an excellent language for constructing DSLs, a prime example being Rake and XML Builder. People are even referring to Rails as a DSL for web applications. Furthermore, with the growing popularity of JRuby, new frontiers have opened up.

One of these has already been pointed out by Julian Doherty when he asked whether JRuby can save Swing. A JRuby DSL for declaratively building Swing interfaces could be a compelling alternative to explicitly assembling them yourself. It could also provide a more natural co-existence between the declarative code used for describing a view and the imperative code that describes what an event handler should do (having seen Flex‘s rather disturbing use of XML with ActionScript embedded in CDATA tags, I think this is definitely worth keeping in mind).

Neal conceded that building DSLs can be hard, but that using them should be easy – that’s the whole point. Furthermore, he advised that in building one, you first write down what you want it to look like, and then work upwards towards that goal. This stops you getting too bogged down in the implementation before you’re clear what you want to achieve. And finally, he urged us to keep them as tightly focussed as possible.

Whilst DSLs may seem a little esoteric to you, we’re already using them everyday without knowing it. When you construct a UI with a complex API like Swing or write an Ant build script, you’re already using a DSL. It’s just that, in each of these cases, the language that the DSL is built on (Java in the case of Swing and XML in the case of Ant) has been stretched a little too far. So why not start thinking about how to make it more natural? Creating DSLs with more dynamic languages could well be the way to go.

Netbeans Ruby Support: Check It Out

Cable CarToday at the JavaOne Community Day I saw a couple of presentations on JRuby and the NetBeans Ruby support. Mark’s already talked about the JRuby stuff, so I’m going to cover the NetBeans Ruby support. I’ve actually been playing with it for a week or so, but also got another demo at today’s presentation. Based upon my experiences and what I saw today, my key message is this: take a look.

A while back Charles Nutter (core commiter of JRuby) applauded NetBeans’ Ruby support. I was a little dubious given that he works for Sun now, but was nevertheless curious given that I was starting to get a little frustrated with the RDT and RadRails plugins for Eclipse.

So I downloaded NetBeans 6 Development Version and installed the Ruby and Rails modules. I was really impressed. Code completion definitely seems superior to RDT (a boon for the novice Ruby developer in particular) and the debugging actually works – RDT’s debugging seems to have gotten a little flaky, possibly because the project has stagnated a little bit whilst the Ruby language and implementation has moved forward.

With an interpreted language like Ruby, I have found graphical debuggers to be quite useful because you can look at the full source code for anywhere on the stack whenever you want. Whilst Ruby comes with it’s own command-line debugger, I find full graphical debuggers to be one of the key strengths of any IDE. And this is especially the case for language novices.

For example, if you don’t quite understand why your Rails app is working a particular way, you can set a break point in your code just before the relevant Rails code, then step right into it. No more staring at a compiled Java class wondering what’s going on inside of it

Speaking of Rails, support for Rails in NetBeans also seems really good – an existing Rails project just worked out-of-the-box for me. This is particularly impressive given that by default NetBeans uses JRuby. I only ran into trouble when trying to use a Rails plugin that used a Ruby native C extension – a known limitation of JRuby (although I do wonder whether some sort of JNI bridge might be able to get around this). So I configured NetBeans to use my native Ruby implementation instead of JRuby and it worked a treat.

My only question concerns refactoring support – or lack thereof. The guys demoed a nifty ‘Rename Variable’ refactoring today, but it’s the only one I’ve seen. I’m keen to know what sort of refactorings they are planning on building, especially given that dynamic languages like Ruby are harder for refactoring tools to work with. I know that Sun and the NetBeans team have done some serious work on automated Java refactoring – I wonder how much of this can be applied to Ruby.

It’s been a long time since I used NetBeans – last time was probably 4 or 5 years ago. Back then I was limping along with it because I knew of nothing better. Somebody pointed me to Eclipse and it just blew NetBeans away. I never looked back – until now. And ironically, Ruby – an entirely different language – has been the trigger. I haven’t even revisited the NetBeans Java support yet!

My NetBeans 6 installation is still a little buggy, but it’s nothing serious and it’s even possible that Sun have fixed the problems since I last downloaded a build. In fact, I wonder whether 6.0 final is going to be released to coincide with JavaOne (although in this age of the eternal beta, I’m not sure that major releases have quite the impact that they used to).

If you’re developing with Ruby, I highly recommend that you check out NetBeans and its Ruby support. And if you’re a Java developer wanting to take a look at Ruby and Rails, NetBeans seems like a pretty good way to get into it. I only hope that now that Aptana have taken over the RDT and RadRails projects, they’re able to get them up to par with what NetBeans now has to offer.