The makers of the best Java IDE have just announced that they are open-sourcing their IntelliJ IDEA product and offering a community edition for free now. You can read about it here (The Most Intelligent Java IDE — Now Free and Open Source).

We would like to take a minute to personally update you on the progress of our book. Although we are running behind the originally estimated release date, the end product will be a much better learning experience. From the beginning we have been continually refining the book and have taken the great feedback we’ve received to align the book more closely to your thoughts and insights. If you are receiving this letter and were part of the reviews, THANK YOU! Much of the feedback received, all helpful, really matched with how we (the authors) were feeling and helped us to really home in on what we felt would be important to include. Here are just some of the things that can be expected out of the new and improved Flex on Java.

Developer accessibility
When we started the Flex on Java journey we wanted to write a book that would assist Java developers in refactoring Java applications with the richness of Flex. Unfortunately, the sample application wasn’t a good fit for everything we wanted to teach and was absorbing too much of our time trying to make it work properly for the readers. The sample application was an open source product that was not easy to download, build and go. This issue caused us to rethink our approach and we turned to Matt Raible’s AppFuse framework that is aimed at helping developers build applications quickly and efficiently. AppFuse makes deployment and creation of the sample application a breeze and also opens the door to developers who are new to Java. It allowed us to focus more on the topic of integrating Flex with Java while broadening its audience to those who are not Java or Flex gurus.

Hit the ground running (faster pace)
The free chapter available will become an introduction to the book and chapter 1 will now get readers rolling with development on the first page. Chapter 1 will begin with developing the server-side application with the AppFuse framework and then quickly begin integrating Flex in chapter 2.

Deepening focus on Flex integration with Java
The faster tempo and more narrow focus on the topic of Flex and Java integration allows us to quickly go deeper in that topic. We will discuss how to use BlazeDS to connect to the Java server-side including POJO services, Spring services and Spring security in more detail. We will also include working with real-time JMS applications utilizing the Flex and Java APIs.

More focus on scalable frameworks
Good developers move from technology to technology and look for frameworks that allow them to avoid the common problems when designing an application. Frameworks for doing both dependency injection for creating loosely coupled applications and Model-View-Controller (MVC) will be explored in more detail. Frameworks such as Spring ActionScript, Cairngorm, and Pure MVC (and possibly others) will be demonstrated.

House cleaning
There are other topics like building the application with Ant and setting up continuous integration that are important but not part of the main gist of the book, so we moved those topics into the Appendices of the book. There are other housecleaning items that are being performed to make this the best book possible on integrating Flex with Java.

We hope that you will be delighted with the upcoming changes to the book. Please feel free to provide us with any feedback you may have for us. Thanks again!

Sincerely,
BJ Allmon and Jeremy Anderson
Authors of Flex on Java

Unless you’ve been hiding under a rock for the past few years you’ve probably heard of Java’s much hipper cousin Groovy. In this presentation we’re going to begin to explore the Groovy language from the ground up through a series of unit tests. We’ll start with some of the very basic concepts such as Strings, collections, looping, conditionals, exception handling, truth and introduce you to closures. With any luck we’ll cover enough of the basics to prepare you for future presentations where we’ll start to dive into the Grails framework and look at more advanced Groovy features such as meta- programming and building DSLs.

Presenter Bio: Jeremy Anderson is a software craftsman for Pillar Technology Group, an Agile consulting firm in the Great Lakes area. He is a self- proclaimed autodidact, constantly tinkering with cutting edge technologies such as Groovy, Grails and Flex. He’s been developing web-based applications on the JVM in one shape or another for over 5 years. He’s currently co-authoring a book on integrating Flex with Java for Manning Publications due out later this year, and even occasionally finds time to write on his blog. When he’s not sitting behind a keyboard hacking away at code you can usually find him out on the single-track on his mountain bike or sometimes even on foot.

In the morning I got the opportunity to sit with Corey Haines and a C++ developer (whose name escapes me right now) who was trying to learn Java for a new job.  Though we didn’t get very far into the problem domain we did have some very good discussions around testing and how in this case and in most we should be testing the behavior of the class rather than trying to assert on the state it contains, as well as how much to test.

