Designing Plugin Architectures

1
Designing Plug-in Architectures

• and the Tiny Plug-in Manager

2
Interfaces

• Interfaces form a contract between the plug-in
  class and the application, so designing them
  carefully is important.
• Using Interfaces to define behavior throughout
  any application is a great practice since you are
  creating an opportunity of make your application
  extensible if you choose to.

3
Example of Plug-in Interface Design Consideration
We want plug-ins to be able to contribute to the
tool bar actions of our faux Swing hex editor
4
Design Considerations

• Lets pretend this application is Swing
• Do we expose our Applications JToolbar by
  providing an API such as
• Public void addActions(JToolbar toolBar)
• Or can we just request a list of Actions from a
  plug-in and let the application handle their
  contribution?
• Public Action getActions()

5
Create Classes Dynamically(some class loading
basics)

• Classes are defined by their fully qualified java
  name i.e. java.util.ArrayList, not ArrayList and
  their ClassLoader.
• If you load the same class with different class
  loaders they are considered completely different
  by the JVM.

6
Example

• TestClass is in our class path.
• ClassLoader classLoader new MyCustomClassLoader(
  )
• Class clazz classLoader.loadClass(matt.test.Tes
  tClass)
• TestClass testClass (TestClass)clazz.newInstance
  ()
• TestClass foo testClass //will throw a
  ClassCastException!
• The TestClass receiving assignment is defined as
  (matt.test.TestClass, ApplicationClassLoader)
• TestClass that we created using reflection is
  defined as (matt.test.TestClass,
  MyCusomClassLoader)
• Luckily this does not happen when using
  Interfaces.

7
Inside a ClassLoader

• Must extend abstract class ClassLoader
• FileSystemClassLoader will load classes from
  known directories on the file system.
• Scans directories for .class files and stores
  them in a Map. class name - File path
• The loadClass(String className) method will
  eventually call findClass(String className) which
  we can override.
• We retrieve the location of the .class file from
  the map and using FileInputStream, read the file
  into a byte .
• ClassLoader provides a final method
• protected final Class defineClass(String name,
  byte b, int off, int len)
• Which takes our byte and returns us a
  Class.

8
To load a Class Dynamically we need

• The fully qualified Class name
• The dependencies of that class
• A place where the JVM can access the class as a
  resource.

9
Tiny Plug-in Manager

• Bring your own Interface
• Jar file plugin.properties file
• plugin.class and plugin.dependencies
• plugin.class mypackage.MyPluginEntryPoint
• plugin.dependencies JDom.jar, Log4J.jar etc
• Pass a directory where your plug-in jars will be
  stored to the constructor.
• plugin.properties file goes in the top level of
  the jar.

10
Tiny Plug-in Manager

• Will scan the directory for Jar files and store
  them internally as PluginEntries
• The application can ask for a list of entry point
  class names that it finds
• Application can then ask for a Class based on the
  entry point class name
• Allows for installation of plug-ins during
  runtime and allows application to decide when to
  instantiate.

11
(No Transcript)