Sometimes you want to distribute a program without requiring users to install a long chain of dependencies. Typically we can do this by building a statically linked binary; for example, by passing the -static flag when linking with gcc. Apple, however, does not support statically linked binaries, so this approach won’t work on Mac OS X. Apple does, however, support statically linked libraries. This means we can get pretty close to what we want: we’ll statically link user-space libraries into our binary, but we won’t statically link with system libraries or the kernel.

To make this approach work, we need to hide all of the user-space shared libraries during the linking phase of our build process. The Apple linker always prefers shared libraries when it can find them, but will revert to static libraries in the absence of a shared library. I’ve yet to find a command-line parameter to change this behavior, but a brute-force solution is available. Essentially, we want to rename every shared library in /usr/local such that it no longer ends in .dylib, link our program, then put all of the shared libraries back the way we found them. I wrote this Python 3 script to automate the process. To temporarily hide the shared libraries on your system, run it like this:

$ ./hide-shared-libs.py -d /usr/local --hide

To restore your shared libraries, use the following command:

$ ./hide-shared-libs.py -d /usr/local --restore

Of course, this assumes that you have static versions of all of the libraries you intend to link with. By default, not all software will install static libraries. I use Homebrew to build software on Mac OS X, and have needed to add --enable-static to the configure parameters for a few packages. Once you rebuild with this parameter, however, static linking should work as expected.

Service discovery in Java is not as simple as it should be. Apple’s reference implementation, Bonjour, is ironically very difficult to setup on Mac OS X (for JavaFX at least). Alternative pure-Java implementations exist, but I’ve yet to find one that identifies services quickly, offers configurable logging, and is robust enough to tolerate the mDNS responses generated by a 3rd-generation Apple TV (seriously, this kept crashing one of the services I tried). While the system-wide service design provided by Bonjour and Avahi is ideal for reducing network traffic via caching, it also adds an additional software dependency that is outside the control of an app developer.

Enter Hola, a dead-simple, pure-Java implementation of Multicast DNS Service Discovery (mDNS-SD). Zeroconf networking promises incredible ease-of-use for end users, but to encourage adoption that simplicity should extend to developers as well. Thus, Hola has been designed with low requirements and a (hopefully!) intuitive API. Want to find every TiVo on your local network? Here’s the code to do it:

try {
    Service service = Service.fromName("_tivo-mindrpc._tcp");
    Query query = Query.createFor(service, Domain.LOCAL);
    List<Instance> instances = query.runOnce();
    instances.stream().forEach(System.out::println);
} catch (UnknownHostException e) {
    logger.error("Unknown host: ", e);
} catch (IOException e) {
    logger.error("IO error: ", e);
}

Each returned Instance will have a user-visible name, a list of IP addresses, a port number, and a set of attributes:

String userVisibleName = instance.getName();
List<InetAddress> addresses = instance.getAddresses();
int port = instance.getPort();
if (instance.hasAttribute("platform")) {
    String platform = instance.lookupAttribute("platform");
}

And that’s it. To search for different services, just change the String passed to Service.fromName(). Right now only synchronous operation is supported, but I plan to add an asynchronous listener in the next release. As for requirements, Hola depends on nothing beyond Java 8 and SLF4J.

Development is hosted on GitHub at https://github.com/fflewddur/hola and pre-compiled JARs are available. If you’re looking for Java-based service discovery, give Hola a try. As always, comments and bug reports are welcome.

I recently needed to use Qualcomm’s Turing stream cipher for a Java project. Some Googling found a Java port of Qualcomm’s C++ reference implementation, which behaves almost exactly as expected: its output is always correct, but its runtime is significantly slower than the C++ implementation. As in, an order of magnitude slower. If this were the late ’90s, such a performance difference between C++ and Java might be expected… but it isn’t, so it’s not.

Digging into the code revealed several areas that required sequential execution, thus preventing HotSpot’s JIT-compiler from really going to town in its optimizations. Qualcomm’s implementation, by contrast, makes liberal use of loop unrolling and bit-parallel operations. By turing as many of these sequential operations as possible into bit-parallel operations, we can help the JVM perform more operations per clock cycle and allow it to inline critical methods.

Starting with the existing Java port as a base, I ported over the bit-parallel optimizations from Qualcomm’s implementation, in the process eliminating most of the loops requiring serial execution. The results are stark: with the original Java port, VisualVM showed that decrypting a 14 GB file resulted in 38.5 seconds spent in the Turing code. By contrast, the optimized variant spent only 5.8 seconds in the same code.

Qualcomm’s license allows both source and binary modification and redistribution, provided they are credited for Turing’s development. If that license suits your needs and you need a fast Java implementation of the Turing cipher, my port is available on GitHub as QuickTuring. Comments and bug reports are welcome.