Evan Summers's Blog

November 2006 Archives

Group Layout Therapy

We use GroupLayout to assemble simple subpanels. For complicated forms, programming layout becomes (very) difficult, and so it's saner to use a GUI designer such as Netbeans.

Demo

Our Address Form is in play again.

  (AddressForm, 150k/400k, unsandboxed, Java6)

Code glance

We configure our component properties in AddressFormPanelProperties so that AddressFormLayoutPanel below is relatively neat.

public class AddressFormLayoutPanel extends JPanel {
    AddressFormPanelProperties properties = 
        dependencyContainer.getInstance(AddressFormPanelProperties.class);
        
    public AddressFormGroupLayoutPanel() {
        initComponents();
    }
    
    private void initComponents() {
        addVerticalPanel(
                createHorizontalPanel(
                createInputComponentPanel(properties.firstName, firstName),
                createInputComponentPanel(properties.lastName, lastName),
                createInputComponentPanel(properties.email, email, true),
                createInputComponentPanel(properties.phone, phone)
                ),
                createHorizontalPanel(
                createInputComponentPanel(properties.address1, address1, true),
                createInputComponentPanel(properties.address2, address2, true)
                ),
                createHorizontalPanel(
                createInputComponentPanel(properties.postalCode, postalCode),
                createInputComponentPanel(properties.city, city),
                createInputComponentPanel(properties.state, state, true),
                createInputComponentPanel(properties.country, country),
                createInputComponentPanel(properties.postable, postable)
                )
                );
    }
    ...
    private JTextField firstName = new JTextField();
    private JTextField lastName = new JTextField();
    private JTextField phone = new JTextField();
    private JTextField email = new JTextField();
    private JTextField address1 = new JTextField();
    private JTextField address2 = new JTextField();
    private JTextField city = new JTextField();
    private JTextField state = new JTextField();
    private JTextField postalCode = new JTextField();
    private JComboBox country = new JComboBox(new Object[] {"South Africa", "Zimbabwe"});
    private JCheckBox postable = new JCheckBox();
}

where createInputComponentPanel() creates a subpanel with an input component and it's label above it.

Punchline

Our AddressFormLayoutPanel and its AddressFormLayoutPanelProperties is delibrately interchangeable with a form produced using Netbeans' GUI designer so that we can choose to program our form view as above, or otherwise design our form using Netbeans.

Sneak Preview

The next step is beans binding for our form, woohoo!

Our Presentation Model class is a separate testable class which we bind to our form. Our controller is also implemented as a separate class, which interacts with the components in our forms, and of course our presentation model beans.

So to summarise, our MVC architecture consists of the following.

• View classes eg. produced using Netbeans GUI designer.
• Presentation Model classes which can be developed using TDD.
• Controller class which implements event listeners and manipulates the view and model.

We provide beans binding support, so that the controller can conveniently invoke a single method to update a presentation model from a form, and visa versa.

The controller needs to manipulate the components in the view eg. setEnabled(), requestFocusInWindow() et cetera. Since Netbeans makes our components private to the form, we provide proxies that are bound to the actual components using reflection. We call them "adapters" because they give JTextField, JComboBox et al, a unified interface eg. QInputComponent. These adapters support the binding of the components to the presentation model.

Separating the view and controller in this fashion is fairly tedious, but hopefully enables separation of concerns, and improves testability eg. where we can mock up our view to facilitate the test-driven development of our controller. This is something i know nothing about, but i suspect is well important!?

Anyway, here is a sneak preview.

  (PersonInfo, 150k/400k, unsandboxed, Java6)

You can refresh the "BeanInfo" tab (and also the "Console" tab) to see that the values entered into our form are written to our Presentation Model.

In this demo, we use QLayout which is GroupLayout therapy for simple subpanels.

Invetigation in Process 2: Event Pump DTs

It is often convenient to execute long tasks synchronously, that is to say, to wait for the task to complete, so that we can then do something appropriate like update the GUI. In order for our GUI to remain responsive while our long task is executing, we can use foxtrot.sf.net which manages to hook into the EventDispatchThread.pumpEvents() method to keep the events rolling.

