platform-core-home/docs/classloader-properties/classloader_properties.html
Parent Directory
| 
Revision Log
Revision 1.4 -
(download)
(as text)
(annotate)
Fri Oct 25 16:04:33 2002 UTC (7 years, 1 month ago) by dj
Branch: MAIN
CVS Tags: v20040721, HEAD
Changes since 1.3: +59 -0 lines
Fri Oct 25 16:04:33 2002 UTC (7 years, 1 month ago) by dj
Branch: MAIN
CVS Tags: v20040721, HEAD
Changes since 1.3: +59 -0 lines
Updated "Using the Class Loader Properties File".
<html> <head> <title>Using the Class Loader Properties File</title> </head> <body> <h1>Using the Class Loader Properties File</h1> <em>Last update: October 25, 2002</em> <p> Eclipse 2.0.2 includes many performance enhancements, including some in the area of classloading. In order to help out with this a classloader properties file was created and this file explains its use. <p> <ul> <li><a href="#activation">Activation</a></li> <li><a href="#location">Location</a></li> <li><a href="#format">Format</a></li> <li><a href="#future">Future</a></li> <li><a href="#trouble">Trouble-Shooting</a></li> <li><a href="#example">Example File</a></li> </ul> <p> <h2><a name="activation"></a>Activation</h2> To enable the classloader performance enhancements, the user must pass the <code>-classloaderProperties</code> command-line argument to the Eclipse executable. If the argument is used by itself the default location (see below) is used for the classloader properties file. Alternatively the argument can be followed by a path or URL to the appropriate file to use. <p> <h2><a name="location"></a>Location</h2> The default location of the classloader properties file is as a sibling of the <code>boot.jar</code> in the <code>org.eclipse.core.boot</code> plug-in. For instance:<br> <code>/eclipse/plugins/org.eclipse.core.boot_2.0.2/classloader.properties</code> <p> If the user specifies the location of the file, it can be either a path or a URL to a file. For instance:<br> <code> -classloaderProperties c:/temp/myfile.properties<br> -classloaderProperties file:/c:/temp/myfile.properties </code> <p> It is important to note that the file which is used by the system (either the default or the one which is specified by the user) is <b>exclusive</b> and does <b>not</b> represent the intersection between multiple files. That being said, if the user specifies a particular file to use, then the contents of the default file must be merged with it in order for the class loader enhancements to take effect for the classes in the Eclipse Platform; the contents of the default file are not automatically used. <p> <h2><a name="format"></a>Format</h2> The format of the classloader properties file is a <code>java.util.Properties</code> file. Each key in the file is the name of the plug-in and the value is a comma-separated list of the package prefixes for the packages in the plug-in's jar. <p> It is quite common for jar files to contain code which reside in multiple packages. For instance, the <code>org.eclipse.core.runtime</code> plug-in contains code in the following packages:<br> <code> org.eclipse.core.runtime<br> org.eclipse.core.internal.runtime,<br> org.eclipse.core.internal.plugins<br> org.eclipse.core.runtime.model</code>. <p> In this case, the classloader properties specifies: <p> <code>org.eclipse.core.runtime=org.eclipse.core</code> <p> Notice that <code>org.eclipse.core</code> is a common prefix for all packages in the plug-in. The alternative is to declare all 4 prefixes in the file as a comma-separated list. In this case one must weigh the trade-off between the number of checks required against multiple entries and a prefix which may include false hits. Depending on the way that your code is structured, it might be best to list as many as 5-10 package prefixes rather than going with a more general prefix. For instance, if all your code across multiple plug-ins contains the same prefix (e.g. <code>com.mycompany</code>) then you will not be taking full advantage of all benefits if you list only the single prefix "com.mycompany" in the file. <p> When a plug-in contains multiple jar files with code, the entry in the the class loader properties file should account for all package prefixes from all jars. <p> Note that missing a package prefix as a value entry in the file means that your code will not work but not having an entry for your plug-in as a key in the file doesn't mean that your code will not work, it just means that you will not be able to take advantage of classloading optimization. <p>See the file which is shipped with Eclipse for an example. (<code>/eclipse/plugins/org.eclipse.core.boot_2.0.2/classloader.properties</code>) <p> <h2><a name="future"></a>Future</h2> As described above, currently one must add all package prefixes to the same properties file. Future work in this area includes the ability to add mark-up to your <code>plugin.xml</code> file to take advantage of this classloading performance behavior to make it easier for people who are extending the Eclipse platform. <p> <h2><a name="trouble"></a>Trouble-shooting</h2> If you get a <code>java.lang.ClassNotFoundException</code> then that is an indication that there might be a problem with your entries in the properties file. The file could have the correct syntax, but the package prefixes in the comma-separated list might be missing some entries. To verify this is the problem, use a number sign (#) to comment out the line of the offending plug-in. <p> <h2><a name="example"></a>Example File</h2> Here is an example of the <code>classloader.properties</code> file which ships with Eclipse 2.0.2. <p> <code> <blockquote> <pre> org.apache.ant = org.apache.tools org.apache.lucene = org.apache.lucene org.apache.xerces = org.apache, org.w3c.dom, org.xml.sax, javax.xml org.eclipse.ant.core = org.eclipse.ant org.eclipse.compare = org.eclipse.compare org.eclipse.core.resources = org.eclipse.core org.eclipse.core.runtime = org.eclipse.core org.eclipse.debug.core = org.eclipse.debug.core, org.eclipse.debug.internal.core org.eclipse.debug.ui = org.eclipse.debug.ui, org.eclipse.debug.internal.ui org.eclipse.help = org.eclipse.help org.eclipse.help.ui = org.eclipse.help.ui org.eclipse.jdt.core = org.eclipse.jdt.core, org.eclipse.jdt.internal org.eclipse.jdt.debug = com.sun.jdi, org.eclipse.jdi, org.eclipse.jdt org.eclipse.jdt.debug.ui = org.eclipse.jdt.debug.ui, org.eclipse.jdt.internal.debug.ui org.eclipse.jdt.junit = org.eclipse.jdt.internal.junit org.eclipse.jdt.launching = org.eclipse.jdt.launching, org.eclipse.jdt.internal.launching org.eclipse.jdt.ui = org.eclipse.jdt.internal, org.eclipse.jdt.ui org.eclipse.pde.build = org.eclipse.pde.internal.build org.eclipse.pde.core = org.eclipse.pde.core, org.eclipse.pde.internal.core org.eclipse.pde.runtime = org.eclipse.pde.internal.runtime org.eclipse.pde.ui = org.eclipse.pde.ui, org.eclipse.pde.internal.ui org.eclipse.search = org.eclipse.search org.eclipse.swt = org.eclipse.swt org.eclipse.team.core = org.eclipse.team.core, org.eclipse.team.internal.core org.eclipse.team.cvs.core = org.eclipse.team.internal.ccvs.core org.eclipse.team.cvs.ssh = org.eclipse.team.internal.ccvs.ssh org.eclipse.team.cvs.ui = org.eclipse.team.internal.ccvs.ui org.eclipse.team.ui = org.eclipse.team.ui, org.eclipse.team.internal.ui org.eclipse.ui = org.eclipse.ui, org.eclipse.jface org.eclipse.ui.externaltools = org.eclipse.ui.externaltools org.eclipse.update.core = org.eclipse.update org.eclipse.update.ui = org.eclipse.update.internal.ui org.eclipse.update.forms = org.eclipse.update.ui.forms org.junit = junit </pre> </blockquote> </code> <p> </body> </html>
| help@eclipse.org | ViewVC Help |
| Powered by ViewVC 1.0.3 |