Flex is gaining adoption among Java programmers and I must confess it’s a fantastic match in my experience. With Java, you get the robust server side that integrates and works with pretty much every useful technology in the enterprise and with Adobe Flex you have a super nice highly interactive rich interface for your application.

For those of you, who have similar opinion or those of you, who are wondering why I am saying such a marriage is excellent, a full day of sessions on the topic is something you want to participate in. Its another Flex Camp and this time it’s in New York City. Not to forget it has an excellent lineup of speakers. (Your truly is speaking at the event as well)

Scheduled for April 18, 2008 Flex Camp Wall Street — http://www.flexcampwallstreet.com – is a unique event that will provide practical tips, techniques and actionable advise for adoption of Flex and AIR based RIA within banks, brokerages, fund management companies, insurance firms and other financial services institutions. Sessions have plenty of emphasis on real-time updates, portal integration, hibernate integration, advanced data visualization and offline applications, so most of you may find the event extremely useful. Please read the session descriptions — http://www.flexcampwallstreet.com/session_descriptions.html — for details.

Lastly, for those who are tracking the world of Flex, the famous evangelist bloggers — Christophe Coenraets (http://coenraets.org/) and James Ward (http://www.jamesward.org/) — are going to be at the event.

Its a day long event. The cost of the event is $99 per attendee.

All other relevant information is online at http://www.flexcampwallstreet.com

I’m convinced that this blog platform doesn’t quite work. Blogs are supposed to be about random navel gazing, but instead of that I think people view the O’Reilly blogging platform as a political megaphone through which they can make themselves appear to be ubergeeks. Anyway, I’m going to continue to write here, but just know that I’m always reticent to say anything real here. Whenever I decided to say something like, “I’m sick of parsing Strings in Java” I’ll get a bunch of hate mail from people about how what I said didn’t fall in line with the expectations they had of OnJava. In addition, I’m very skeptical of the idea of “topical” blogs. I’ve never worked on a system that was in one technology. Enough self-reference.

Web Frameworks IM Log

I don’t think we have any clarity in Java Web Framework land, here’s a chat log from yesterday that has been anonymized to protect the innocent…the topic was, “What framework should we use?”

tobrien: Waffle
tobrien: GWT
tobrien: Wicket
tobrien: SpringMVC
tobrien: Struts2
tobrien: Django
tobrien: Rails
other: why not all?
tobrien: PHP
other: you should do it in all of them and then we can decide which is the most elegant
other: it should be a standalone AIR app
other: wait, silverlight
other: no. it should be a firefox extension
other: i know i know. do it in an excel macro
other: it would be more efficient. you could enter all the meta data in excel and just hit 'upload'
other: although... c++ would be faster
other: you know what, just use assembler
other: f*** it, we can do it in hardware
other: it can have a usb interface
other: win32 api?
other: too legacy. use XAML
other: wait. make it a cocoa app, dont want to be a ********
other: no, do it in a osx widget
tobrien: yo!
other: you can use javascript for those right?
other: facebook app

:-) I think I’m going to just do it in Wicket. The person I was conversing with is partial to GWT.

Adobe Fx

Here’s a fun little icon:

(Anyone heard anything about JavaFx?) I know APress published a book on it, but that seems a little crazy at this point. Adobe released a public beta 3 for Flex 3 and there’s an icon on my desktop “Fx”. That’s nice, so that’s what Ward meant when he noted that name overlap at JavaOne last year. Has Sun selected another name for JavaFx yet? Googling for JavaFX just brings up a bunch of Sun stuff, and an entertaining article from last May. Check out what Andy Patrizio wrote in May:

You know all that AJAX code you’ve been writing and tearing your hair out over as you attempt to get the JavaScript working in both Internet Explorer and Firefox? Yeah, that AJAX code (define).

It’s all going to be useless real soon.

Seriously? It’s going to be “useless real soon”. The internet “press” is crazy.

Anyone care to wager what the big announcement is going to be about JavaFX? What the new name is going to be? It was interesting when it was announced, I was impressed by C. Oliver, but I’ve also been impressed with Abode over the past year.

Tomcat Love

I’m a pulitzer prize winning author, I’ve written a few fictionalized accounts of my own experiences in Vietnam. And, my most interesting book is about my love affair with Apache Tomcat - “Tomcat in Love”. This is what happens when your name overlaps with someone much more famous and successful than yourself.

