#112 Please support building on Java 9

[Chris West (Faux)]

davmail currently fails to build with Java 9, due for release 28 days from today.

Firstly, there's a build system check that seems to be incorrect: Java 9 exposes its version as just "9", not "1.9":

--- build.xml   (revision 2490)
+++ build.xml   (working copy)
@@ -26,12 +26,9 @@
     </condition>

     <condition property="is.java6">
-        <or>
-            <equals arg1="${ant.java.version}" arg2="1.6"/>
-            <equals arg1="${ant.java.version}" arg2="1.7"/>
-            <equals arg1="${ant.java.version}" arg2="1.8"/>
-            <equals arg1="${ant.java.version}" arg2="1.9"/>
-        </or>
+        <not>
+            <matches string="${ant.java.version}" pattern="1\.[012345]"/>
+        </not>
     </condition>

     <condition property="is.utf8">

Then, SunPKCS11ProviderHandler.java is a problem. The class has lost the ability to configure it based on an input stream, as far as I can see; the new expected api is:

Provider p = Security.getProvider("SunPKCS11");
p.configure(filePath);
Security.addProvider(p);

Even worse, this isn't compatible with Java8, as that .configure() method is new in 9:
https://docs.oracle.com/javase/9/security/pkcs11-reference-guide1.htm

[Mickael Guessant]

The first part is easy, already merged in trunk, the second one is tricky: if the only way to configure the provider is to provide a file path, it's easier to directly adjust java.security and not use DavMail PKCS11 settings.

I understand this class does not compile at all under Java 9 ?
Does it run if compiled with Java 8 ?

[Chris West (Faux)]

On Sun, Aug 27, 2017 at 02:33:55PM +0000, Mickael Guessant wrote:

The first part is easy, already merged in trunk, the second one is tricky: if the only way to configure the provider is to provide a file path, it's easier to directly adjust java.security and not use DavMail PKCS11 settings.

I understand this class does not compile at all under Java 9 ?
Does it run if compiled with Java 8 ?

No, the method is gone in Java 9, even if compiled with 8:
Exception in thread "main" java.lang.NoSuchMethodError:
sun.security.pkcs11.SunPKCS11.<init>(Ljava/io/InputStream;)V
at PKCS.main(PKCS.java:3)

Testcase, which compiles and runs fine on Java 8:
class PKCS {
public static void main(String... args) throws Exception {
new sun.security.pkcs11.SunPKCS11(new java.io.FileInputStream(args[0]));
}
}

I'm afraid I don't really know enough about davmail to show that the
official binaries/source will start failing when people upgrade to Java 9,
but I strongly suspect they will, as it currently stands.

One could write reflection code to detect the method, and use it if
present, but doing so sounds horrible and a waste of time, if java.security
covers the usecase?

Cheers.

[Mickael Guessant]

The issue is that we have two completely incompatible SunPKCS11 implementations:
Java <=8:
- has an inputstream constructor => ne need to create a temporary file
- this constructor is public, as most methods/classes in the package
- does not have the configure method

Java 9:
- no longer any inputstream constructor
- constructor only accepts fileName => requires a temporary config file
- constructor is package protected, the Config class is also protected
- supports the configure method

=> this means the only way to create an implementation compatible with both is to use reflection
=> during my tests, I found that with Java 9 if the file name starts with --, it's considered as config content, not file name !

=> Fix available in subversion should be compatible with all Java versions.

[Mickael Guessant]

Fix available in latest version