Welcome to Java Joe Morgan's Web Site

Who is "Java" Joe Morgan?

I've been programming or involved with software development for over 25 years. Over the years, I've seen Information Technology move from one trend to another, all the while I've worked to keep up, like everyone else has. I also like to work at one thing until I feel I've mastered it, and has always had an affinity for user interfaces and utilities.

Throughout my career, on more than one occasion, I've had the opportunity to teach. I spent a number of years teaching Java during it's early growth years, and I used to joke that I had the perfect name for teaching Java, and quite frequently told my classes that they would be getting a "cup of Joe" for the week. In one class, one of my students began calling me "Java Joe", and the name stuck. From then on, I was "Java Joe" Morgan.

What is the DEF?

Many years ago, I became somewhat interested in multi-threaded programming, especially after the release of the Java programming language. Having very strong opinions about Object Orientation, and even stronger views on programming first and foremost with maintenance in mind, I began developing the Dynamic Execution Framework, or DEF.

Many years later, the DEF has matured and I have used it in scores of production programs. I usually just keep these things to myself, but someone who worked with me who became familiar with the utilties and the API suggested I should document and put it out for public use. So here it is. I've always put quite a bit of effort into my API documentation, so putting together the JavaDocs was quite easy. However, I didn't realize just how large this had evolved until I began writing the User's Guide.

The DEF, or Dynamic Execution Framework, is a set of Java Classes and API extensions designed to make easy multi-threaded programming, dynamic execution, and general event handling and property binding. There are many APIs and other general tools out there that do this sort of thing, but I continue to find the DEF much, much easier to use and understand, but also much, much more powerful and flexible than its competition. I think you will agree.

Benefits and Features

Why would I want such a thing?

How many times have you written an anonymous class to react to an event, or to be able to execute some method? How many times have these anonymous classes done nothing more than just call a single method? How many times have you wished there could be a better way?

Imagine never again having to write such an anonymous class. Envision your applications scores to hundreds of lines shorter because you will never again have to subclass Thread, or implement Runnable. Imagine never again implementing ActionListener, or any Listener interface again! Believe in a world where with a single line to just a couple of lines of code, you can direct any event to any method, even if that method takes arguments. Would you like to be able to setup a dynamic process, and then execute that process asynchronously?

This world exists, and with every promise you just read. If you searched through my applications, you would never find an implementation of Runnable or a subclass of Thread, though threads are firing all over the place. Looking at UI applications implemented with the DEF, there are no more implementations of listener interfaces, and, in line with MVC, the DEF allows you to bind fields within the UI to properties of a bean or controller.

The real beauty of the DEF is that you can create very powerful dynamic constructs with just a line or two of code. Less code means faster time to market. Less code means easier maintenance. Whether you are a server-side programmer a UI developer, or specialize in creating APIs, the DEF makes your life easier! Get it!

Code Comparison

What about the Concurrent API?

In the example set forth for the Concurrent API for out-of-the-box Java, this is the code they propose:

	interface ArchiveSearcher { String search(String target); }
	 class App {
	   ExecutorService executor = ...
	   ArchiveSearcher searcher = ...
	   void showSearch(final String target)
	       throws InterruptedException {
	     Future future
	       = executor.submit(new Callable() {
	         public String call() {
	             return searcher.search(target);
	         }});
	     displayOtherThings(); // do other things while searching
	     try {
	       displayText(future.get()); // use future
	     } catch (ExecutionException ex) { cleanup(); return; }
	   }
	 }
			  

Let's see. We have an interface, a reference to the ExecutorService, the Future class, and an anonymous Callable instance. They don't even bother showing you the complexity of the ArchiveSearcher and ExecutorService implementations. Not only is this code difficult to write, it is much, much more difficult to maintain. Think about how many things you need to learn about just to understand this simple example. I'm getting sleepy just thinking about it.

Now look at the code you'd write using the DEF:

	ArchiveSearcher searcher = ...
	AsynchMethodInvoker mi = new AsynchMethodInvoker(searcher, “search”, target);
	displayOtherThings();
	if (mi.hasCompleted()) displayText(mi.getReturnValue());
			  

Note how everything is taken care of by the AsynchMethodInvoker. No other class or interface or anonymous implementations are needed! There are many, many other things you can do and so much more simply than with the Concurrent API. Browse through the user manual from the download page and you'll get the idea.

Two simple questions to ask yourself? What code would you rather be writing and struggling to make syntactically correct? What code, if you did or did not write it, would you rather be tasked with maintaining?