In case you don't want to read Event Pump DTs, a scifi space opera, in all its gory detail, we extract some salient bits and present them below.

We might introduce a doInBackgroundAndWait() method as below.

public class QEdtInvoker {
    ...
    public <T> T doInBackgroundAndWait(final Callable callable) 
    throws Exception {
        final QEventPump eventPump = new QEventPump();
        SwingWorker worker = new SwingWorker() {
            protected Object doInBackground() throws Exception {
                try {
                    return callable.call();
                } finally {
                    eventPump.done();
                }
            }
        };
        worker.execute();
        eventPump.pumpEvents(); 
        try {
            return (T) worker.get();
        } catch (Exception e) {
            throw getActualCause(e);
        }
    }
}

An alternative to actually pumping events is to a use an "invisible" modal Dialog to disable and block our application while executing a "background" task (synchronously).

public class QEventPump {
    protected JDialog dialog;
    
    public QEventPump(JFrame frame) {        
        dialog = new JDialog(frame, true);
        dialog.setUndecorated(true);
        dialog.setBounds(0, 0, 0, 0);
    }
    
    public void pumpEvents() {
        dialog.setVisible(true);
       
    }
    
    public void done() {
       dialog.setVisible(false);
    }    
}

In this case we aren't actually pumping all events on our frame, but are disabling mouse and keyboard events by means of the modal dialog, which invokes the EDT's pumpEventsForHierachy() method.

The following demo displays an undecorated modal dialog which overlays our status bar (to appear to be our status bar) and displays a progress bar and a cancel button, while blocking our application.

(AddressFormDemo, 150k/500k, unsandboxed, Java6)

Gooey Logger

Spoiler Warning! The following pitch is a spoiler for the actual um, article...

Stairwell Pitch

Logging is a fundamental tool of software development. But using System.out.println() is for monitoring is um, not very convenient. So we rather implement a logger which can accept variable arguments, infer the class and method by default, and format our objects nicely for us.

Demos

You can see this type of logger in service in the CookieJar, its Address Form demo, and other true stories.

Implementation

I like the Java Logging API. So we implement a logger in the spirit of java.util.logging.Logger.

public class QLogger {
    protected static QLoggerProperties properties = new QLoggerProperties();
    protected static QLoggerFormatter formatter = new QLoggerFormatter();
    ...
    protected String loggerName;
    protected Level level;

    protected Logger delegateFileLogger;

    public QLogger(String loggerName) {
        this.loggerName = loggerName;
        String levelKey = loggerName + ".level";
        String levelValue = System.getProperty(levelKey, "INFO");
        setLevel(Level.parse(levelValue));
        ...
    }

    public void entering(Object ... args) {
        logp(Level.FINER, "entering:" + formatter.formatArgs(args));
    }
    ...
}

We get the desired verbosity level for this logger from the command-line system properties, eg. -Dlogger.level=FINEST.

We implement the following method to log if the message has a sufficient level.

    public void logp(Level level, String string) {
        if (!isLoggable(level)) return;
        StackTraceElement frame = getStackFrame();
        String className = getSimpleClassName(frame.getClassName());
        QLogRecord record = new QLogRecord(level, string);
        record.setSourceClassName(className);
        record.setSourceMethodName(frame.getMethodName());
        record.setLoggerName(loggerName);
        record.setLineNumber(frame.getLineNumber());
        if (delegateFileLogger != null) delegateFileLogger.log(record);
        log(record);
    }

where by default we get the stack frame, if it's loggable, and pay the performance price. Hopefully we can afford it.

Invetigation in Process 1: JOptionPane DTs

It seems that we can popup a JOptionPane from a background thread in a SwingWorker without the sky falling in. "But why?"

Ps. The title of this series, "Invetigation in process" comes from an episode of The Office when "Gareth Keenan Investigates!" but mispels "investigate" on his makeshift sign which for his "office." Heh heh. Hee hee. He He. Hmm.

