richclientgui.com

Polymorph Systems has scheduled their two flagship Java courses for October and November this year.

The Java Intermediate course will be presented in their new training facilities in Worcester, South Africa, from 18 to 21 October.

There is an early-bird special on this course: if you register before 15 September 2010, you will get a huge 20% discount on the course fees.

The very exclusive Java Master course will run from 22 to 25 November 2010, also in Worcester.

And for those interested in the overview of the courses, read this:

Java Intermediate Course
Our Java Intermediate course is aimed at developers who feel they got a basic understanding of Java and OO, and would like to learn more about topics like multi-threading, generics, annotations, a design pattern or two, network and database programming, and a bit of reflection to round it off.
This course is extremely practical oriented, and also discuss the use of unit-testing (JUnit) and basics of logging.

This course is based on The JavaSpecialist Java SE course material. We added a lot more programming exercises and some more advanced topics.

Java Master Course
This is easily the best Java course in existence. It is meant for intermediate to advanced Java programmers, and tackle very interesting topics on multi-threading and concurrent programming, performance tuning and optimization, data structures, the NIO library and lots more.
The trainer (Herman Lintvelt) has been hand-trained by Dr Heinz Kabutz (the author of the course) in Crete, Greece, and is one of only a select few in the world that is qualified to present this course, and the only one in Africa.
This is a very intense and challenging course, and the amount you will learn is extremely valuable – to your company and your own career.
Read here why you should consider this course, and what the prerequisites are.
Students who successfully complete the course will get a certificate from The JavaSpecialists, issued by Heinz Kabutz.

Please contact us if you have enquiries about the course.

I recently got a request from my one client: “Please add logging of the time it takes to do remote service calls, with minimal impact on the existing code.”

Now I immediately thought of the Proxy design pattern.

The existing code had quite a large number of business interfaces defined, with an implementation for each one that made use of RMI to call the remote objects. I’ll spare you the unnecessary details (JAAS, etc). It boiled down to basically every public method in each business interface implementation making use of an anonymous inner class with a simple public Object run() method to make the actual call to the remote object. A lot of code to change by hand, if logging and measurement of the time it took for remote calls were to be added.

A drastically reduced business interface might look like:

package com.richclientgui.blog.delegate;

public interface SoccerScoreService {
    public int getTeamScore(String teamName);
}

In order to re-enact the work of the JAAS Subject.doAs(…) code that is involved with the actual code, I created a MockSubject class for this example, which just calls the run() method of whatever Runnable gets passed to it:

import java.util.concurrent.Callable;

public class MockSubject {
    public static <T> T doAs(Callable<T> action) throws Exception {
        return action.call();
    }
}

We add a very basic mock implementation (no real remote calls happening here…):

import java.util.concurrent.Callable;

public class MockSoccerScoreServiceImpl implements SoccerScoreService {

    @Override
    public int getTeamScore(String teamName) {
        try {
                
            Integer result = MockSubject.doAs(
                                    new Callable<Integer>() {
                public Integer call() throws Exception {
                    System.out.print("Doing some work...");
                    try {
                         Thread.sleep(1000);
                    } catch (InterruptedException e) {
                         e.printStackTrace();
                    }
                    System.out.println("completed.");
                    return new Integer(50);
                }
             });
             return result.intValue();
                        
        } catch (Exception e) {
             //for this blog, I don't care about the
             //exception handling...
             e.printStackTrace();
             return -1;
        }
    }
}

Now we can just create a simple class with a main method that calls getTeamScore(…) on an instance of MockSoccerScoreServiceImpl.

Now to add the logging…

Approach A: Use a Proxy
We can create a Proxy for the Callable, since all our calls to the server are done using Callable instances. This proxy class measures the time it takes to perform the call() method of the real Callable, and logs it to sysout.

import java.util.concurrent.Callable;

public class LoggingCallableProxy <T> implements Callable<T> {
        private final Callable<T> realCallable;
        
        public LoggingCallableProxy(Callable<T> realCallable){
                this.realCallable = realCallable;
        }
        
