bdkosher

import groovy.transform.Field
@Field def _ = [do: { body ->
    [while: { condition ->
        body()
        if (condition()) call(condition)
    }]
}]

String formatMillis(int x, int forcedDigits = 3, int dstIdx = 0) {
    if (x > 999 || x < 0) {

bdkosher

A "Principled," Blameful Post-Mortem

(I also considered calling this post "Why I Hate Dates: Reason #761.")

I encountered a production bug a few months back. An error was occuring during a system-to-system transaction executed through an HTTP POST. The server responded with a 200 OK, but the client failed to parse the XML payload, resulting in a failed transaction. The failure happened only on occassion, however, and there was no discernable pattern for when they occurred.

The server-side implemented the HTTP endpoint through a Spring Surf Webscript (which immediately tells you that this is an Alfresco Share customization--nothing else in the known universe is built with Spring Surf). Surf Webscripts use Freemarker for rendering the view. The template for formatting the sometimes problematic XML payload looked innocuous:

 <document><#setting number_format="0"><#setting time_zone="GMT">

${doc.obj

bdkosher

import java.util.function.Supplier;

public <T extends Throwable> void amIcrazy(Supplier<T> s) throws T {
    throw s.get();
}

bdkosher

/* 
 * Groovy has a controversial feature to call a single-arg method w/ null when no arg is passed.
 * Equally surprising, if the first arg is an array, Groovy auto-passes an empty array instead
 *
 * Groovy has a useful feature called multiassignment. It's innocuous looking but not very forgiving;
 * if used on a null or empty array, it will throw NPE and IndexOutOfBoundsExceptions respectively 
 */

String m1(String arg) {
    def a = arg

bdkosher

Differentiating State and Dependency Fields in Java

A recent DZone article reminded me of a question I've been privately grappling with:

What is the best way to visually differentiate state fields from dependency fields within a Java class?

This may lead you to grapple with a question of your own: Why would you care?

Well, if you're maintaining an existing code base, you want to be able to get up to speed quickly. To do that, you'll need to read code. Conventionally, fields are placed at the top of a class, so they're one of the first things you notice when reading code. The more information you can learn from looking at the fields alone, the more quickly the class can be understood.

bdkosher

Class.metaClass.and << { arg -> false }
org.codehaus.groovy.runtime.NullObject.metaClass.and << { arg -> false }

assert (void & null) == (null & void)

bdkosher

BATCH_FILES=/cygdrive/c/Users/jwolf2/bin/*.bat
for bfile in $BATCH_FILES; do
  bname=${bfile##*/}
  bcmd=${bname%.*}
  alias $bcmd=$bfile
done

bdkosher

import java.util.concurrent.*

def WEB_SERVICE_URL = new URL('http://localhost:8080/example/search?q=ornithology&rows=50')
def THREADS = 3
def TASKS = THREADS * 4

def exec = { url ->
    def start = System.nanoTime()
    Thread.sleep(3000) // new JsonSlurper().parse(url)
    def end = System.nanoTime()

bdkosher

String shiftCipher(String text, int amt = -3) {
    new String(text.toUpperCase().chars.collect { c ->
       c < 33 ? c : (c - 65 + (amt < 0 ? 26 + amt : amt)) % 26 + 65
    } as char[])
}

(-25..25).each { amt -> println "$amt: ${shiftCipher('WKH TXLFN EURZQ IRA MXPSV RYHU WKH ODCB GRJ', amt)}" }

bdkosher

JAX-RS 2: Custom @Context Injection of a Limited, Thread-Unsafe Resource

I've been working on wrapping a stateful CGI/Perl web application in a stateless, RESTful interface using JAX-RS 2. Besides the mechanics of interacting with the CGI/Perl web application (think judicious use of HTTP clients and HTML scraping), one challenging aspect has been ensuring that simultaneous requests to the REST service do not end up sharing a CGI/Perl application session.

Each request must establish and end a session for a particular webapp user; any incoming requests during that time should not establish a session with that same user.

My initial idea was to customize Tomcat's thread pool executor so that each thread was bound to a particular user. I made progess in this area, but abandoned the approach after struggles with the under-documented tomcat7-maven-plugin. Besides, I was leery of being coupled to Tomcat at such a low level given how my custom org.apache.catalina.Executor "borrowed" heavily from the [standar