Why Spaghetti Is Not Tasty: Architecting Full-Scale Swing Apps - - PowerPoint PPT Presentation

2007 JavaOneSM Conference | Session TS-3316 |

TS-3316

Why Spaghetti Is Not Tasty: Architecting Full-Scale Swing Apps

Jasper Potts SwingTeam Sun Microsystems Inc http://jasperpotts.com

2007 JavaOneSM Conference | Session TS-3316 | 2

A understanding of some of the key issues

• f building large desktop Java™ applications.

Why you need to think about these problems early on and some ways to tackle them.

What you will take away from this session

The Goals

2007 JavaOneSM Conference | Session TS-3316 | 3

My Background

• Working on Swing Team at Sun
• Nimbus Look and Feel
• Synth
• Metal & Ocean
• JTable
• Creator of Xerto Imagery
• Worked on large Swing Applications for: Banking,

GIS and Image Processing

2007 JavaOneSM Conference | Session TS-3316 | 4

The Start

• How did I end up standing here talking to

you today?

2007 JavaOneSM Conference | Session TS-3316 | 5

Agenda

• Basics
• Modularity
• Wiring
• Communication
• Conclusion
• Q & A

2007 JavaOneSM Conference | Session TS-3316 | 6

Setting the Scene

• So you have a idea of what to build
• Time to make a prototype

2007 JavaOneSM Conference | Session TS-3316 | 7

Setting the Scene

• Lets look at some common architectures

2007 JavaOneSM Conference | Session TS-3316 | 8

Passing Everything Around

Frame MainPanel Copy Action Quit Action Paste Action Editor Save Action

2007 JavaOneSM Conference | Session TS-3316 | 9

Static or Singleton Core

Frame MainPanel Copy Action Quit Action Paste Action Editor Save Action Application Core

2007 JavaOneSM Conference | Session TS-3316 | 10

Static or Singleton Core

Application Core

2007 JavaOneSM Conference | Session TS-3316 | 11

Pass the Core Around

Frame MainPanel Copy Action Quit Action Paste Action Editor Save Action Application Core

2007 JavaOneSM Conference | Session TS-3316 | 12

Pass the Core Around

Frame MainPanel Copy Action Quit Action Paste Action Editor Save Action Application Core Frame MainPanel Copy Action Quit Action Paste Action Editor Save Action Application Core

Big Application

2007 JavaOneSM Conference | Session TS-3316 | 13

How to draw the lines

Applications Sizes

• When is a application small, medium, large?
• Let’s look at some example applications

2007 JavaOneSM Conference | Session TS-3316 | 14

Application Sizes: Old UK Maps

2007 JavaOneSM Conference | Session TS-3316 | 15

Application Sizes: Aerith

2007 JavaOneSM Conference | Session TS-3316 | 16

Application Sizes: JEdit

2007 JavaOneSM Conference | Session TS-3316 | 17

Application Sizes: JAlbum

2007 JavaOneSM Conference | Session TS-3316 | 18

Application Sizes: Xerto Imagery

2007 JavaOneSM Conference | Session TS-3316 | 19

Application Sizes: NetBeans™ Software

2007 JavaOneSM Conference | Session TS-3316 | 20

Source: Simple line count of Java,XML,MF,C,CPP,H files including comments and excluding test code.

Application Sizes

2007 JavaOneSM Conference | Session TS-3316 | 21

Source: Simple line count of Java,XML,MF,C,CPP,H files including comments and excluding test code.

Application Size Breakdown

50,000

2007 JavaOneSM Conference | Session TS-3316 | 22

SPAR - A Swing Rich Client Platform

• At a point Imagery got to big for a simple model
• I did a lot of research and put together the best

technologies of the time

• The SPAR framework was born

2007 JavaOneSM Conference | Session TS-3316 | 23

Agenda

• Basics
• Modularity
• Wiring
• Communication
• Conclusion
• Q & A

2007 JavaOneSM Conference | Session TS-3316 | 24

Modularity

• The idea of breaking an application down into

manageable modules is well known.

• It has been tackled in the server space by

frameworks like: Java Platform, Enterprise Edition (Java EE platform)

• The main form modularity takes in desktop

applications is plugin frameworks.

2007 JavaOneSM Conference | Session TS-3316 | 25

Modularity: Solutions

• Today
• OSGi [Java Specification Request (JSR) 291]
• Eclipse Equinox
• Knopperfish
• NetBeans™ Platform
• Platonos
• JPF
• In the next generation Java SE Platform
• JSR 277: Java Module System
• JSR 294: Improved Modularity Support in the Java

Programming Language

2007 JavaOneSM Conference | Session TS-3316 | 26

Modularity: Platonos

http://platonos.sourceforge.net

• Small light weight plugin framework
• Not as fully featured as OSGi etc but smaller and