Less Opensource Desktop

The different Linux distributions shouldn't be Fedora, Ubuntu, or Suse. They should be Server Edition, Developer Edition and Desktop Edition.

Server Edition will include JEE, PostgreSQL et al, Desktop will include OpenOffice, Java, Gnome/KDE et al, and the Developer Edition, Eclipse and um, Netbeans!? One would hope so!

The Non-Free Trap

The common approach of Linux distros has been to exclude all non-free binaries, to encourage vendors to release their drivers as opensource, and simultaneously encourage opensource developers to implement alternative opensource drivers, eg. for nVidia cards, Flash, and what-not. In the meantime, users have to jump through hoops like adding non-free repositories, downloading tarballs from vendors' sites and such.

This wouldn't be such a trainsmash if the vendors made it easy for new Linux users (coming from a Windows background most likely) to install "essential" non-free goodies without being forced to drop into the command-line. For example, why don't they install a "Start Here" icon on the desktop with "Click here to enable the non-free repository and launch Synaptic. And click here to install Flash once you have downloaded that tarball from Adoobie."

For this reason, the opensource desktop is currently a non-starter for Joe Bloggs that hasn't used Linux before. And surely those are the people one should be trying to attract to the opensource desktop!?

Rock and Hard Place

So the Linux vendors are afraid that by distributing non-free drivers, or at least making it easy to install these, they would be discouraging vendors to opensource their drivers and discouraging the development of alternative opensource drivers.

I respect and understand that. But i think they are making a mistake, and missing an opportunity. Having said that, it's not every distribution that needs to focus on the consumer desktop. Linspire, Mandriva and Ubuntu is enough. Others like Red Hat and Suse are focussed on the data center, and that's fine.

Common Binary Distribution License

So what's next for these distros that are actually trying to compete in the consumer desktop space?

I think they need to come up with the "CBDL" ie. the Common Binary Distribution License, like Sun's DLJ. This license would allow Linux vendors to repackage and redistribute non-free software, eg. via their default non-free repository, if not on their LiveCD. Clearly the licensors might impose some conditions, eg. before, during or after installation, direct the user to this webpage on our website, and/or display this advert of our products.

I'm sure nVidia, Adobe et al want to distribute their free-to-use Linux drivers and software as broadly as possible, and if that comes with free packaging and testing, free distribution, free marketing, and easy installation of their software for the end user, then where's the downside? All they have to do is publish their binaries under the CBDL.

This mechanism could also be used for opensource software, eg. Netbeans. I mean, is Netbeans in Ubuntu repositories, and installable via Synaptic? "But why not?"

As long as people who are installing Linux for the first time don't get accelerated video, flash and what-not, and can never get this without dropping into the command-line, then excluding IT professionals, can the opensource desktop realistically ever be anything other than a hobbyist's desktop?

In the meantime, consumers will be choosing between Vista Viao's, MacBooks and MacMini's, and be very happy with their purchases.

Gooey Beans 2: Concrete Action

The top story today is... Java is GPL'ed! The future begins today! And now for something completely unmomentous...

An earlier demo (Address Form with Gbc) is being used as a vehicle to play with GroupLayout (more on that later), but more to the point, as a testbed for the following part of Gooey Beans, namely Concrete Action. In case you missed it, the first part was Resource Map.

The following abstract is a spoiler for the actual article...

Here's the Address Form demo using actions.

(AddressFormDemo, 150k/500k, unsandboxed, Java5)

As you can see we have actions that have been configured with icons and keystrokes, and we use these to configure toolbar buttons and menu items. "But Why?" So that we can disable one action object, to disable the button, menu item and keystroke associated with it. Also we ensure consistency in each screen eg. of the label and tooltip in the toolbar and menus, and also across the application, using global defaults, eg. for icons and keystrokes.

Here's a code snippet of our concrete action to give you a gist.

public class QAction extends AbstractAction {
    String actionCommand;
    String keyStroke;
    String iconName; 

    public QAction(QActionProperties properties) {
        configure(properties);
    }
    
