Bug 77185 [classpath] entry kind "natives"
We had a discussion about how to best support SWT application developement. The biggest problem is the native dll and that user have to create special launch configs with -Djava.library.path=.... to get a SWT application up and running. However the dll problems seems to be a more general problem. Although the compiler doesn't care about dll it would fit into our current story to have a class path entry kind "natives". Java/Core wouldn't benefit from the entry, but debugger could use it to construct the -Djava.library.path= command line argument.
org.eclipse.jdt.ui/ui/org/eclipse/jdt/ui/wizards/BuildPathDialogAccess.java
}
		return null;
	}
	
	/**
	 * Shows the UI for configuring a javadoc location attribute of the classpath entry. <code>null</code> is returned
	 * if the user cancels the dialog. The dialog does not apply any changes.
	 * 
	 * @param shell The parent shell for the dialog.
	 * @param initialEntry The entry to edit. The kind of the classpath entry must be either
	 * <code>IClasspathEntry.CPE_LIBRARY</code> or <code>IClasspathEntry.CPE_VARIABLE</code>.
	 * @return Returns the resulting classpath entry containing a potentially modified javadoc location attribute 
	 * The resulting entry can be used to replace the original entry on the classpath.
	 * Note that the dialog does not make any changes on the passed entry nor on the classpath that
	 * contains it.
	 * 
	 * @since 3.1
	 */
	public static IClasspathEntry configureJavadocLocation(Shell shell, IClasspathEntry initialEntry) {
		if (initialEntry == null) {
			throw new IllegalArgumentException();
		}
		int entryKind= initialEntry.getEntryKind();
		if (entryKind != IClasspathEntry.CPE_LIBRARY && entryKind != IClasspathEntry.CPE_VARIABLE) {
			throw new IllegalArgumentException();
		}
		
		URL location= JavaUI.getLibraryJavadocLocation(initialEntry);
		JavadocLocationDialog dialog=  new JavadocLocationDialog(shell, initialEntry.getPath().toString(), location);
		if (dialog.open() == Window.OK) {