After lunch it was now time to dive into doing some Ruby, which is what I was looking forward to.  I’m starting to do more and more Ruby on the side, and this was definitlely stepping out of my comfort zone to try and improve my Ruby-fu.  We were first treated to a Kata performed by Corey Haines, just a short demonstration of the process of spec, write code, spec, write code, etc.  I could tell that many folks in the room could appreciate the lesson, but would not be able to duplicate it themselves, which I believe is something we’re going to try to improve for the next CodeRetreat.

Next it was time to start pairing on implementing some of the Game of Life in Ruby.  Chet Hendrickson had the great idea of setting some random time to work on the codebase and then when that time was up, we throw away the code and start over.  Brilliant in the fact that now we were able to “act in spite of fear” as Patrick had spoken about in the morning.  For the first round I paired with Nayan and somebody else, who again I’m horrible with names so I can’t remember who it was.  We did manage to get some working specs done in the time we had, but I feel like we spent too much time trying to decide how we were going to implement it.  Next I got the opportunity to pair with J.B. Rainsberger and a couple of other guys.

When it was all said and done, we had our retrospective and adjourned to the bar across the street.  The discussions continued into the night ending with Patrick, J.B., Corey, Dan Davis, Nayan and myself trying to solve the worlds problems.  I am looking forward to the next CodeRetreat which will hopefully be next month sometime in Cleveland, OH and the possibility that Corey may swing through Grand Rapids, MI on his pair programming tour and get the opportunity to sit and pair with him again on some Ruby stuff that I’ve been working on.

My co-author (BJ Allmon) and I had originally intended to leverage an existing application that we would refactor to use a Rich Client interface so that the experience would more closely resemble the audience we were originally targeting; the Java developer who would be tasked to integrate Flex with their existing application.   So after much thought and some suggestions from some co-workers, we decided on XPlanner would be a good candidate.  XPlanner was a project that hadn’t seen any real development in a couple of years, it’s infrastructure was not chosen with Flex in mind, and it was a sample application that we really wanted to make work.