    public void configure(QActionProperties properties) {
        setActionCommand(properties.getName());
        setLabel(properties.getLabel());
        setToolTip(properties.getToolTip());
        setMnemonic(properties.getMnemonic());
        setKeyStroke(properties.getKeyStroke());
        setIconName(properties.getIconName());
    }
    ...
}

As you can see, we have an action properties object, into which we can inject resources, eg. translations. We use this properties object to create our concrete action, which we can then use to create our menu items and toolbar buttons.

We keep a global map of default action properties, and for each screen we can create new actions, and/or reference a global action, where we can override the defaults, eg. typically the tooltip eg. from a vague "Save data" default to a more informative "Save this Address Form."

Our sample application code is as follows.

public class AddressFormPanel extends JPanel implements ActionListener {    
    AddressFormPanelProperties properties = new AddressFormPanelProperties();
    ...
    QAction newAction = new QAction(properties.newAction);
    QAction deleteAction = new QAction(properties.deleteAction);
    QAction editAction = new QAction(properties.editAction);
    QAction saveAction = new QAction(properties.saveAction);
    QAction cancelAction = new QAction(properties.cancelAction);

    JToolBar toolBar = createSmallIconToolBar(
        newAction, deleteAtion, editAction, saveAction, cancelAction
    );
    ...
    public void actionPerformed(ActionEvent event) {        
        if (newAction.equalsActionCommand(event)) {
            ...
        } else if (deleteAction.equalsActionCommand(event)) {
            ...
        }
        ...
        setEnabled();
    }

    public void setEnabled() {
        saveAction.setEnabled(isEdited());
        cancelAction.setEnabled(isEdited());
        deleteAction.setEnabled(isSelected());
        ...    
    }
    ...
}

where we reference the actions in our actionPerformed() method, and also of course to enable/disable them depending on the current state.

IT's all good

It's an "interesting" time for our industry, and for ourselves as Java developers, innit!? "But why?" Cos i reckon that "diversity" is what defines "interesting." And it's on the up and up.

Microsoft's commoditisation of computing

I don't wish to bash Microsoft, and i won't. I don't think they deserve it. They facilitated the commoditisation of computing. Arguably, they made computing accessible to everyone. The problem was that diversity had to suffer too. But now our industry is normalising itself, and growing up quite nicely.

Microsoft envisaged a world were everyone had a computer, and the opensource-ness of the hardware platform made that possible. The volumes made the software cheap. Microsoft can sell something that costs a billion dollars to develop and market, for fifty dollars a piece. Cheap at the price.

The problem was that in this vision, every computer would be running Windows. And all software running on those computers would be written in Visual Basic or C/C++ by Microsoft or a certified Microsoft ISV Partner. Thank goodness Sun invented Java! ;)

We are still living in a Microsoft world, notwithstanding opensource, the resurgence of Apple (and hopefully Sun), and the ascendency of Google. Microsoft is here to stay. Only, they gonna adjust their goals from "total world domination" to just plain "world domination," which is of course every company's goal, and every opensource project's goal too ;) Fortunately for us, no one is going to achieve total world domination. That is now clear, thank goodness.

In the 90s, after Microsoft had trounced Apple and IBM, it seemed that the diversity of our industry was in its descendency. What's exciting today, is that it's on the ascendency again. It's normalising itself.

Open world

Nowadays we got open commodity hardware, from handhelds right through to supercomputers, and not only the x86, but also Power and OpenSparc. And open software, not only OSes like the BSDs, Linux and Solaris, but the full spectrum right from developer tools like Netbeans and Eclipse, through to desktop software used by everyone like OpenOffice and Firefox, through to databases and enterprise stacks. This keeps our industry honest and hard working.

The opensource desktop is gonna be great, and will give Apple and Microsoft a run for their money. But there'll be no world domination for any of these three, just a diversity of great choices for the consumer.

Java

We already feel that Java is gaining momentum, notwithstanding the other great options that are out there. And the opensourcing of Java will spur this on, to an extent that will suprise even ourselves.

