GreenMail Core does not build using Oracle JDK 6 about greenmail

[buildscientist]

So it looks like we can get around this by adding this import to com.icegreen.greenmail.util.DummySSLSocketFactory

import com.sun.net.ssl.internal.ssl.SSLSocketImpl;

The primary issue here is that we'd be using what appears to be an internal/deprecated library. No idea if this is going to continue being supported in Java 8 and beyond.

[camann9]

We can avoid the import by using reflection: try to find out if "setHost" is available and if this is the case set it. This is of course not a very nice fix but I would very much like to keep the setHost in there. In my (Windows) environment the reverse lookup is unbearably slow and I don't see any other way of circumventing this problem.
What I'm surprised about is that greenmail doesn't build on Oracle JDK 6 when it does build on Oracle JDK 7 (see https://travis-ci.org/greenmail-mail-test/greenmail ). Another way of dealing with this problem would be to just bump the java version to 1.7. What do you say?

[buildscientist]

Hi Christian - thanks for welcoming me to the project.

I believe we should avoid limiting the build scope of Greenmail to Java 1.7 and above. Java 1.6 is still being supported by Oracle and a lot of users (myself included) are using Greenmail in Java 1.6 environments.

Reflection is definitely a possibility but what if we were to extend the default Java SecurityManager class and override the methods that cause reverse DNS lookups for SSL chains to do nothing. Then we can do something like:

System.setSecurityManager(new ExtendedSecurityManager());

This has the downside of introducing potential security issues when dealing with SSL.

[buildscientist]

Reverse DNS lookup latency appears to manifest itself only on Windows OS. For more details see the following Java bug reports.

• http://bugs.java.com/bugdatabase/view_bug.do?bug_id=4939977
• http://bugs.java.com/bugdatabase/view_bug.do?bug_id=4653680

[camann9]

Yeah, I guessed that this is a windows issue but sadly many develper computers run windows (including mine...). I think supporting jdk6 is generally a good thing so i would tend to use the reflection "solution". The DummySSLSocketFactory is only used for testing anyways.
Sadly travis ci doesn't support jdk6 so we can not Continuous Integration on jdk6. This means that changes that break compatibility with jdk6 are hard to spot.
Anyways, I "corrected" the problem now

[camann9]

If you have a suggestion on how to fix this issue in a better way pleaselet me know