ViewVC logotype

Contents of /libjpf-java/trunk/jdocs/concepts.jxp

Parent Directory Parent Directory | Revision Log Revision Log

Revision 1601 - (show annotations)
Sat Feb 28 23:28:19 2009 UTC (12 years, 5 months ago) by gregoa
File size: 3462 byte(s)
[svn-inject] Forking libjpf-java source to Trunk
1 <%
2 // Java Plug-in Framework (JPF)
3 // Copyright (C) 2004 - 2005 Dmitry Olshansky
4 // $Id$
5 // Updated by Michael Dawson 20/02/2006
6 %>
7 <%
8 include("/functions.ijxp");
10 printHeader("Concepts");
11 printMenu("concepts");
12 %>
13 <div class="content">
14 <h1>Core JPF Concepts</h1>
15 <h3>Our Purpose</h3>
16 <p>The goal of the JPF project is to help Java developers build <strong>modular</strong> and <strong>extensible</strong> applications. At JPF, we think it is important to clearly distinguish between the two.</p>
17 <h3>Modules and Application Modularity</h3>
18 <p>Simply speaking, modularization is splitting an application into several smaller parts. The JPF framework allows this by using the concept of plug-ins. This means you can think of plug-ins as a collection of classes and resources managed by special ClassLoader that makes them available to all dependent plug-ins transparently.</p>
19 <p>Lets say a plug-in <em>PluginA</em> introduces a class <code>ClassA</code> (this class is included in a plug-in directory hierarchy described by a JPF plug-in manifest). Now you are developing another plug-in, <em>PluginB</em>, and add another class, <code>ClassB</code>, to this plug-in. You want to reference <code>ClassA</code> in your <code>ClassB</code> code so you need to declare a plug-in dependency. You can do this by making an entry in the JPF manifest of the plug-in <em>PluginB</em> that says "<em>PluginB</em> depends on <em>PluginA</em>". This is done in the prerequisites/imports section of the JPF manifest. JPF handles finding and loading <em>ClassA</em> when it is first called. The magic lies in the ClassLoaders created by JPF. The extend the classpath of <em>PluginB</em> so that it includes the classpath of <em>PluginA</em>. So the developer doesn't have to worry about finding classes and can use the basic code that follows in <code>ClassB</code>:</p>
20 <pre>
21 ClassA clsA = new ClassA();
22 </pre>
23 <p>No further work is necessary to make <code>ClassA</code> visible for <code>ClassB</code> code, only simple <strong>JPF manifest declarations</strong>.</p>
24 <h3>Extensions and Application Extensibility</h3>
25 <p>Simply speaking, application extensibility is adding on to already existing functionality. JPF supports this with special manifest declarations. In JPF extensibility is based on the concept of <em>extension points</em> and <em>extensions</em>. An extenstion point is an opening that may be added to by later code. An extension is code that adds onto an existing extension point. Typically <em>extension points</em> are declared in a plug-in manifest and supported with Java code There is no special dedicated API for such code in JPF as it can be anything! For examples of <em>extension points</em> see the JPF demo application.</p>
26 <p>When designing applications based on JPF it is better to think in terms of <em>extension points</em> and <em>extensions</em> rather than <em>plug-ins</em>. In general, it doesn't matter where (in what <em>plug-in</em>) the actual code and/or resources are placed. It is much more important to define where an application can be extended, and design and develop <em>extension points</em> to support this extensibility.</p>
27 <h3>Summary</h3>
28 <p><em>Plug-ins</em> - are what makes an application <strong>modular</strong>. <em>Extension points</em>&nbsp;/&nbsp;<em>extensions</em> - are what makes application <strong>extensible</strong>.</p>
29 </div>
30 <%
31 printFooter();
32 %>

  ViewVC Help
Powered by ViewVC 1.1.26