Archive for the 'Java' Category

Using Sections in Java Classes

In last month’s discussion started by Martin Fowler’s article on humane interfaces, some people mentioned Smalltalk’s method categories. These categories supposedly serve to bring order to classes containing large number of methods. I wonder if something like that would work for Java. (Personally, I wouldn’t call them ‘categories’, as categories imply that you can assign multiple categories to a method as well as multiple methods to a category.) For example, you could have:

public class String {

    section getters {
        public char charAt(int index) {
            // ...
        }
        // ...
    }

    section testers {
        public int compareTo(String anotherString) {
            // ...
        }
        // ...
    }

    section mutators {
        public String replace(char oldChar, char newChar) {
            // ...
        }
        // ...
    }

    section finders {
        public int indexOf(String str) {
            // ...
        }
        // ...
    }

    // ...

}

The section names would not be used anywhere else in the code, so you don’t use "text".finders.indexOf("e"). Their use would be limited to sorting method names in IDEs, JavaDoc etc. So it would make sense to add JavaDoc to the sections, like this:

public class String {

    /**
     * Groups methods retrieving parts of the String object
     * or its attributes.
     */
    section getters {
        public char charAt(int index) {
            // ...
        }
        // ...
    }

One possible functional use for sections would be to allow access modifiers to sections, so you could have a public section businessMethods and a private section privateMethods.

There would have to be additional rules about inheriting sections in subclasses, using sections in interfaces, having methods outside sections, naming standards for recurring types of sections and such things.

The question is: does Java need something like this? The String class isn’t that huge, doesn’t have hundreds of methods like Smalltalk classes seem to have (note to self: read Smalltalk primer). I was triggered, actually, by a comment earlier on this blog, about the DefaultOWLIndividual class. It’s an example of a Java class that does have 300+ methods. A class like that would certainly benefit from (inherited!) class sections. I’m sure there are many more examples of large classes like this one.

But even if a class is not that humongous, even if it only has 10 or 20 methods; wouldn’t it still make the interface design more clear and structured if it had sections? It could also show better the intended use of the methods in the class (business methods vs. private methods). So I think sections could be a useful addition to the Java syntax.

2006-01-02. 3 responses.

BEA WebLogic Ready for Ruby?

BEA’s Bill Roth (vp of the BEA Workshop Business Unit) hinted at JavaPolis and later in his blog and a LogicCMG blog at the possibility of WebLogic server supporting other languages than Java, like PHP or Ruby. I think this is an interesting idea. If, for instance, Ruby or Rails applications could be deployed to a WebLogic server, maybe you could use data sources or JMS queues from within Ruby code, or even call EJBs. You could profit from WebLogic’s scalability. Another advantage I see is that with BEA ‘supporting’ Ruby, it would be much easier to use Ruby in a corporate environment (that is, if they use BEA in the first place). BEA, bring it on!

(Note that I’m silently ignoring the mention of PHP here. Mentioning PHP and Ruby together does not do justice to Ruby; too many people I speak already think Ruby is just another PHP variant. I think BEA would actually lose credibility if they were to support PHP.)

2005-12-20. No responses.

Final Thoughts on JavaPolis 2005, Part 2: Is JavaPolis the European JavaOne?

In Thursday’s keynote, JavaPolis founder Stephan Janssen asked whether JavaPolis should grow even bigger, and because of that, move to a bigger location. According to the official site this year over 2100 people attended the conference. I don’t think there’s a clear answer to Stephan’s question. JavaPolis had a very friendly, cosy atmosphere; I never had the feeling there were 2100 people around. All the stands were well accessible, there was always a seat left even in the most popular sessions. Maybe 2100 is just right. On the other hand, if JavaPolis really wants to be ‘the European JavaOne’ (as I’ve heard people say more than once) I think it’s not nearly big enough. I would expect much more sessions, high-quality sessions even on Friday (see below), more big names in the speakers department and a bigger exposition room with more companies and bigger stands. I wouldn’t mind paying a little more either if it were that big.
Continue Reading »

2005-12-20. No responses.

Final Thoughts on JavaPolis 2005, Part 1

Not being able to blog live during JavaPolis 2005 leaves me with several pages filled with scribbled notes on the various presentations. I’m glad that JavaPolis 2006 is said to feature free on-site WiFi access (you read it here first!). But even so, I’m not sure how easy it is to blog live on the spot. My laptop is rather big and heavy to carry around, it always finds a way to play the Windows welcome jingle when it boots up, no matter what settings I tweak, and it’s actually difficult to focus on the presentation and write a cohesive, intelligible blog entry.
So, about these notes. Thursday I saw…
Continue Reading »

2005-12-19. No responses.

On the Rails Again

Back from JavaPolis, and seeing the Rails book lying where I’ve left it last Tuesday, made me pick it up and continue reading — instead of looking into GlassFish, the new persistency API, JSF and all the other new stuff I’ve seen in Antwerpen. It’s all alpha, beta, preview releases; and even if it isn’t it’s still so far away: Jeroen (colleague also attending JavaPolis) and I figured we’re lucky if we’ll be able to use Java SE 5 in our daily work (read: in BEA WebLogic) by the end of 2006 (when Mustang, Java 6 is already out), and Java EE 5 by the end of 2007 (when Dolphin, Java 7 is out). Two years and two more Java versions before we can use the technology we’ve been presented this week! So I’ve more or less lost interest momentarily and gone back on track with Rails.

There was very little mention of Ruby at JavaPolis. None of the people I spoke with had actually done anything with Ruby. What I did see:
Continue Reading »

2005-12-17. 8 responses.

JavaPolis Disconnected

Lesson learned: a hotel which advertises with ‘WiFi’ as one of its rooms’ facilities may actually charge a substantial amount of money for that service; do not assume that it’s included in the room price. Not that I can’t afford 22 euros for a day of WiFi access, or that my employer wouldn’t pay it for me; I just refuse to pay that much money for it. At home (sorry, product placement) I get high-speed Internet access for a month for that amount. And it’s not that I’m in some faraway country; I’m just around the corner, in Antwerpen, at the JavaPolis conference — where there’s no reasonably priced WiFi available either. So this blog entry is written on old fashioned paper (the fancy JavaPolis notebook that we got in the goody bag), and you won’t be able to read it until Saturday, when I return.

On my first day at JavaPolis, I’ve already seen several interesting new things. After seeing a presentation on EJB3 and the new persistence API, I was left wondering why anyone would want to use Hibernate anymore. In a year or so, you’ll have this elegant-looking, standard ORM solution built into the application server you’re already using anyway. Furthermore, writing EJBs suddenly seems to become a fun thing to do. Just write the business interface, chuck in an annotation or two, and you’re ready to deploy.

I saw two excellent presentations, one about concurrency in Java 5: Brian Goetz explained very clearly, and with numerous examples, how to use the new concurrency functions, and why you would want to use them. Concurrency performance turns out to be much better than using synchronization. In Java 5 that is; in Java 6 the core language team optimized synchronization so the performance is up to par again with the concurrency library. I wonder why they waited so long with doing that optimization…

The other presentation was about Shale, by David Geary (who has some interesting blog entries about his experiences with Ruby and Rails by the way). Shale is named ‘the new Struts’, but technically it doesn’t have much to do with Struts — and maybe that’s just as well. It’s based heavily on JSF for its web interface, but it also borrows from Tapestry, Seam, and Spring WebFlow; although Shale’s webflow mechanism seems to be somewhat easier to use. However, now that I’ve seen Ruby on Rails, it occurred to me how insanely many XML config files are still used by something like Shale. I hadn’t expected this from someone so enthousiastic about Rails. Is it really impossible to have anything in Java without a heap of XML files accompanying it? I don’t think so; the EJB3 presentation showed that it is possible, using annotations and convention over configuration. People are starting to understand that developers want to code, not configurate!

2005-12-14. 5 responses.

Vacation! But first, JavaPolis

The best moment in any vacation is when you shut the office door behind you, the night before the vacation begins. You feel a free man, even if it’s only for a few days or weeks. Today I had that moment, and I’m still enjoying it now.
This year, my Christmas vacation starts off with a visit to the JavaPolis conference in Antwerp, Belgium. Technically, it’s still work; but it’s a lot more fun than solving issues and debugging code, which I’ve been doing since our first major release back in October.

The other night, a colleague told me he doesn’t like going to conferences because you get so little out of the — usually short — presentations. But for me, a conference like this is all about hearing and seeing new things, being inspired, getting new ideas, thinking up new plans, new projects… As well as meeting people: people I’ve worked with in previous projects, or people that you only knew on-line, or people who helped build the stuff we’re using everyday: Java, Google, Spring etcetera. Not that meeting them would change the way you work with their tools, but I think that people who’ve created something noteworthy, are often inspiring to meet and talk to. A conference can be so much more than just the presentations you attend. I hope JavaPolis will be like that.

I’m going to try to blog whenever I can, but that will probably only be at night, in my hotel. WiFi seems to be the one thing missing from JavaPolis, unfortunately.

2005-12-13. No responses.

Java is minimal only in the apidocs, not in our minds

The battle of Ruby vs. Java is breaking loose big time. You haven’t heard? Seriously? Well, I’m not going to add yet another blog entry with a summary of the whole discussion started by Martin Fowler; you’ll find an excellent summary on The Farm (but don’t stop there; you don’t want to miss, for example, Elliotte Rusty Harold discovering the versatility of Ruby’s Array class). My local Ruby guru advised me earlier on against comparing Ruby with Java, and I agree: you should use each language where it’s best suited.

But I would like to ask the ‘minimalists’ (pro-minimal interface, vs. humanists: pro-humane interface) this. In the last three years of Java coding, I haven’t been on a project where at least commons-lang, commons-collections and commons-beanutils weren’t included, from the start, and used throughout the code.[1] My point is, our (= coders) virtual interface to List/String/Class/etcetera does already contain all those extra, some say superfluous, methods. If I want to do a select(predicate) on a collection, I know I can — it’s just a matter of remembering which to use: Collection, Collections or CollectionUtils. But virtually, it’s just an operation on the Collection interface to me. However minimal the Collection interface is in the apidocs, in my mind there’s a lot more I can have a collection do. So if we’re generally aiming at keeping things simple, why aren’t these operations on the Collection interface itself? So what if it takes 78 methods, or 780 for all I care — if that’s where they belong, we should put them there instead of spreading them out artificially over utility classes.[2]

————

1. And even that wasn’t enough sometimes for fairly basic tricks, like the one I wanted to do just recently: convert a collection of objects to a map with key/value pairs coming from the objects’ properties. It’s not in commons-collections (let alone java.util.Collections). Yet another utility method added to the project, and not even trivial to code. While in Ruby, it’s nothing more than a fresh breeze of code…

map = {}
objects.collect {|obj| map[obj.key_property] = obj.value_property}

2. Why do people get nervous over big numbers so often? Isn’t that what we have computers for? And where should we place the limit? Obviously, 22 methods is ‘officially approved’, 78 is not; so is 23 okay? 24? Why should we have an arbitrary limit? Personally, I think it would be better to just consider the behaviour we want a class to have, no matter how many methods it takes.

2005-12-10. 2 responses.

BEA & Ajax: Bringing BEA WebLogic Portal up to speed with JSON-RPC

Among today’s fashionable buzzwords in web development is Ajax. Fortunately, when you’re using the BEA WebLogic Portal framework, it’s easy to add a bit of this hot new technology to your application. For a project I did this year, we used the JSON-RPC-Java Ajax implementation. To use JSONRPC(JavaScript Object Notation remote procedure call protocol), you drop the downloaded jsonrpc.jar in your application’s APP-INF/lib directory. This library contains a servlet that will catch and process your Ajax actions. You’ll have to configure the servlet in the web.xml (see the detailed instructions). Then it’s up to you to do some JavaScript coding.
Continue Reading »

2005-12-07. 6 responses.

So many Java web frameworks… Can we get some Clarity please?

Today I was talking with my co-worker Ravan about the various web frameworks there are now in the Java world. There’s Struts, of course, Spring MVC, Spring Webflow, Tapestry, Beehive/Netui, JSF, Shale… and undoubtedly many more. One or two years ago it was obvious which one you were going to use (Struts); right now it’s hard to tell where to put your money. Chances are, the framework you’re building your enterprise application with today, will be out of fashion (or worse, out of existence) next year. Three years from now, who’s going to maintain all that code written with, by then, outdated frameworks?

By coincidence I came across some half-hidden postings later today, about a newly proposed framework called Clarity–the one framework to replace them all. Representatives from several of the existing frameworks (Spring, WebWork, Struts Ti and Beehive) have joined the initiative. Clarity’s goal is “to unify WebWork, Struts, Spring MVC, Beehive, and Spring WebFlow in to a single project that establishes clear leadership in the web development space.” Right now there seems to be little more than a mailing list and a mission statement. It does sound promising though. Think of it: the best of Spring, Struts and Beehive united. If it’s done well (easy to use, easy to code) it could well be the Java answer to Ruby on Rails. (No, let’s not go there; Rails and J2EE are for different kinds of applications, that won’t change).

I see only one potential problem: that Clarity will fail to replace the existing frameworks, and will become just another framework coexisting with the others. If that happens, we’re all doomed. This initiative might be more important for Java than these few cautious postings seem to suggest…

2005-11-30. No responses.

« Prev - Next »