The aim of Drools (or any other Business Rules Engine) is to get knowledge out of business user’s heads and into a format where it can be copied , edited and peer reviewed , then run 24/7. Ideally, business users should be able to write these rules directly (a) to save time and (b) to reduce errors caused by a 3rd party having to to ‘translate’ these rules into code. And it saves you (as a technical person) from having to code them yourself.

Drools BRMS (Business Rules Management System) is such a tool. Easily deployed into almost any Java Web or App server, it allows users to write and validate business rules that you can then pull into your Enterprise Java Application.

Because it uses the Google Web Toolkit (GWT) , even though it is a web application (i.e. zero install on client machines) it behaves and performs as fast as a desktop one. And unlike some other (Commercial) Rules Engines, it’s free to Download and use (under the Apache licence) from the JBoss site.

And now there is a guide for business users available online. Shortly to be integrated into the existing Drools (technical) documentation a preview of the JBoss Drools BRMS guide is now available.

More Information

• JBoss Drools Blog
• JBoss Drools Homepage.
• JBoss BRMS Chapter in the technical documentation

Brett Porter has a terse branch in Maven that introduces an incrementally leaner syntax for Maven POMs. If you’ve used Maven, you’ve probably cursed it repeatedly for relying too heavily on an element only approach to XML configuration. To illustrate the problem, consider a Maven 2 POM declaring a simple dependency:

    <dependencies>
      <dependency>
        <groupId>javax.activation</groupId>
        <artifactId>activation</artifactId>
        <version>1.1</version>
      </dependency>
    </dependencies>

Brett’s terse branch is an incremental improvement. He’s changed many of the properties in a Maven POM to XML attributes. In Brett’s terse branch, the dependency declaration shown above turns into this:

    <dependencies>
      <dependency groupId="javax.activation" artifactId="activation" version="1.1"/>
    </dependency>

This is a small change, but a welcome one. Anything that can save keystrokes makes sense as my POM files have grown unwieldy over the past few months. I’m also sick of wasting book pages listing POM after POM. If you’ve ever tried to write a book about Maven, you’ll realize just how insane it is that a tool that professes to follow the “Convention of Configuration” design pattern requires so much configuration to achieve simple results. (From my Editor: “If Maven is so easy, why does it require all of this XML.”) Maybe Brett’s incremental changes are a step in the right direction? Hopefully, we’ll see more innovation in the weeks to come.

While the Maven team has made it abundantly clear that they are not interested in revolutionary changes to the Maven POM, now’s your chance to comment on the proposed format changes. If you have any ideas about how to make POMs less verbose and more readable, leave a comment on this thread.

James Ward and I put together an article on porting over an HTML application to Flex. Its published on InfoQ. We used the Pentaho BI Dashboard as the sample application in our endeavor. After reading the article you will realize the simplicity of the task and the quick gains you could get by making such a move. The source code is available for download and a copy of the final application is accessible online.

James is presenting on the same topic this week at JBoss World, with JBoss JMX Console as the example this time.

Enumerated types (enums) are a way to define fixed set of constants, so helpful in many areas of software development. In the most common case, in your Java code written for Java 5 or newer, you will use enums for int constants and replace chunks of code that look like this

    public static final int DIRECTION_NORTH     = 0;
    public static final int DIRECTION_SOUTH     = 1;
    public static final int DIRECTION_EAST      = 2;
    public static final int DIRECTION_WEST      = 3;

with something like this

public enum Direction {
    NORTH, SOUTH, EAST, WEST;
}

Then, you’ll change method definitions that look like

public void changeDirection(int direction) {
    // do something
}

with something like this

 public void changeDirection(Direction direction) {
    // do something
}

And finally, the method call will be changed too, from

ship.changeDirection(DIRECTION_EAST);

to

ship.changeDirection(Direction.NORTH);

There are a few obvious benefits from using enums over the standard int constants, such as the type safety and namespaces for example.

But we can also use enums to define other types of constants, string constants for example. You can often see examples of using enums to make a switch idiom for strings possible in Java. Take a look at the following example

        String direction = "WEST";
        switch (Direction.valueOf(direction)) {
            case WEST :  System.out.println("Go west!");
                         break;
            case EAST :  System.out.println("Go east!");
                         break;
            default : System.out.println("Go somewhere!");
        }

It prints Go west! as a result which is great.