        @Override
        public T call() throws Exception {
                long time = System.currentTimeMillis();
                T result = realCallable.call();
                time = System.currentTimeMillis()-time;
                //find calling method, using call level of 3
                //for this example
                final StackTraceElement stackTrace
                        = Thread.currentThread().getStackTrace()[3];
                //using sysout for example, but of course
                //use proper logging in real life
                System.out.println(
                                stackTrace.getClassName()+"."
                                +stackTrace.getMethodName()
                                +" took "+time+"ms to execute.");
                return result;
        }
}

Now comes the disadvantage of using a Proxy: we now have to change all the existing code to now create the instance of LoggingCallableProxy where the Callable was used up to now. This is not so bad if you have the source code, it is just a simple find&replace, so we can be pragmatic and live with it (I’ve always wanted to use the word “pragmatic” in a blog). Our MockSoccerScoreServiceImpl class changes to look like:

import java.util.concurrent.Callable;
import com.richclientgui.blog.proxy.LoggingCallableProxy;

public class MockSoccerScoreServiceImpl implements SoccerScoreService {

        @Override
        public int getTeamScore(String teamName) {
                try {
                
                    Integer result = MockSubject.doAs(
                           new LoggingCallableProxy<Integer>(
                               new Callable<Integer>() {
                         public Integer call() throws Exception {
                             System.out.print("Doing some work...");
                             try {
                                     Thread.sleep(1000);
                             } catch (InterruptedException e) {
                                     e.printStackTrace();
                             }
                             System.out.println("completed.");
                                     return new Integer(50);
                         }
                     }));
                     return result.intValue();
                        
                } catch (Exception e) {
                     //for this blog, I don't care about the
                     //exception handling...
                     e.printStackTrace();
                     return -1;
                }
        }
}

Now we have logging of the time measurements, with minimal code impact.

However, that simple yet far-reaching find&replace operation one potentially hundreds of methods in a huge number of classes still worries me…

Approach B: use Aspects

Aspect-oriented programming (AOP) has been around for a while, and it allows us to weave in functionality without changing existing java classes. That is an extremely brief and potentially inaccurate summary, but it will suffice for this blog. Go read more about aspects and AspectJ.

First, we need to enable aspects on our project. Do this, you must:

1. Download the AspectJ Development Tools (AJDT) if you are using the Eclipse IDE (AspectJ also integrates with other IDEs).
2. Convert the project to an AspectJ project: Right-click on project, choose Configure -> Convert to AspectJ project
3. Now you are ready to start implementing aspects.

Second: change back the MockSoccerScoreServiceImpl class to now make use of the LoggingCallableProxy anymore.

Then we can implement our aspect:

import com.richclientgui.blog.delegate.MockSubject;

/**
 * This aspect will find all occurrences of the MockSubject.doAs(...)
 * method being called, and wrap that in code to log the time
 * measurements.
 */
public aspect TimeLoggerAspect  {

        // the pointcut defines what method calls to intercept
        // All calls to the MockSubject.doAs(...) method
        // (wildcards for return and param types)
        pointcut doingRemoteCalls() :
                call(* MockSubject.doAs(..));

        /* around() defines an advise that will be executed whenever
         * the doingRemoteCalls() pointcut is matched.
         * It measures the time that it takes to execute the actual
         * doAs(...)method at that point, and prints out the time,
         * class and method calling the MockSubject.doAs(..) method
         */
        Object around() : doingRemoteCalls() {
                long time = System.currentTimeMillis();
                Object result = proceed();
                time = System.currentTimeMillis()-time;
                //find calling method
                final StackTraceElement stackTrace
                        = Thread.currentThread().getStackTrace()[2];
                System.out.println(
                                stackTrace.getClassName()+"."
                                +stackTrace.getMethodName()+" took "
                                +time+"ms to execute.");
                return result;
        }
}

Now you can run your main/test class as an AspectJ application, by using the Run As -> AspectJ/Java Application menu option in Eclipse.
(Visit the AspectJ website to see how to run it from commandline or other IDEs.)

