Dependencies on *.sun.* classes

[kasemir]

A recent commit on master to add m2e configs for using Tycho/maven within the IDE also changed several .classpath files from

    <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"/>

to one of these:

    <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/J2SE-1.5"/>
       <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/JavaSE-1.6"/> 
    <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/JavaSE-1.7"/>

This results in compiler errors wherever *.sun*. classes are used which may not be in non Sun/Oracle versions of Java:

org.csstudio.security/src/org/csstudio/security/authorization/LDAPGroupAuthorizationProvider.java uses com.sun.security.auth.module.LdapLoginModule.
org.csstudio.email/src/org/csstudio/email/EMailSender.java uses sun.net.smtp.SmtpClient.
org.csstudio.trends.databrowser2/src/com/jmatio/io/MatFileReader.java uses sun.misc.Cleaner.
Probably related, org.csstudio.utility.pvmanager.ui.toolbox/src/org/csstudio/utility/pvmanager/ui/toolbox/FunctionTreeContentProvider.java has a problem using Integer.compare() after that .classpath change.

Short solution could be to revert the JRE_CONTAINER change, we continue to require the Sun/Oracle JDKs. Then perform the updates as we switch to Java 8.

[kasemir]

Compiler errors are done, issue can be left open until we handle the .sun. dependencies.