platform-core-home/docs/classloader-properties/classloader_properties.html
Parent Directory
| 
Revision Log
Revision 1.1 - (view) (download) (as text)
| 1 : | dj | 1.1 | <html> |
| 2 : | <head> | ||
| 3 : | <title>Using the classloader.properties file</title> | ||
| 4 : | </head> | ||
| 5 : | <body> | ||
| 6 : | <h1>Using the classloader.properties file</h1> | ||
| 7 : | Eclipse v2.0.2 includes many performance enhancements, including some in the area | ||
| 8 : | of classloading. In order to help out with this a classloader properties file | ||
| 9 : | was created and this file explains its use. | ||
| 10 : | <p> | ||
| 11 : | |||
| 12 : | <h2>Activation</h2> | ||
| 13 : | To enable the classloader performance enhancements, the user must pass the <code>-classloaderProperties</code> | ||
| 14 : | command-line argument to the Eclipse executable. If the argument is used by itself | ||
| 15 : | the default location (see below) is used for the classloader properties file. | ||
| 16 : | Alternatively the argument can be followed by a path or URL to the appropriate | ||
| 17 : | file to use. | ||
| 18 : | <p> | ||
| 19 : | |||
| 20 : | <h2>Location</h2> | ||
| 21 : | The default location of the classloader properties file is as a sibling of the <code>boot.jar</code> | ||
| 22 : | in the <code>org.eclipse.core.boot</code> plug-in. | ||
| 23 : | For instance:<br> | ||
| 24 : | <code>/eclipse/plugins/org.eclipse.core.boot/classloader.properties</code> | ||
| 25 : | <p> | ||
| 26 : | |||
| 27 : | If the user specifies the location of the file, it can be either a path or a URL to a file. For instance:<br> | ||
| 28 : | <code> | ||
| 29 : | -classloaderProperties c:/temp/myfile.properties<br> | ||
| 30 : | -classloaderProperties file:/c:/temp/myfile.properties | ||
| 31 : | </code> | ||
| 32 : | <p> | ||
| 33 : | |||
| 34 : | <h2>Format</h2> | ||
| 35 : | The format of the classloader properties file is a <code>java.util.Properties</code> file. The key in the file is the name of the | ||
| 36 : | plug-in and the value is a comma-separated list of the package prefixes for the packages in the plug-in's jar. | ||
| 37 : | <p> | ||
| 38 : | |||
| 39 : | It is quite common for jar files to contain code which reside in multiple packages. For instance, the <code>runtime.jar</code> file | ||
| 40 : | in the <code>org.eclipse.core.runtime</code> plug-in contains code in the following packages:<br> | ||
| 41 : | <code> | ||
| 42 : | org.eclipse.core.runtime<br> | ||
| 43 : | org.eclipse.core.internal.runtime,<br> | ||
| 44 : | org.eclipse.core.internal.plugins<br> | ||
| 45 : | org.eclipse.core.runtime.model</code>.<p> | ||
| 46 : | In this case, in the classloader properties file we put specify the following line: | ||
| 47 : | <p> | ||
| 48 : | <code>org.eclipse.core.runtime=org.eclipse.core</code> | ||
| 49 : | <p> Notice that <code>org.eclipse.core</code> is a common prefix for all packages | ||
| 50 : | in the <code>runtime.jar</code>. The alternative is to declare all 4 prefixes | ||
| 51 : | in the file as a comma-separated list. In this case one must weigh the trade-off | ||
| 52 : | between the number of checks required against multiple entries and a prefix | ||
| 53 : | which may include false hits. Depending on the way that your code is structured, | ||
| 54 : | it might be best to list as many as 5-10 package prefixes rather than going | ||
| 55 : | with a more general prefix. For instance, if all your code across multiple plug-ins | ||
| 56 : | contains the same prefix (e.g. <code>com.mycompany</code>) then you will not | ||
| 57 : | be taking full advantage of all benefits if you list only the single prefix | ||
| 58 : | "com.mycompany" in the file. | ||
| 59 : | <p> | ||
| 60 : | |||
| 61 : | It is also common for plug-ins to contain multiple jar files with code. In this case all package prefixes from all jars | ||
| 62 : | should appear in the classloader properties file. | ||
| 63 : | <p> | ||
| 64 : | |||
| 65 : | Note that 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 | ||
| 66 : | means that you will not be able to take advantage of classloading optimization. And note that missing a package | ||
| 67 : | prefix as a value entry in the file does mean that your code will not work. | ||
| 68 : | <p> | ||
| 69 : | |||
| 70 : | See the file which is shipped with Eclipse for an example. | ||
| 71 : | (<code>/eclipse/plugins/org.eclipse.core.boot/classloader.properties</code>) | ||
| 72 : | <p> | ||
| 73 : | |||
| 74 : | <h2>Future</h2> | ||
| 75 : | As described above, currently one must add all package prefixes to the same properties | ||
| 76 : | file. Future work in this area includes the ability to add mark-up to your <code>plugin.xml</code> | ||
| 77 : | file to take advantage of this classloading performance behaviour to make it easier | ||
| 78 : | for people who are extending the Eclipse platform. | ||
| 79 : | <p> | ||
| 80 : | |||
| 81 : | <h2>Trouble-shooting</h2> | ||
| 82 : | If you get a <code>java.lang.ClassNotFoundException</code> then that is an indication that there might be a problem | ||
| 83 : | with your entries in the properties file. The file could have the correct syntax, but the package prefixes in the | ||
| 84 : | comma-separated list might be missing some entries. The workaround for this is to comment out the line of the offending plug-in. | ||
| 85 : | <p> | ||
| 86 : | |||
| 87 : | </body> | ||
| 88 : | </html> |
| help@eclipse.org | ViewVC Help |
| Powered by ViewVC 1.0.3 |