Naturally, Microsoft will counter, and maybe they already have with their alliance with Novell, who represents opensource .Net on Linux. But competition is your own best enemy.

All good

If projects like Java and C#, GNOME and KDE, Netbeans and Eclipse, or Linux and Solaris, were to "combine" as some people suggest, the sum of the whole will be much less than the sum of its parts. This healthy competition nourishes and inspires these projects.

So it's all good. More diversity. Less world domination. I like.

Pulp Friction: Top Ten Reasons to choose Java over Python et al

Come of think of it, this can be Java versus Python and all the other scripting languages, ouch!

1. Beauty. No legacy underscores. Nuf sed.
2. Java has long, clear, unabbreviated names.
3. With Java, IDEs come standard so that you don't have to type those long names. Phew!
4. Sooo many vendors support Java, except Microsoft. Microsoft supports IronPython, which doesn't help my pro Java arguments, so ssh ssh.
5. Java runs Python and many other languages including Java! Ok, it's not fair comparing a VM to a language, but i couldn't resist.
6. Java has a well funded community, whereas Pythonistas have to be naturally enthusiastic.
7. Java is strongly typed, so we don't have to write unit tests, and can rely on blind luck more.
8. It takes longer in Java, which helps a lot when you're getting paid by the hour. "Wa wa we waa!"
9. Java rules the Enterprise, if you exclude that SAP thingy.
10. Java rules the Web, if you exclude those ASP and LAMP thingies - and Python is only one of three P's in LAMP, so...
11. Java rules the Desktop, if you exclude C/C++, Objective-C, and all the stuff from the desktop monopoly.
12. Java rules the Mobile, period... for now.
13. Java is no good at system tasks, so it gives us a good cop-out for avoiding those.
14. Java never gets compared to, or confused with, Perl.
15. Java has an enterprise version. Quite a few actually.
16. Java has more opensource projects, more toolkits, more IDEs, more jobs, more verbosity, more everything!

Please gimme some help getting this up to a Top 20, or where to slim it down to a Top 10, and/or which are your top Top reasons, and/or bottom Top reasons, for or against, Java or Python, or dynamic scripting languages in general?!

On Frameworks vs Toolkits

initialise()

In response to a comment by one of newest heroes Michael Bushe (eg. of EventBus fame) to my article Enhanced DTs 1, i wrote an essay of sorts, which i repeat below. Cos i was trying to distill my thoughts about some quite gooey stuff, and I can only think by writing eg. code and words about code. But then i am mental. "Quite literally. Only joking, that wouldn't work of course." heh heh.

Also to the point, that blog entry was my first correct move in breaking up a long article (becoming more unmanageable by the day) into a series of byte-sized chunks, much like breaking up an unweildy framework into a set of light and fluffy toolkits.

In a postscript to that article, i mentioned another heffalump article that had become quite unmanageable, quite literally, and i was squashing that after three months of work, d'oh! And rewriting it, as Gooey Beans (my online vanity non-book), Woohoo! "What? You were asking if i was writing a book? Yes, actually i am, so..." hee hee. Because for me writing a toolkit or wha'ever, and writing an article about a toolkit, are two intertwined exercises. Check it.

essay.run()

Writing an integrated framework where everything is tightly coupled, decreases its general usefulness. If it's a bag of tools, then different people can pick and choose which tool(s) they might or might not want to use, to give them some added convenience in some situtations, where it works for them. Hang on, i'm sure i'm quoting this verbatim from what someone else said that i read very recently?!

Also from an article-writing side, one should be able to explain and demonstrate individual aspects of the framework in isolation, as independently useful toolkits, eg. beans binding, actions, and what-have-you. Because if you can't explain the software to someone in byte-size chunks that they can play with and understand, then that also decreases its general usefulness.

So i want to try to separate the "framework" into more discrete toolkits, that can be used on their own. For instance maybe you want to construct a panel using Matisse, but matisse doesn't have beans binding (yet), so you want to use binding for that, ie. Presentation Model pattern - which i love, especially now that i know what it's called :)

