Set up as a Java module

An important part of a good cryptographic library is its API. By and large, we only want downstream libraries and applications to use the interface that we have defined, because it helps to ensure that (often security-critical) invariants are enforced (e.g. that an invalid Ristretto group element is unrepresentable, because the only way to instantiate one is through the DECODE or FROM_UNIFORM_BYTES functions).

Currently, the way we enforce the API is by keeping all internal classes inside the same package as the API, so that they can be package-private. Java only provides two levels of visibility for classes - public, and package-private - so this is the only way to keep the implementation accessible to the classes providing the API, without giving the implementation public visibility.

However, this still suffers from reflection: anyone with reflection priviledges can make any class (or its members) visible. Java 7 and 8 provide no way for libraries to override this; reflection can only be disabled at the system level via security permissions.

Java 9 introduced the concept of modules, which enable strong encapsulation by preventing reflection into a package by default. Libraries can use this to export their API without exposing any internals, and reflection for exported APIs is disabled. Only when a package is "opened" can reflection be performed. This can be overridden by the user at the system level (by passing flags to the JVM), but it's a significantly improved barrier, and more effectively encourages use of the intended API.

This issue requires:

Creating a module-info.java exporting the intended API.
Configuring the build system to compile module-info.java targeting Java 9, while leaving the rest of the codebase targeting Java 7.
Testing that the module correctly prevents reflection on Java 9 and above.

cryptography-cafe / curve25519-elisabeth

Set up as a Java module #11