Bug 118479 [api] Need a way to get a shared instance of JavaTextTools
JavaTextTools contains tools required to cofigure a java text viewer, and those tools can be shared via JavaTextTools. Currently, when clients want to use those tools, they need to first create a new instance of JavaTextTools and then share their instance of JavaTextTools in order to share the tools in JavaTextTools. This seems like it goes against the purpose of JavaTextTools. You should only really have 1 instance of JavaTextTools (at least per preferenceStore) Plus, you also need to make sure you dispose JavaTextTools, so by having only 1 instance, it'll be easier to keep track of to dispose. JDT is already kind of doing this by only creating one instance of JavaTextTools in JavaPlugin. I think this one instance should be shared amongst other clients instead of just the jdt plugin. A new method should be added to JavaUI, getJavaTextTools, which gets JavaTextTools from JavaPlugin.
org.eclipse.jdt.ui/ui/org/eclipse/jdt/ui/JavaUI.java
* The Java UI plug-in uses the <i>primary working copy owner</i> that can be accessed with <code>null</code> in
	 * API's that require an owner
	 */
	public static org.eclipse.jdt.core.IBufferFactory getBufferFactory() {
		return JavaPlugin.getDefault().getBufferFactory();
	}
	/**
	 * Returns the DocumentProvider used for Java compilation units.
	 *
	 * @return the DocumentProvider for Java compilation units.
	 * 
	 * @see IDocumentProvider
	 * @since 2.0
	 */
	public static IDocumentProvider getDocumentProvider() {
		return JavaPlugin.getDefault().getCompilationUnitDocumentProvider();
	}
		
	/**
	 * Sets the Javadoc location for an archive with the given path.
	 * 
	 * @param archivePath the path of the library; this can be an workspace path
	 * or an external path in case of an external library.
	 * @param url the Javadoc location to set. This location should contain index.html and
	 * a file 'package-list'. <code>null</code> clears the current documentation
	 * location.
	 * @deprecated Javadoc is now attached to the classpath entry. 
	 * Evaluate the libraries classpath entry and reconfigure the Javadoc location there.
	 * 
	 * @since 2.0