Actually quitegooey just started for dinky webstart demos, then i thought to use it as an experimental (minimal) framework - an R&D exercise actually, to keep me on my toes and able to contribute to the discussions on JSR295 and 296. Writing articles is for me a design exercise. I find when i write articles, i'm standing back and can spot design flaws and see areas for improvement. So the writing process for me is a most important reflective design exercise.

On the issue of using less reflection. I have a love-hate relationship with reflection, and with annotations. It's so tempting and easy to overuse these shiny things. So finding the balance is hard. I think i've found a better balance in the past few days, and i'll be writing it up of course, and publishing it very soon, in byte size chunks :)

The other difficult balance, is trying the keep the application code more concise, more straighforward, and more agile (to changing domain requirements, and refactoring) - vs the simplicity, transparency and flexibility of the framework classes - which maybe we should call a convenience library that gets reused by most of application classes, to keep them agile from a domain/business/logic programming perspective. But frameworks tend to become a straight-jacket, which is my pet hate!

My personal silver bullet is that the laws of um, physics, or the theory of complex systems or something, dictate that it's logical that the complexity of a class and its methods can only be reduced by increasing the number of classes (and/or methods), if mass (functionality) aint gonna be destroyed!?

So i've decided to bite that bullet and increase the number of classes, and use reflection and annotations in hopefully a more balanced way, to drastically simplify the framework classes (if not the application class count), to reduce the corresponding magic happening behind the scenes, and simplify the (individual) application classes, while still keeping them refactorable. In short, to find beauty in simplicity.

Most programmers aren't gonna like it cos so many classes, and i don't like it much (yet). But i do believe in simplicity and clarity, all round, with no magic black boxes. I want an application which is totally recognisable as a traditional Swing application, where the "framework" just smooths over some rough edges eg. actions, configuration, and beans binding to enable presentation model pattern. And you can pick and choose when, where and which rough edges to smooth over, or not, without your application classes looking totally different when they are using some part of the framework, or not.

So i'm arguing in favour of simplistic convenience toolkits for different aspects of an application, that you can opt in - rather than an over-arching framework that contains your application like a um, straight-jacket. It would be a framework only in the sense that the toolkits are "internally consistent," ie. from the same toolbag, rather than a hodge-podge of toolbags.

Actually the most crucial issue for me is toolability and refactoring. I mean the basic IDE stuff like auto-completion, renaming, and navigating code. I gotta have it! So i really don't like string references. So for example, my current thinking is that every view class has a "properties" class, and every presentation model class has a "bean info" class (to refer to its properties). All this just to avoid string references! I liked annotations as a way to get around string references. But i lost my balance there i think, and i'm trying to strike a new balance.

Enhanced DTs Extract 2: The Boiler Room

Here is an extract from an upcoming article, called "Enhanced DTs" about EDT "boilerplate" programming, which i'm publishing in smaller more manageable doses. (Manageable for me.)

It starts off looking at moving our boilerplate sideways into a separate class, which we present here, and then later we'll look at using CGLIB's interceptor mechanism (which CGLIB calls an "enchancer," hence the name of the article). On the way, we explore some other interesting EDT stuff like Foxtrot.

Enter the Boiler Room.

Pulp Dictionary: Top Ten Reasons to choose Java over um, C#

1. Beauty. Let's face it, using uppercase for method names is mental.
2. Free enterprise stacks, free frameworks, free IDEs, free everything! Buy now pay later.
3. java.net, jcp.org - you can brew Java.
4. Java is opensource - you can brew your own java.
5. Java is supported by all vendors, except Microsoft. So that's two reasons in one ;)
6. Swing, the sweetest GUI'est thing :) Just add Webstart.
7. Java runs Java, JavaScript, Ruby, Python and VisualBasic. And maybe a few more by the time you finish reading this ;)
8. Java runs on Linux.
9. Java runs on MacOS.
10. Java runs on your cell phone.

Please comment! Of course please don't be abusive towards other people eg. "Geoff, I'm going to rip your head off cos i don't like your head." (As in Withnail and I :)