We added logging to the remote calls, without changing any existing code, by just adding one simple aspect. This is only the tip of the iceberg of what you can do with AOP.

Eclipse RCP tip:
For Eclipse RCP applications, you will need to add a dependency to the org.aspectj.runtime plug-in to your plug-in project in order to use AspectJ.

I recently blogged (on my blogger site) about my quest to find a more effective way of coding Java GUI applications. This resulted in the creation of a one-day workshop that I am very excited about.

The details from the JTraining website are:

Fast-tracking Java GUI Development
This is a great one-day workshop that discusses a number of concerns with developing Graphical User Interfaces applications with Java, and explore various ways to improve the speed and efficiency of development.

• Do you sometimes think that coding in Java is perhaps not the best way of constructing GUIs?
• Do you feel that your team should be able to develop GUI applications much faster?
• Are you frustrated with the amount of “donkey code” you are writing to implement some basic GUI features?
• Are the new team members struggling with the high learning curve of the Java GUI framework you are using?
• Are you spending more time on coding GUI behaviour than you spend on coding domain behaviour?
• Do your team find it difficult to add or modify existing features of a GUI application?

The above questions highlight some of the issues typically found when doing GUI application development. We have been specialising in Java GUI development for more than a decade, and in this time we have investigated and used a wide range of frameworks, tools and techniques to help us build GUI applications more effectively. This workshop explores a number of these options, in a highly interactive and hands-on way.

Visual GUI builder tools, code generators, UI DSLs: these are some of the topics we will investigate.

However, none of these have any meaning if a good foundation of UI development principles and practices is not embraced in a project. The workshop also aims to instil a number of important principles and practices that is a must for any good GUI development team.

I’m also giving away more detail here (I still have to finalize the content and outline, will add that to our website later):
A) discussion of frustrations & issues with “traditional” approach to GUI development using something like RCP/Swing
[interactive discussion]
B) exploration of alternatives:
* Tools (e.g. SWT Designer, Eclipse e4, etc)
* UI DSLs (e.g. Glimmer, Gryphon, XScalaWT)
* Code Generation (e.g. XText, ANTler)
[I want to demo some of the options, and allow for practical hands-on use of at least one. My current idea is that we divide in groups, and each develop a UI DSL, using something like XText, or a more dynamic language like Scala]
C) Discussion of Practices and Principles when doing GUI development, including:
- UI Design
- UI Testing
- Tool (in)dependency
- Domain Driven UIs
[This discussion will also involve a whiteboard/interactive design session (also done in groups).]

And all this will be taking place on 1 July 2010 at my new training and agile office venue in Worcester (or if the group gets to big, we’ll move to an extremely nice country lodge nearby).

Please see our training website for more details.

I have been doing a lot of work around renewing my Java courses, talking to Heinz Kabutz in Crete, creating a new website.
Why?
Because I realized I have a passion for teaching others how to become great programmers. So am starting to concentrate more on training (while still doing enough real development work to keep the balance).

I am very excited to announce three new open Java courses that are going to be presented in June/July in South Africa by me.

First we have the Java and OO Foundation course, from 14-15 and 17-18 June 2010 (16th is Youth Day), happening in Worcester, South Africa, at our new training facility there. I can recommend this course to anyone starting out with OO and Java. Most of the content comes from my friend Heinz Kabutz’s JavaSpecialist Java Foundation course.

Then we have our first presentation of the Java Intermediate Course happening from 5 to 8 July, also in Worcester. I can recommend this course to developers who are comfortable with the basics of the Java language and OO, and who wants to learn more about real life Java topics like using JUnit, concurrency, generics and annotations.

Finally we have another big first for Africa: the first presentation of the now famous Java Specialist Master Course, from 13 to 16 July 2010. All those Soccer World Cup fans out there: stay a week longer in South Africa and come attend this brilliant course, authored by Heinz Kabutz.