But in order to be truly useful for string constants purpose, enums needs some extra tuning and here’s why.

So I want to pontificate about SOA in the Enterprise for a few minutes here. I, as an “enterprise” developer obviously have an opinion on this topic, but this final rant was spawned by listening to Dalibor on Java Posse speaking of OSGi in the Enterprise. I had a similar conversation with 
Brian Ehmann, the Java Posse intern, a while back. So I want to address several things.

First, I want to talk about OSGi, and why I would never allow it in “my” enterprise. In “my” enterprise I want absolute control over what every service has in its runtime environment. Indeed, as a longtime Fedora user, one of the things I loathe about its Java support is the dependency system that works just as Dalibor describes — at the OS level. The beauty of Java on the server is that applications and their API dependencies can be packaged into a single artifact (WAR/EAR) that is completely isolated from the library install or configuration of the server itself. Anyone who has dealt with install libs on Unix machines understands this. Indeed, if any two of your “enterprise apps” had to have the same version of something even trivial, like Log4J, this could become a serious problem for deployments.

Secondarily, the last thing I want is my application “updating” itself without my (or Major League Baseball’s) expressed written consent. One of the “theories” I have espoused for a long time, and indeed one of the reasons I fell in love with J(2)EE is the WAR  file, and having a singular artifact from the developers. A WAR/EAR file is an artifact that can be built by development and move seamlessly from development, to QA, staging and production as a singular, atomic unit. As soon as you introduce dynamic dependency updates in your production systems, you have lost this atomicity in terms of production bits. It is true that OSGi does not mandate this loss of atomic control, but it does encourage it.

Of course, this example has a certain narrowness of focus. Of course things within the enterprise change, but one of the advantages of a Web Services based infrastructure is low-level dependencies as I have discussed to this point are maintained independently. At the service level, of course you need to control change. In my current environment we do this by endpoint management and control. This is one of the things that strikes me as a failing of “SOA” as a “solution”. Endpoint discovery is almost never a real problem for the enterprise. Low level network services like DNS are perfectly adequate for controlling this. Barring that, in the “WS” world. simple things like controlling HTTP routing through Apache or a specialized load balancing product work well. These solutions make it easier than most “SOA” products to run multiple live versions of a service without forced deprecation as well. Sure OSGi can operate at this level for service version control, but why trust it? Why allow binary update of runtimes on servers when endpoint URIs are easier to control over time?

Finally I want to address the issues of SOA as a failed technology. Bill de hOra and Joe Gregorio have noted that SOA has reached the “assign blame” state of failure. Indeed, here on the O’Reilly network shadows of this meme have kicked around.. I want to note that SOA is still a valid idea, but much like BPM, the marketing doesn’t live up to the hype. In enterprises with “architect” staff who are fundamentally unqualified– though I don’t believe the position is unnecessary in medium-large organizations — or a technical debt load that has become unmanageable, SOA proffers no real solution to any problem. Companies selling their SOA product as a silver bullet to said architects that will eradicate said debt are doing so at their own peril. Best case, their thousands of dollar projects will be quickly forgotten failures. Worst case, these enterprises will feel scorched by the failure and never want to deal with the same companies again. In reality, the former is most likely, since the people making the decision to go with the failed technology products will keep their jobs, blaming the failure not on their own lack of understanding of the enterprise they are responsible for but the vendors. Indeed, these sales relationships mean the same vendors get to come back when the next “Silver bullet” enterprise solution is available.

Everyone using Maven should pay attention to what Don Brown is doing. He’s reached a level of frustration with Maven, and he’s decided to start working on his own branch. Luckily some people on the core Maven team have noticed and have started porting some of his performance changes back into Maven proper.

Branching, forking, whatever you want to call it… should be much more common in open source Java. Even though we use tools that support it (or do we? see my previous post about SVN vs GIT), you rarely see the discussion on a developer list that mentions someone’s branch. Hopefully people like Don will inspire more people to start forking the projects they use.

Open source isn’t about convincing a centralized “project committee” that your changes have merit, it is about decentralized innovation. Over the last few years, I’ve come to the realization that open source communities can be detrimental to innovation, real innovation comes from ad-hoc, decentralized code revolutions like Don’s. Too often, open source Java dev lists are full of noisy arguments about what to do and how to do it while building consensus. We’d all be better off if people forked first and discussed later.