Unfortunately the more we tried to make XPlanner work with Flex, the more we realized this was a bad idea.  The SOAP implementation had to be tweaked because for some reason when doing inheritance with Axis the ordering of the elements in the SOAP response are out of order, which screws up Flex’s parsing resulting in some elements being returned as null when unmarshalling the objects in ActionScript (http://bugs.adobe.com/jira/secure/attachment/17509/Flex3Bug.txt).  That was fixed fairly painlessly but once we got to the point where we were attempting to integrate with BlazeDS we quickly learned that most of the functionality we needed to populate the screen was not exposed as a service, but rather many of the CRUD operations were implemented in JSP custom tags, so we were forced to have the reader implement those in order to follow along.  It was becoming apparant that this wasn’t going to work out.

After much reflection over the holidays, I had come to a solution.  We would remove XPlanner from the book as a sample application, even though I was dreading the thought of having to build up a sample Java based web application from scratch so late in the game.  I was longing for some sort of framework that would help me get a web application up and running, and quickly, kind of like Grails but for Java and not Groovy.

Then the answer came to me, AppFuse.  For those of you not familiar with AppFuse, it’s basically a skeleton Java web project that provides many services for you out of the box.  You then plug in all of your application specific code and build on top of AppFuse to create your application.  This was the answer I needed.  This also allowed us to now address one of the other comments that we received from our review; our book had assumed some high level of Java and Java web application knowledge effectively alienating the Flex developer who wanted to break into Java web development on the back-end.  It also allowed us to not stray too far from our original goal of an existing application for the basis of a sample application.  Even though we’ll now be building up the Java portion of the sample application in our book instead of using an existing one, by leveraging AppFuse we’re following many best practices for Java web development that make no assumptions about the view technology being leveraged, and developers with existing applications they want to refactor should easily be able to adapt anything in the book to their specific environment.

I must admit that I’m getting very excited about this new direction, I had rediscovered AppFuse which had played a role in me learning Spring and Struts, and helped me to refine my views on what good Java web application architecture consisted of.  Even though we’ll now have to refactor half of our book to accomodate this new sample application, I’m confident that it will not only improve the quality and clarity of the book, but it will also open up the book to a whole new audience that we weren’t targeting before.

Soon after I began spiking the sample code for our application, I discovered that a bug in the way Apache Axis handles SOAP inheritance would force us to not be able to connect to the Web Services without some modifications.  This is not including all the changes we would need to make to integrate the BlazeDS server with XPlanner so we could take advantage of the AMF binary protocol.  So we were forced to either host a modified version of the XPlanner sources ourselves, detail the changes that must be made in our book, or attempt to contact the XPlanner maintainers to get the changes introduced to the main project.  I really didn’t like the idea of forking the project, and felt that providing a patch and making the reader apply that patch before following along with the code examples was less than desirable also.  So I decided to attempt to contact the project maintainer, and after a couple of unsuccessful attempts I finally heard back from the maintainer Jacques.

So to make a long story short, it looks like I may be taking over maintenance for the XPlanner project.  I am currently working with Jacques to figure out what needs to be done in the short term to get the latest release out the door, which is over 2 years in the making.  I’m very excited about the opportunity to breathe some life back into the XPlanner project, and it would appear that the direction that I envisioned for XPlanner falls in line with the direction that Jacques was hopeful to take before other commitments tore him away from it.

How we got here is kind of an interesting story. I’ve always been a big fan of RIAs and had looked at Flex a few years back in one of my “I hate HTML” phases and really fell in love. Unfortunately the price tag was really expensive and could never show a ROI on this really cool framework that provided such a rich user experience. Fast forward a couple of years and Adobe has acquired Macromedia, and decided to open source the Flex Framework as well as create an open source fork of their LiveCycle Data Services and now it is possible to do Flex development without spending a dime. So I decided to pick up a Flex book and re-acquaint myself with RIAs, only to struggle to find a good title that would show me how to integrate Flex into my everyday job as a Java developer.

A few months back I had somehow gotten on Manning’s list of people they call on to do manuscript and proposal reviews, and I had reviewed a proposal on Flex and AIR, and it looked interesting. Come to find out the authors pulled out at the last minute, and they were looking for someone to write a title on Flex. So, for whatever reason, I’m still not quite sure exactly why, I opened my mouth and volunteered. After a couple of exciting conversations with the publisher about what I thought would make a good Flex book, I decided to recruit BJ and put together a proposal.

Keep your eyes peeled for the MEAP to show up on Manning’s site in the near future. In the meantime I plan on blogging about the experience, when I’m not up to my ears in writing this book.

In 2002 Macromedia used the term “Rich Internet Applications” (RIA) to describe the next generation of web applications that have all of the benefits of a traditional desktop application, with the flexibility of being deployed via the Internet.

However, it’s 2008 and RIA has not been able to penetrate the business application sector with any real success. The old days of RIA are history. (Maintenance nightmares, weird or no unit testing, and little friendliness toward other agile developer practices.)

With a RIA framework like Adobe Flex it’s now possible to unit test RIA applications and even write tests first. It’s possible to connect up to a CI server just like server-side code and pick up coverage stats. It’s possible to evolve a simple design incrementally and emergently.

The speakers will model how to make standard agile development practices work in the RIA world: Refactoring, Test First Design, Simple Design, Continuous Design, and Continuous Integration & Automated Builds.

The bottom line is many businesses have invested much time and money into their existing applications and their staff. For this reason, this session will guide the attendees on how to refactor an existing web application with familiar server-side technologies. We’ll show how to integrate Flex into existing applications in order to build a next generation application that will delight users.

Rather than trying to teach the basics of Flex, the speakers will demonstrate how to develop robust applications leveraging the Flex framework in concert with enterprise technologies like Java. These applications can be deployed not only to the web but also to the desktop using the Adobe Integrated Runtime (AIR).

 

Process/Mechanics

 

Refactoring to RIA’s will be a demonstrative (tutorial-like) session geared towards Java developers that would like to refactor existing applications in an agile way. Test First, CI, and other friendly agile practices will be key in making this possible.

The session will consist of live code and practice demonstrations leveraging an already existing application. Requirements for creating a new rich client interface will be explored and code will be refactored in a Red/Green/Refactor manner.

public class SomeCustomTagTest extends TestCase {

    private SomeServiceInterface mockService;
    private SomeCustomTag someCustomTag;
    private MockServletContext mockServletContext;
    private MockPageContext mockPageContext;
    private WebApplicationContext mockWebApplicationContext;

    protected void setUp() throws Exception {
        super.setUp();
        // Create the mock servlet context
        mockServletContext = new MockServletContext();

        // Create the mock Spring Context so that we can mock out the calls to getBean in the custom tag
        // Then add the Spring Context to the Servlet Context
        mockWebApplicationContext = createMock(WebApplicationContext.class);
        mockServletContext.setAttribute(WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE,
                                        mockWebApplicationContext);

        // Create the MockPageContext passing in the mock servlet context created above
        mockPageContext = new MockPageContext(mockServletContext);

        // Create the mock service object using it's interface
        mockService = createMock(SomeServiceInterface.class);

        // Create an instance of the custom tag we want to test
        // set it's PageContext to the MockPageContext we created above
        someCustomTag = new SomeCustomTag();
        someCustomTag.setPageContext(mockPageContext);

        // Whenever you make a call to the doStartTag() method on the custom tag it calls getServletContext()
        // on the WebApplicationContext.  So to avoid having to put this expect statement in every test
        // I've included it in the setUp()
        expect(mockWebApplicationContext.getServletContext()).andReturn(mockServletContext).anyTimes();
    }

}

public class SomeCustomTag extends RequestContextAwareTag {

    protected int doStartTagInternal() throws Exception {

        // put some business logic here

        return SKIP_BODY;
    }

}

public void testDoStartTag() throws Exception{
    String param = "Jeremy";
    String expectedOutput = "Hello, " + param;

    replayAllMocks();

    someCustomTag.setUserName(param);
    int tagReturnValue = someCustomTag.doStartTag();
    String output = ((MockHttpServletResponse) mockPageContext.getResponse()).getContentAsString();

    assertEquals("Tag should return 'SKIP_BODY'", TagSupport.SKIP_BODY, tagReturnValue);
    assertEquals("Output should be 'Hello, Jeremy'", expectedOutput, output);

    verifyAllMocks();
}

private void replayAllMocks() {
	replay(mockWebApplicationContext);
	replay(mockCompanyQuery);
}

private void verifyAllMocks() {
	verify(mockWebApplicationContext);
	verify(mockCompanyQuery);
} 

public class SomeCustomTag extends RequestContextAwareTag {

    private String userName;

    // A setter for an attribute that will be set in the custom tag
    public void userName(String userName) {
        this.userName = userName;
    }

    protected int doStartTagInternal() throws Exception {

        pageContext.getOut().print("Hello, " + userName);

        return SKIP_BODY;
    }

}

public void testDoStartTag() throws Exception{
    String param = "Jeremy";
    String fullName = "Jeremy Anderson";
    String expectedOutput = "Hello, " + fullName;

    expect(mockWebApplicationContext.getBean("someService")).andReturn(mockService);
    expect(someService.getFullName(param)).andReturn(fullName);
    replayAllMocks();

    someCustomTag.setUserName(param);
    int tagReturnValue = someCustomTag.doStartTag();
    String output = ((MockHttpServletResponse) mockPageContext.getResponse()).getContentAsString();

    assertEquals("Tag should return 'SKIP_BODY'", TagSupport.SKIP_BODY, tagReturnValue);
    assertEquals("Output should be 'Hello, Jeremy Anderson'", expectedOutput, output);

    verifyAllMocks();
}

protected int doStartTagInternal() throws Exception {
        // Get the Spring Context from the RequestContext
        WebApplicationContext context = getRequestContext().getWebApplicationContext();

        // Get the service we want to call from the Spring Context
        someService = (SomeServiceInterface) context.getBean("someService");

        String fullName = someService.getFullName(userName);
        pageContext.getOut().print("Hello, " + fullName);

        return SKIP_BODY;
    }