I am extremely excited about our new training facilities in Worcester, which we call “The Loft @ PolymorphHQ”. Worcester is only about 100km away from Cape Town, a very scenic drive over the mountains. I am planning to combine all courses presented in Worcester with a bit of wine-tasting or even game-drive experiences. We are also investigating providing special packages that include accommodation. And we will definitely work in a nice steak and some good red wine with great Java discussions one of the evenings of the course.

I also want to announce our The Loft opening special: if you register for both the Java and OO Foundation (14 June 2010) and the Java Intermediate (5 July 2010) courses, you save R7,000.

I hope to have a lot of great Java developers coming out of Worcester these next few years

If you:

• are a fast and willing learner
• are passionate about developing quality software
• are self-disciplined and self-motivating
• tired of the typical city and office life
• need more flexibility in your working day
• have experience in Object-oriented development
• have experience in Java (acronyms optional)
• are willing to either move to Worcester or work remotely with regular visits to Worcester

Then we:

• want to talk to you about contracting or permanent employee options
• want to provide training and mentoring
• want to make you part of a newly founded team that has the goal of becoming the leading Southern Africa Eclipse RCP/RAP and OSGi development team
• want to expose you not only to exciting new software projects, prototyping, and technology research, but also to interesting consultation opportunities, and unfortunately a bit of less interesting maintenance work

Email us at: jobs@richclientgui.com

When faced with a bulky problem…

you have to start digging.

Thanks to Aslam Khan for planting the term “archeology of Java” in a discussion.

This is my second blog about the Eclipse Commands framework, but actually the first one containing useful (I hope) information. I’m going to focus on the topic from a practical “using it in development” point of view, trying to keep the examples as simple as possible and the theory limited. For an updated outline please refer to the first blog in the series: Eclipse RCP Commands Part One.

Short history: the Commands framework has been around partially since Eclipse 3.0, maturing over the versions until it became quite useful in Eclipse 3.3. Some refinements in Eclipse 3.4 makes it even more appealing. I must admit, before Eclipse 3.3 I saw no reason for using Commands, and I stuck to using IActions and IActionDelegates, trying to work around their issues as much as possible (and falling into the rythm of the copy-and-paste anti-pattern in order to contribute an IActionDelegate to multiple places in a UI). No I’m trying to convince all my clients to “renew” their code to use Commands…

What are Commands

“A command is neither the presentation nor a particular behavior implementation; it is an abstract representation of some semantical behavior.” – Marc R. Hoffmann (see Article on Eclipse Commands Framework)

That’s the best quote I could find as to what a Command is. What does it boil down to? I assume (hope?) you are all familiar with the Model-View-Controller pattern, used especially when developing UI applications. By abstracting a particular piece of functionality into separate Model, View and Controller objects, the code is must less coupled, allowing more (and easier) reuse, flexibility and extensibility.

Well, the Command design is not exactly MVC, but it has the same goals in mind. It abstracts the actual business or application semantics (i.e. what is actually meant to happen from business or application functionality perspective) into this thing called a Command. Worries about how it should appear in the UI (menu contributions), or what exactly must happen on a code implementation level to execute the command (handlers) is left for later. In this way we get the same decoupling of presentation and implementation as with MVC, and thus the gain in reusability of Commands and their handlers, and increase in the flexibility and extensibility of the code, thus leading overall to code that is much easier to maintain.

Add to the above paragraph that code that is easier to maintain leads to huge development cost savings, and you’ll have a convincing argument to offer to your boss for allowing you to refactor away all the old IActionDelegates.

Ok, but what to we do with Commands?

Plain and simple: we use it to implement functions that our application can perform and make it available as menu or toolbar items so the user can invoke it.

On a more practical level

That is about enough theory for one day. Let’s get down to the bits and the bytes.

The Example

Firstly, I want to introduce my patent-pending idea for an application. Image this: you have this cross-platform application (obviously implemented using Eclipse RCP) that can actually read electronic versions of books, that we can call “e-books”. “Wow!” you say. “Amazing”. “What a novel idea”.

Let us call our bleeding edge application MyReader. You can download the source code for this blog’s version of the example.

Step 1: Create a RCP application using Eclipse 3.4 (I’m using 3.4.1) and the New Plug-in Project wizard.