Top Ten Reasons to Bury Digg and Get your Daily Dzone

1. No more titles like "AWESOME WEBSITE WITH PICTURES"
2. Dzone is an awesome website with awesome pictures of other awesome websites! If you hover over the picture, it pops up an awesome bigger picture!
3. You can customise how many articles to show on one page eg. a lot. I really do digg this feature. This should be number one.
4. Mmmmm.... software.
5. You only need 4 votes. "So you saying i've got a chance?!"

What do you digg the most about dzone, and/or where would you like to see it improve (let's give those okes some constructive whatsit) and/or what don't you digg about digg?

Gooey Beans Extract 1: Resource Map

Going forward this article will be updated and posted to the following permalink. It's the first part of my work-in-progress, um, online book, woohoo! It's a preachy scifi/fantasy online book on how you could rewrite your database application using Swing. "Eet's nice." It's gonna be whatsit, creative commons, partly because it's not gonna be worth the, um, paper its not written on. Check it out.

Your Daily D-zone

dzone.com is helluva well done. In my book it's got the critical mass already to rapidly become the top developer site on the internet.

I confess i've been submitting my own blogs to dzone.com - at least the ones i think are the most likely to get some votes - for whatever reason ;)

And as a matter of course voting for any and every java.net weblogger posting i see there, oops, that finger keeps slipping ;) Obviously i'm gonna vote with my heart (Java) and for my community colleagues (java.net)

What do you reckon is "good" behaviour in this new Web2.0 world? Where do you draw the lines between Commendable, Ok, Shaky and Dodgy?!

Mmmmm.... Twisted Perverted Thingymajigs

Someone asked, "Do you really need a persistent layer?" Got me to musing.

We all know that the right way to do things, like software program thingyies, is... Use Hibernate, or JPA. Use JEE containers (Spring or EJB3). Expose your middle-tier with minty EJB3 WS-* webservices, or yummy Apache Axis2. Etcetera. Hey you, preachy guy, shuddup already with all those goddamn rules! Mmmmm... rules, sweet breakable rules...

Anyway this is actually an architecture article. Actually it's a joke. Cos I always like to cloak any serious topic as a flagrant joke. I really hope no one ever takes anything i say seriously?!

So i decided on an architecture for aptframework. Which is my playground where i can just write frameworks all day and not ever actually achieve anything useful, woohoo!

And the winner is... Swing for the database-frontend client. Cos i love programming in Java. Ok I use HTML and CSS for articles, but not for anything serious! ;)

And REST for the transport, ie. XML over stock-standard HTTP, to transact with the middle-tier. And for the persistence framework? Nothing! And for the database? Nothing!

Yes, you heard me right, ladies and gentlemen. As much as i love SQL (and i'm seriously in love with databases and SQL, ask my girlfriend, she's so jealous that to her JDBC is a four letter word, and SQL is a three-finger salute) - so as much as i love SQL and PostgreSQL, and HSQL, and JavaDB, and anything remotely to do with SQL and JDBC, i'm saying, it's so 80s man, and this is the new millenium. You know, i hate progress, just when you start digging something, something else comes along and makes it yesterday's news, D'oh!

But how can you write a database application with no database? You guessed it, something along the lines of prevayler.org. Just not that, i wanna try roll my own. Why? Because i'm not gonna miss out on ALL the fun! Besides i got nothing better to do. And the best part is, there is still a database, eg. you gotta persist the RESTful XML transactions, and of course take snapshots of your "cache" aka database aka HashMap. Mmmmm, i get to write another crumpled up JDBC framework, woohoo!

But who would be mental enough to use this in production? Well apparently people are interested. Check out this podcast.

"John Davies on the Investment Banking Technology Stack." at TheServerSide.com

OK, i'm keeping a client waiting, gotta go now, kay bye.

Ps. I nominated myself for JCP. Embarassing. I dunno what possessed me. Please vote for Doug Lea, I'm certainly gonna! Mmmm... java.util.concurrency :)

This work is licensed under a Creative Commons License.