Bug 289409 [Viewers] ILazyTreePathContentProvider documentation request
I believe the JavaDoc for ILazyTreePathContentProvider#updateElement() should mention that the implementation can call TreeViewer#setHasChildren() instead of TreeViewer#setChildCount() if the content provider can more efficiently determine the has-children status than it can the actual number of children. This optimization was made possible by 156883. I think it needs to be advertised so clients can take advantage of it in their implementation of ILazyTreePathContentProvider#updateElement(). In fact, I think clients that use ILazyTreeContentProvider also have access to that optimization. If so, that JavaDoc should be updated, too.
bundles/org.eclipse.jface/src/org/eclipse/jface/viewers/ILazyTreeContentProvider.java
/**
	 * Called when a previously-blank item becomes visible in the TreeViewer. If
	 * the content provider knows the child element for the given parent at this
	 * index, it should respond by calling
	 * {@link TreeViewer#replace(Object, int, Object)}. The content provider
	 * should also update the child count for any replaced element by calling
	 * {@link TreeViewer#setChildCount(Object, int)}. If the given current child
	 * count is already correct, setChildCount does not have to be called since
	 * a call to replace will not change the child count.
	 * 
	 * <strong>NOTE</strong> #updateElement(int index) can be used to determine
	 * selection values. If TableViewer#replace(Object, int) is not called
	 * before returning from this method, selections may have missing or stale
	 * elements. In this situation it is suggested that the selection is asked
	 * for again after replace() has been called.
	 * 
	 * @param parent
	 *            The parent of the element, or the viewer's input if the
	 *            element to update is a root element
	 * @param index
	 *            The index of the element to update in the tree
	 */
	public void updateElement(Object parent, int index);