simpler to understand.

• Could be a good choice for medium sized

applications

• Currently on Version 1.0 version 2 in the works
• Good support on the mailing lists

2007 JavaOneSM Conference | Session TS-3316 | 27

Modularity: JPF

http://jpf.sourceforge.net/

• Another light-weight plug-in framework
• Derivation from Eclipse plug-in framework before

it went OSGi

• Not one I have had personal experience with but

looks like there are people using it for serious applications

• Recent releases of 1.0.1 and 1.5.0 on 03/07/2007

2007 JavaOneSM Conference | Session TS-3316 | 28

Modularity: NetBeans Platform

http://platform.netbeans.org

• Robust well proven framework
• Many applications out there using it
• Good tool support
• New Book on NetBeans Platform

Rich Client Programming: Plugging into the NetBeans™ Platform (ISBN: 0132354802)

2007 JavaOneSM Conference | Session TS-3316 | 29

Modularity: OSGi

http://www.osgi.org

• Huge industry support for the specification
• Widely used in many industries such as:

cars, cell(mobile) phones, industrial automation, building automation, PDAs, servers, and of course desktop applications with Eclipse and its RCP apps.

• Has good support for native code in plugins
• Links:
• There is a good presentation on Spring and OSGi that covers the basics of

OSGi http://www.bejug.org/confluenceBeJUG/display/PARLEYS/Spring%20OSGi

• A good reference to OSGi API is the official spec:

http://osgi.org/osgi_technology/download_specs.asp

• The Eclipse OSGi implementation: http://www.eclipse.org/equinox/

2007 JavaOneSM Conference | Session TS-3316 | 30

Modularity: JSR 277 and 294

• JSR-294 (superpackage)
• Defines linguistic unit of modularity
• Information hiding and separate compilation
• JSR-277 (Java Module System)
• Defines deployment unit of modularity
• Versioning scheme, new distribution format, repository,

and runtime support

• In the future, existing frameworks like OSGi and

NetBeans software will be able to be take advantages of these new core functionality.

Offer first-class modularity, packaging and deployment support in the next generation Java SE platform.

2007 JavaOneSM Conference | Session TS-3316 | 31

Modularity in the Spar Framework

• Provides modularity though plugins
• Uses Eclipse OSGi implementation as its engine
• In OSGi a plugin is called a Bundle
• What is a Bundle:
• Basically a bundle is just a Jar file with some extra

attributes in its manifest file

2007 JavaOneSM Conference | Session TS-3316 | 32

Modularity: A OSGi Bundle Manifest

Manifest-Version: 1.0 Bundle-ManifestVersion: 2 Bundle-Name: SPAR UI Bundle-SymbolicName: com.xerto.spar.ui; singleton:=true Bundle-Version: 1.0.0 Bundle-Vendor: XERTO Bundle-Activator: com.xerto.spar.ui.internal.SparUiActivator Export-Package: com.xerto.spar.ui, com.xerto.spar.ui.actions, … Require-Bundle: org.eclipse.core.runtime, com.xerto.spar Bundle-Classpath: ., swing-worker.jar Eclipse-AutoStart: false Spar-Runlevel: 10

2007 JavaOneSM Conference | Session TS-3316 | 33

Modularity: So what does this give you

• Simple self contained building block
• Forces you to think about contracts(links)
• Separate public API from any implementation
• Makes it easy to breakdown work
• Defined dependencies
• Simple start-up ordering

2007 JavaOneSM Conference | Session TS-3316 | 34

Agenda

• Basics
• Modularity
• Wiring
• Communication
• Conclusion
• Q & A

2007 JavaOneSM Conference | Session TS-3316 | 35

How do you connect all these plugins together

Wiring

• Three types of connections:
• First is Class Exports
• Plugin ‘A’ exports a public API that is used by

plugin ‘B’

• Example: ‘A’ contains some Swing components

like a Image Viewer Panel which ‘B’ is then using in its UI

2007 JavaOneSM Conference | Session TS-3316 | 36

How does one plugin use another plugin’s classes

Wiring: Class Exports

• Class exports are provided by the core of OSGi
• Plugin ‘A’ who provides the class needs export that

classes package in its manifest:

Bundle-Name: Plugin A Bundle-SymbolicName: com.abc.A; singleton:=true Export-Package: com.abc.components.imagepanel

• Plugin ‘B: needs to depend on ‘A’ in its manifest:

Bundle-Name: Plugin B Bundle-SymbolicName: com.abc.B; singleton:=true Require-Bundle: com.abc.A

2007 JavaOneSM Conference | Session TS-3316 | 37

Wiring: Class Exports

import com.abc.components.imagepanel.ImagePanel; public class ExmpleB { private ImagePanel ip = new ImagePanel(); … }

2007 JavaOneSM Conference | Session TS-3316 | 38

