Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Mail Systems
Eclipse Documentation

How To Guides
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Problem Solutions
Privacy Policy




Eclipse Plug-in Developer Guide
Previous Page Home Next Page

Eclipse 3.3 Plug-in Migration FAQ

  1. Impact of JAR signing

Impact of JAR signing

In Eclipse 3.3, plug-ins in the Eclipse platform are signed with a cryptographic signature supplied by the Eclipse Foundation. Signing of plug-ins can have an impact in three areas:

  • Code that uses non-Eclipse class loaders. Eclipse class loaders have a flag that controls load-time verification of signature, and it is turned off by default. Loaders in the JDK such as URLClassLoader do not have this option, and will always verify any JAR file that contains signatures. If this performance impact is not acceptable, the only solution is to avoid signing of JARs that are loaded by other class loaders. A common example is JARs that are intended to be run with Ant.
  • Use of the constructor java.util.jar.JarFile(File) (i.e., without verify = false). JarFile will perform verification of signatures unless explicitly told not to. This will have a performance impact when the JAR is signed. If you don't need signature verification, be sure to use the JarFile API that does not perform verification.
  • Use of java.util.jar.Manifest. Since the manifest file of a signed JAR can be quite large, anyone reading and parsing entire files will see a performance hit. The best solution in this case is to only read the manifest main attribute rather than parsing the entire file.

  Published under the terms of the Eclipse Public License Version 1.0 ("EPL") Design by Interspire