Related link: http://www.topologi.com
My company, Topologi
is releasing our new product line next week. This isn’t really a pitch for the products (repeat after me “I will try! I will buy!”) but more about the particular solutions I have come up with to making a large desktop application with Java that has just as good performance as a native Windows application.
Now, let me start off by saying I don’t mean good performance in the benchmarking sense: Java programs have, if well written, just as good performance as C++ programs when they are up and running. Indeed, as Java uses SSE instructions now, benchmark performances may exceed typical C++ binaries compiled without SSE.
But a real desktop application is competitive with other resources: in particular with other applications and with the Windows virtual memory system. Users have multiple applications running, they minimise them, or quickly switch between them. Lets call poor performance in these areas suckitude.
We faced two sets of problems. The first were issues with Windows and Java:
- Slow start-up times: our application uses a ton of libraries, and even though we did lazy initialization, start-up time was just too much. The initial prototypes of the product had used custom class loaders to reduce the problem, but we abandoned them because they didn’t fit.
Instead we had tried a little reflection, lazy intitialization, and invoking many methods through BeanShell scripts.
- Java didn’t know how much memory was optimally available. It just tries to reserve as much as it can up to some limit.
- Java GC does not interact particularly happily with paging. You don’t want too multiple JVMs running unless they have quite small heaps, but if they have small heaps they are useless for decent-sized work.
- Java scheduling and memory management does not have any idea of foreground/background. They don’t have any way to act differently when the Java application is not the foreground application or when the application is minimised. Consequently, it has no built-in way to be a good citizen.
The second came from issues relating to the size of our application. The Professional Editions contained a ton of functionality, but
- Download times were becoming too long because of
the large file size. We had found we had to include our
own JRE because we couldn’t be sure what JRE the user’s
had on their systems.
- Users often bought the system for specific funtionality
- Large WIMP applications are only
for habituated power-users (sometimes called
“the Adobe syndrome” unfairly: Adobe’s interfaces
are exemplorary for reducing this problem that
in particular by moving beyond WIMP to
using floating pallettes and differentiated products,
backed up by their training programs).
Users wouldn’t look more than one menu deep to
find anything, and wouldn’t look things up in
help files even when the help was there.
Inductive, Task-Oriented GUI Design
It is that last issue that caused the lightbulb.
A few years back the practicality boffins at MicroSoft, in particular, started espousing
>inductive user interfaces.
>Jan Miksovsky says
“ I think
its most significant contribution is … that tight
constraints around the clarity of a page title can drive an interface’s
“The answer proposed by the inductive UI model is that a single task is something that can be stated
(ideally, directly on the screen) in a single concise question or
statement in natural language.“.
MicroSoft since have since moved on to
see this blog conversation:
>Who are you? Mort, Elvis or Einstein
>Inductive vs Productive UIs, and
This is probably a logical step: when you need to
elaborate tasks, you have to ask “who” before “what.”
The cynic in me wonders whether inductive interfaces
are too thin-client friendly for MS, IYKWIM?
(An check out
>this great article
to see why personas won’t work for tomato sauce.)
Inductive interfaces, wizards, typical multi-stage web-based interfaces are all task-based.
Task-Orientedness as an Architecture
The issue I set myself was
Is there a way to re-factor our existing functionality
to reduce suckitude to the same limits as native Windows
The solution I came up with was to refactor our
application as a suite of independent utilities.
Rather than kick against the pricks
of Java’s applet/servlet focus, why not accept it
and love it:
use it as the impetus for a more task-oriented
each group together three to six related tasks.
The utilities are
independent in the sense that they each can
be downloaded independently, but
each utility can launch another in the
same JVM, using a pulldown menu on the toolbar.
They are virtual utilities: they
look like independent programs but they
run in the same Windows process.
The exemplar was WinZIP: a simple
interface with a small number of toolbar buttons.
Each button would be an inductive-style
verb+type statement. We threw out menus,
though the toolbars ended up a little
Each utility launches with its own class-loader.
Each utility has a “Lauch Utility” button that
invokes whichever other Topologi utilities have
been installed: if it is the first launch of that
utility in the current JVM, the utility is
launched by its own class loader.
Closing the window of a utility does not cause
the destruction of the utility’s Java object: instead it
acts like a smart window-minimization. The utility
frees up as many objects as possible (trees,
files, etc) and hides the utility window.
Next time the utility is launched from another
utility, it comes up almost instantly.
So here is how the problems fared:
- Slow start-up times:
The initial start-up time is less, because
only the libraries needed for the utility
need to be loaded.
The time to launch a new utility from an existing one
is smaller, because there is no need to launch a new
Indeed, if the utility was previously launched then
closed but there was always some utility keeping the JVM
alive, it may open instantly.
- Java didn’t know how much memory was optimally available.
I blogged last year about this: the utilities are invoked
through a executable which calculates the optimal
- Java GC does not interact particularly happily with paging.
Using the same JVM rather than launching
others reduces the pressure that active pages will be
- Java scheduling and memory management does not have any idea of foreground/background.
Again, by keeping everything in one JVM, we
reduce the liklihood of
- Download times:
Each utility is substantially smaller:
often less than 20% of the size of the Professional
Edition. Just as helpfully,
we figured that by now most people have upgraded
to JRE 1.4.2 or JRE 1.5, so we didn’t need to
rebundle the JRE.
- Users often bought the system for specific funtionality:
Obviously the utility idea caters for this well.
- Large WIMP applications are not “intuitive”
Removing the menus, and giving a clear, small set
of tasks on the buttons makes the interface easier
to figure out.
We also simplified the help files and made them
available in the first tab.
In our performance goals from three years before,
we had a launch limits of 4 seconds to get a splash
screen, 4 second to get the application frame and
main menu, and 4 seconds to get the main GUI
items functional (4:4:4), on our target PC.
We had gone pretty well, but
load times were hindering us, and one prototypes
of a recent product we had degraded closer to 8:8:16,
which represented high suckitude. The utilities are
each about 1:3:2 for the first one launched,
0:2:2 for the initial fast lauch of one utility from
and 0:0:0 for subsequent fast launch times. Yahoo.
It is a good architecture: it matches Java’s and Window’s
natures quite well. To actually spit up the Topologi
Professional Edition completely along these lines would
take at least 20 utilities, so we started off with 5
and enabled fast launch to the simpler Mark Editor
and with several more utilities in the pipeline.
In one sense, what we are doing is moving the top-level menus to the Windows Start menu. This in effect moves up all the underlying interace objects up one level. Users select the utility (which groups related tasks) and then have the tasks staring them in the face, rather then hidden under one or two layers of menus. Similarly when switching to help files the user sees the help belonging to the tasks, rather than amalgamated help for all functionality, which requires searching and head-scratching.
The limitation currently is that fast-launching only
works from inside a utility. If you have one utility open
and launch another from the Start menu, say, you get two JVMs. I may look at having our custom launchers
find an existing JVM before launching a utility in a new one, and there may be some way to use the JDIC Windows Quicklaunch Toolbar to keep the JVM alive, but that is down the road.
I don’t know whether moving to a task-oriented, utility/mini-program approach will work on your application, but I certain commend it. It makes Java applications feel like different beasts.
Java experts often recommend custom class loaders as
the way to reduce initial loadtime. What no-one (who I have
read, at least) suggested was what I found: that to use
class-loaders successfully you have to design your program so that the user
interacts in chunks of related tasks, rather than the WIMP approach of having most functions theoretically available at the same time (which can happen as a result of removing modality from a WIMP interface, for example, in HCI jargon).
Grouped Tasks -> Virtual Utilities -> Fast Loading & smaller size -> good suckitude