The goal of this particular implementation was to be highly algorithmically efficient, so no hidden computational costs of regex which could otherwise lead to quadratic, or worse time complexity. That's why everything is "coded by hand".

The decodeBits() method is linear time, and generally a fast linear time due to an early return optimization in the findTransmissionRate() method which can return early as long as the "bit rate" is not 3 or 7, (both of which are valid "character" lengths). The runtime of the bitstreamToMorse() method is bits.length() / rate where rate is the "bit rate" of the string so may be extra fast as long as rate > 1.

The decodeMorse() method also runs in linear time.

Last line should be return openingBraces.isEmpty();

Another accidental submission. I absolutely hate how when you make some change to the code while refactoring after a successful attempt but hit ctrl-z to remove the change in the editor it changes the "Attempt" button back to the "Submit" button.

i = -1; should probably be i = (i > 1) ? i - 2 : -1; (or some such) as an optimization.

This part:

directions.remove(i + 1);
directions.remove(i);

Could have been written:

directions.remove(i);
directions.remove(i);

But I, personally, think the first version is easier to understand at a glance.

Should have read the BigInteger documentation more thoroughly to discover the BigInteger.nextProbablePrime() method. The program was originally long primorial = 1 rather than BigInteger primorial = BigInteger.ONE; hence the original need to generate the primes manually. With that in mind, the numPrimorial() method would look like this:

public static String numPrimorialBigInt(int n) {

    if (n == 0) { return "1"; }

    BigInteger primorial = BigInteger.ONE;
    BigInteger nextPrime = BigInteger.TWO;

    for (int i = 0; i < n; i++) {
        primorial = primorial.multiply(nextPrime);
        nextPrime = nextPrime.nextProbablePrime();
    }

    return primorial.toString();
}

And that would be the entire program.

Factored out getDecompString(factors) and now each function has a very clearly-delineated purpose. The performance is IMO rather good, 600-700 ms on the main test. I can't really think of any way of speeding it up without sacrificing too much from the readability which would be counter to my personal purposes which is to make cleaner, more maintainable code, hence the use of short, clearly-defined functions.

Obsolete version. I forgot to cast loop condition variable to (int)

double sequenceLength = Math.sqrt(max);

should be

int sequenceLength = (int)Math.sqrt(max);

This was an accidental submission before refactoring, hence the superfluous if (snail.size() == totalSize) { break start; } statements...

I keep accidentally submitting things when I mean to refactor them first and there's apparently no way to delete old versions... Anyway, this version is obsolete.

I wanted to see if I could make myself barf coming up with this disaster.