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/CPListElement.java
public Object[] getChildren(boolean hideOutputFolder) {
		if (hideOutputFolder && fEntryKind == IClasspathEntry.CPE_SOURCE) {
			return getFilteredChildren(new String[] { OUTPUT });
		}
		if (fParentContainer != null && fEntryKind != IClasspathEntry.CPE_SOURCE) {
			
			return getFilteredChildren(new String[] { ACCESSRULES, COMBINE_ACCESSRULES });
		}
		if (fEntryKind == IClasspathEntry.CPE_PROJECT) {
			return getFilteredChildren(new String[] { COMBINE_ACCESSRULES });
		}
		return fChildren.toArray();
	}
		
	public Object getParentContainer() {
		return fParentContainer;
	}	
	
	private void attributeChanged(String key) {
		fCachedEntry= null;
	}
	
	
	/*
	 * @see Object#equals(java.lang.Object)
	 */
	public boolean equals(Object other) {
		if (other != null && other.getClass().equals(getClass())) {
			CPListElement elem= (CPListElement) other;
			return getClasspathEntry().equals(elem.getClasspathEntry());