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.

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.

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 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

• 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

Limiting visibility of Commands

A powerful feature of the Commands framework is that you can declare in the plugin.xml when a Command should be visible (or rather when specific menu contributions should be visible) and when it should be enabled. This is done by using what is called core expressions.

Simple visibleWhen definition

Let us take a simple example first: we want to limit the Annotate eBook command (from the example in Part Two: Quick Review) to only show in the context menu if one item is selected in the view. If no item is selected, or more than one, it must not appear in the menu.

Eclipse.org Wiki on mapping from old to new menu contribution extension points

Enough said.

]]> http://blog.richclientgui.com/?feed=rss2&p=50 0 http://blog.richclientgui.com/?p=18 http://blog.richclientgui.com/?p=18#comments Mon, 01 Jun 2009 21:21:37 +0000 herman http://blog.richclientgui.com/?p=18 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.

]]> http://blog.richclientgui.com/?feed=rss2&p=18 0 http://blog.richclientgui.com/?p=15 http://blog.richclientgui.com/?p=15#comments Mon, 01 Jun 2009 09:52:02 +0000 herman http://blog.richclientgui.com/?p=15 Quick Review: Defining a Command

In this blog I just want review the basic definition of a command by adding an additional Command to the example application using the steps defined in Part Two of the series on Eclipse RCP Commands.

We already have an Open eBook command that we made visible in the File menu of the MyReader application. Now we want to another item to the File menu, as well as to a context menu, to allow the user to annotate an eBook. Let us call this the Annotate eBook command. So let us follow the same eight steps we did for the Open eBook command.

Step 1: Create RCP application

Done already (I assume you are working from the example in Part Two.)

Step 2: Add org.eclipse.ui.commands extension to plugin.xml.

Done already. (see step 2 of previous blog)

Step 3: Declare Annotate eBook command.

Editor keys

Navigation keys

Mouse tips