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/internal/ui/wizards/buildpaths/LibrariesWorkbookPage.java
if (result != null) {
				selElement.setAttribute(CPListElement.SOURCEATTACHMENT, result.getSourceAttachmentPath());
				attributeChanged= true;
				fLibrariesList.refresh();
				fClassPathList.refresh(); 
			}
		} else if (key.equals(CPListElement.JAVADOC)) {
			String initialLocation= (String) selElement.getAttribute(CPListElement.JAVADOC);
			
			String elementName= new CPListLabelProvider().getText(selElement);
			try {
				URL url= initialLocation != null ? new URL(initialLocation) : null;
				URL[] result= BuildPathDialogAccess.configureJavadocLocation(getShell(), elementName, url);
				if (result != null) {
					URL newURL= result[0];
					selElement.setAttribute(CPListElement.JAVADOC, newURL != null ? newURL.toExternalForm() : null);
					attributeChanged= true;
					fLibrariesList.refresh();
					fClassPathList.dialogFieldChanged(); 
				}
			} catch (MalformedURLException e) {
				
			}
		} else if (key.equals(CPListElement.ACCESSRULES)) {
			TypeRestrictionDialog dialog= new TypeRestrictionDialog(getShell(), selElement);
			if (dialog.open() == Window.OK) {
				selElement.setAttribute(CPListElement.ACCESSRULES, dialog.getAccessRules());
				attributeChanged= true;
				
				fLibrariesList.refresh();