Since it is understandable that not all of our users can track all development activities on GitHub, I would like to write a few paragraphs here about the technical updates that are planned for Cryptomator in 2018 and their impact on usage.
The biggest upcoming change is the implementation of FUSE-based drives. This will be additional to WebDAV and will become the new default setting. We are currently developing the necessary library. It is based on jnr-fuse, which means you need FUSE for macOS or WinFsp in case of Windows. The Linux kernel supports FUSE out of the box.
A big challenge at the moment is how to include WinFsp or FUSE for macOS in the installer. First test versions will therefore require manual installation of named libraries.
The benefit of using FUSE lies not only in performance enhancements (which are already clearly measurable in the current state of development for some file/directory operations) but also in the expected increase in compatibility with third-party software. There are several problems related to the WebDAV drive, as can be seen in our issues list.
During the Christmas holidays, I made all libraries and the desktop application compatible with Java 9. Our CI builds now run uniformly with JDK 9 in containers. However, the code is still compiled for older Java versions, not just because our Android app depends on it.
What’s the point? Java 9 is a huge step in the development of the Java platform. In addition to various bug fixes that directly benefit Cryptomator users, e.g. better support for HiDPI displays under Windows and Linux, there were massive refactorings which form the basis for a new release model of the Java platform with new feature releases in six-month cycles. This means that we will be able to benefit from new features in the future more rapidly without having to rely on unstable test versions.
However, the conversion to Java 9 with Cryptomator 1.4.0 is also the basis for the use of the Java Platform Module System from Cryptomator 1.5.0 onwards, whereby much smaller applications can be built. In a first test, the size of the Cryptomator application for macOS was reduced from over 200 MiB (in the installed state) to about 70 MiB.
We switched our build platform from Eclipse to IntelliJ because the JDK 9 compatible versions of Eclipse contain changes to the compiler that didn’t get along with code generated by Dagger.
Furthermore, our Android developers are already used to IntelliJ so that we can harmonize our tools a little bit here.
Since both WinFsp and JDK 9 require 64 bit, Cryptomator will no longer support 32 bit systems as of version 1.4.0. Although this is a pity, it also speeds up the development process because fewer systems have to be tested.
Cryptomator 1.3.x will be 100% compatible with 1.4.0. This means that users who depend on 32-bit software can continue to use Cryptomator vaults.
Did you find this insight interesting? Should we give an outlook for every major milestone in the future? We would like to hear your opinion in the comments!