The Madness of Microsoft Exchange

2017-09-04 in microsoft exchange
Abandon all sanity, ye who enter here! If ye can even find the way in.

Today is a rather unusual day. We will leave behind the comfort of the UNIX world; the thoughts of the comparatively well-engineered groovy; the joy of the comparative minimalism of Enterprise Java Beans. Today we take a trip to Redmond to gaze upon the monstrosity that is Microsoft Exchange, Microsoft’s PIM (email, calendar, and contacts) server.

Now, we’re not going to talk about actually setting up or running Exchange. This is something I have no experience with and certainly never will; there are many employment opportunities available that are less depressing and more fulfilling, such as decapitating rabbits with scissors or installing road signals for bicyclists.

Instead, we’re going to be talking about interfacing with third-party Exchange servers, including “Office 365”.

RxJava — The worst of all worlds

2017-08-31 in java

RxJava, short for “Reactive Java“, the Java implementation of the “ReactiveX” specification, is sometimes used to facilitate asynchronous or concurrent programming in Java, particularly in code from Netflix, its original implementor. It enjoys some popularity in the realm of server backend programming, and there appears to be surprisingly little criticism of it.

“ReactiveX” is an extension of the observer pattern and perhaps works well in realms where that pattern is actually used, such as GUIs. But nobody in their right mind writes GUIs in Java anymore outside a single mobile platform. RxJava is instead purported to instead be a solution to asynchronous tasks on the server, something for which the observer model is an extremely poor fit.

RxJava appears to draw people in on the basis of pretty diagrams that make it look easy to work with and vacuous conceptions of universality. In reality, outside of a very, very narrow space where it fits well, it brings far more harm than good.

Efficient Bounding Rhombi

A bounding box generally refers to an axis-aligned rectangular region of space used as a first, coarse step of collision detection. Every object is given a bounding box which covers all space the object could possibly occupy. If the bounding boxes of two objects overlap, the simulation needs to do a more precise but expensive collision check; but if they do not overlap, they certainly do not collide and the pair can be skipped.

Since Hexeline uses an oblique coordinate system, the same approach results in bounding rhombi instead of boxes, though that distinction is not particularly interesting here. What is interesting is how bounding boxes/rhombi can be handled extremely efficiently with SIMD. I fully expect that this technique has been discovered by someone else previously, but it’s still worth discussing.

Hexagonal coordinate representations in Hexeline

One of the central design principles in my still extremely early space shooter Hexeline (read: has neither space nor shooting) is that spacecraft will be defined in terms of a hexagonal grid, rather than cells of varying shape, which simplifies things for both the software and the player while still allowing more interesting shapes than a square grid.

A useful property of regular grids is that they are directly addressable; i.e., you can put the elements of an array and immediately access an element just by knowing its coordinate. Ideally, it’s also efficient to go from continuous spatial coordinates to a grid coordinate. This is trivial in a square grid: depending on how you define your coordinates, you can usually just divide spatial coordinates by the cell size to get the coordinate of the cell a point falls within.

In effort to get a similar property for hexagonal grids, I’ve taken the unusual step of basing a Newtonian physics engine on non-cartesian coordinates. It turns out this is not as bad as it sounds, and quite a few useful properties fall out of it.

Note: This post is going to be comparatively math-heavy and assumes some familiarity with linear algebra.

Java Anti-Pattern: Inconvenient Public Variables

2017-07-01 in java anti-patterns
The worst of both worlds

Encapsulation, in one form or another, is nearly universal in large-scale programming across languages. Isolating the code which can access certain state or data makes it easier to maintain and easier to reason about what impact changes to that state could have. In object-oriented languages, the unit of encapsulation is the class, and encapsulation is accomplished by making instance variables private and exposing a set of well-defined operations on that state in the public API.

JavaBean properties (a.k.a. “bean properties” or simply “getters and setters”) arose when the point about making instance variables private was applied universally without paying attention to the “well-defined operations” point.

Bean properties, particularly within an internal code-base or narrowly deployed library, are nothing more than inconvenient public variables.

The Generations of Java Style

2017-03-13 in java rambling

In the two decades of its existence, the Java programming language has gone through quite a few changes. Even more so, however, have the overall approaches to design and architecture in the Java ecosystem. I have found that these can by and large be separated into four generations which typically cut over relatively abruptly, immediately giving large code-bases of prior generations an archaic and poorly-designed feel.

“Groovy Strings” are here to make puns and cause chaos

2014-07-10 in groovy grails java
And their only pun is horrible.

Mundane Java has two types of character-type literals: character literals, enclosed in single-quotes, and string literals, enclosed in double-quotes.

1 /* Character literal, enclosed in single-quotes */
2 char ch = 'c';
3 /* String literal, enclosed in double-quotes */
4 String s = "This is a string.";

One of the first things not backwards-compatible with Java that a new Groovy user may notice is that single-quotes now delimit strings as well.

Groovy method calls involve lock contention

2014-01-26 in groovy java
A fractal of bad implementation

Suppose that we have a stateless but computationally-intensive piece of code involving a lot of function calls, which is for some reason written in Groovy.

SlowFib.groovy

1 package gl.lin
2 
3 class SlowFib {
4   static int fib(int n) {
5     n <= 1? n : fib(n-1) + fib(n-2)
6   }
7 }

Obviously, the algorithm here is pretty much the worst one possible — it has exponential run-time, but calculating the Fibonacci sequence can be calculated in linear time. But imagine for the time being that this is real code. The important thing is that this code makes lots of function calls. Also important is how the function is stateless — it accesses no data outside of its locals, and is non-virtual due to its staticness (ie, it could be called with one instruction were this native code).

Now say we want to write a program that maps a sequence of input integers to the corresponding Fibonacci number. A simple single-threaded implementation is below.

Gradle mixes your dependencies with itself

2014-01-19 in gradle
A fractal of bad implementation

Update 2017-03-04: Gradle no longer has these problems.

One of the most important features of the Maven family of build tools, of which Gradle is a member, is the ability to automatically download dependencies and configure the Java classpath. The latter often is the more important part of the feature — unlike virtually every other module-based environment, the JVM is bafflingly incapable of locating dependencies itself (eg, from a standardised location as in C).

Gradle’s implementation, however, is rather problematic. Virtually every task undertaken by Gradle — including simply invoking the javac compiler — involves spawning a child Gradle process, whose classpath includes that of the user code in question. This is perfectly fine as long as the user code’s dependencies are disjoint from Gradle’s; had gradle been written without any non-JRE dependencies, it wouldn’t be an issue at all.

But Gradle isn’t at all light-weight — its memory footprint dwarfs that of Windows XP — and it has almost as many dependencies as one might suspect.