2nd form of connecting plugins together

Wiring: Extension Points

• Plugin ‘C’ has a extension point that plugin

‘D’ provides an extension for

• Example: ‘C’ has extension point for image

readers and ‘D’ provides a implementation

• f a JPEG reader to ‘C’
• Are extension points legacy?

http://www.eclipsezone.com/articles/extensions-vs-services/

2007 JavaOneSM Conference | Session TS-3316 | 39

Wiring: Extension Points

• This is how one plugin provides a way for another

to extend it.

• Extension Points are not part of the core of OSGi

they are added functionality by the Eclipse implementation.

• Extensions and Extension Points are defined in a

XML file called “plugin.xml” in the root of the plugins(bundles) jar file.

2007 JavaOneSM Conference | Session TS-3316 | 40

Wiring: Extension Points

For plugin ‘C’

<plugin> <extension-point id=”imageReaders” name="imageReaders"/> </plugin>

For plugin ‘D’

<plugin> <extension point="com.abc.C.imageReaders"> <format name=“Jpeg” ext=“jpg,jpeg” bean=“JpegImageReader”/> </extension> </plugin>

2007 JavaOneSM Conference | Session TS-3316 | 41

Wiring: Extension Points

For plugin ‘C’

IExtensionRegistry extReg = Platform.getExtensionRegistry(); IExtensionPoint extPoint = extReg.getExtensionPoint( "com.abc.C", "imageReaders"); for (IExtension ext : extPoint.getExtensions()) { for (IConfigurationElement element : ext.getConfigurationElements()){ registerImageReader( element.getAttribute("name"), element.getAttribute("ext"), (IImageReader)springRegistry.getBean( extension, element.getAttribute("bean")) ); } }

2007 JavaOneSM Conference | Session TS-3316 | 42

Wiring: Extension Points

• In the SPAR framework I have integrated Spring IOC

(Inversion Of Control) with the Eclipse OSGi implementation.

• What does Spring IOC bring to SPAR?
• IOC is a neat way of connecting things without direct coupling.
• A class that is using a interface doesn’t need to care about where

the implementation comes from.

2007 JavaOneSM Conference | Session TS-3316 | 43

3rd form of plugin connections

Wiring: Services

• Plugin ‘C’ provides a service that is used by

plugin ‘B’

• Example: ‘C’ could provide a image reading

service that can load up images in any of the formats provided to it though its extension point. ‘B’ Could then use that service to load a image to display in the Image Panel from ‘A’

2007 JavaOneSM Conference | Session TS-3316 | 44

Wiring: Services

• Spring IOC can be very simply thought of as two parts:

1. A Map<String,Object> of beans called a BeanFactory 2. A engine that reads XML files and populates the map, calling constructors and/or set methods as it goes.

• In SPAR there is a hierarchy of bean factories, There is

a top level that is a wrapper around OSGi Services and a local bean factory for each plugin.

Services Bean Factory Plugin A BeanFactory Plugin B BeanFactory Plugin C BeanFactory Plugin D BeanFactory

2007 JavaOneSM Conference | Session TS-3316 | 45

Agenda

• Basics
• Modularity
• Wiring
• Communication
• Conclusion
• Q & A

2007 JavaOneSM Conference | Session TS-3316 | 46

How do events get from one part of the system to another

Communication

• The classic example of this in the Swing world is a

Listener.

• We all know and use listeners, why are they a problem?
• Again it comes down to the problem of coupling.
• Let’s look at an example

2007 JavaOneSM Conference | Session TS-3316 | 47

Communication: Example

2007 JavaOneSM Conference | Session TS-3316 | 48

Communication: Example

2007 JavaOneSM Conference | Session TS-3316 | 49

Communication: Example

2007 JavaOneSM Conference | Session TS-3316 | 50

Communication: Solution

• EventBus or messaging system.
• Which is much more manageable than all the

interconnections.

Selection Changed Filter Changed

2007 JavaOneSM Conference | Session TS-3316 | 51

Communication: Extensions

• You can extend a message system

to do things like:

• Message rate limiting
• Only keep most recent
• Centralize threading in message bus
• Send events of the network to other clients

2007 JavaOneSM Conference | Session TS-3316 | 52

Agenda

• Basics
• Modularity
• Wiring
• Communication
• Conclusion
• Q & A

2007 JavaOneSM Conference | Session TS-3316 | 53

Conclusion

• So in the end I have a few basic pieces of advice:
• Break a large application down into manageable

modules with defined interfaces

• Limiting the direct coupling between areas of the

application

• Plugin frameworks, IOC and EventBuses are good

tools to help you do that

• I am open sourcing the SPAR framework I have

built for Imagery:

• http://spar.dev.java.net

2007 JavaOneSM Conference | Session TS-3316 | 54

Q&A

Jasper Potts