Cautionary tale

Toyota is a cautionary tale for following good practice at software.

Friends don't let friends smash their own stack.

Explaining LISP right

Are you a C++ programmer? Sergey Mozgovoy explains LISP to you. Are you not a C++ programmer? This is still a good post. He discusses LISP well and concisely.

Doing Java file I/O right

Rick Hightower writes I wrote up a small example that shows how to use the FileSystem, URL, Reader, Pattern, Objects, InputStream, URL, URI, etc., really chock full of good practice tidbits. His post is focused on file I/O but the recommendations are good anywhere.

Signing maven releases with gpg while keeping your passphrase secure

On the road towards putting sample code into Maven Central I stumbled at GPG signatures of my artifacts. The problem was how to handle my passphrase.

The recommended solutions (one source of many) all had shortcomings:

• Prompting for your passphrase is often unuseful and is broken when running maven in Cygwin.
• Putting your passphrase on the command-line is visible to ps and is saved in history.
• Putting your passphrase into {{settings.xml}} leaves it on disk.
• Putting your passphrase on removable media and linking to it in {{settings.xml}} is awkward.
• Using a gpg agent would be best, but I did get everything hooked up right; I should investigate further.
• I will not even entertain removing the passphrase from my secrets just to satisfy maven.

A little think and some trial and error led me to:

1. In pom.xml enable maven-pgp-plugin and configure maven-release-plugin:

   <plugin>
       <artifactId>maven-release-plugin</artifactId>
       <configuration>
           <arguments>-Dgpg.passphrase=${gpg.passphrase}</arguments>
       </configuration>
   </plugin>

2. In settings.xml add a profile:

   <profile>
       <id>gpg-sign</id>
       <activation>
           <activeByDefault>true</activeByDefault>
       </activation>
       <properties>
           <gpg.passphrase>${env.GPG_PASSPHRASE}</gpg.passphrase>
       </properties>
   </profile>

3. Write a small helper shell script:

   #!/usr/bin/bash
   
   read -er -p 'Passphrase: ' gpg_passphrase
   echo # Get back newline
   GPG_PASSPHRASE="$gpg_passphrase" exec "$@"

The key observation is that environment variables are private to the process, in memory and transient. I invoke thus:

$ ./rls mvn clean verify
Passphrase:
[INFO] Scanning for projects...

Chaining exceptions in Java 7

I used to write code like this when transmogrifying an exception:

try {
    // Something broken
} catch (final RandomUninformativeException e) {
    final Bug x = new Bug(format("Sprocket sprung a leak: %s", e));
    x.setStackTrace(e.getStackTrace());
    throw x;
}

The intent was to turn a less meaningful exception into a more meaningful one. This was especially useful for log grepping. Most times I could chain the caught exception in the constructor of the thrown one (new BlahException(message, e)) but some exceptions do not have this constructor (e.g., NullPointerException).

With Java 7 I have a more expressive way:

final Bug x = new Bug(format("Sprocket sprung a leak: %s", e));
x.addSuppressed(e);
throw x

You may add as many suppressed exceptions as you like, they all show up nicely (output from some test code):

java.lang.NullPointerException: Outer!
 at scratch.ExceptionMain.main(ExceptionMain.java:11)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:606)
 at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120)
 Suppressed: java.lang.NullPointerException: Inner!
  at scratch.ExceptionMain.main(ExceptionMain.java:12)
  ... 5 more
 Suppressed: java.lang.NullPointerException: Second!
  at scratch.ExceptionMain.main(ExceptionMain.java:13)
  ... 5 more

State of the art Java lock-free queues

Nitsan Wakart writes on optimizing SPSC lock-free queues (single producer, single consumer) with lots of code samples, performance data and refernces. Even the comments are interesting. An excellent read to understand state of the art in Java.

A random blub:

There are a few subtleties explored here:

• I'm using Unsafe for array access, this is nothing new and is a cut and paste job from the AtomicReferenceArray JDK class. This means I've opted out of the array bound checks we get when we use arrays in Java, but in this case it's fine since the ring buffer wrapping logic already assures correctness there. This is necessary in order to gain access to getVolatile/putOrdered.
• I switched Pressanas original field padding method with mine, mostly for consistency but also it's a more stable method of padding fields (read more on memory layout here).
• I doubled the padding to protect against pre-fetch caused false sharing (padding is omitted above, but have a look at the code).
• I replaced the POW final field with a constant (ELEMENT_SHIFT). This proved surprisingly significant in this case. Final fields are not optimized as aggressively as constants, partly due to the exploited backdoor in Java allowing the modification of final fields (here's Cliff Click's rant on the topic). ELEMENT_SHIFT is the shift for the sparse data and the shift for elements in the array (inferred from Unsafe.arrayIndexScale(Object[].class)) combined.

Better Java properties handling

Luigi R. Viggiano provides OWNER API, a clever, better way to handle Java properties.

Essentially he maps properties in a general sense onto Java interfaces, using annotations to guide sourcing and processing. This is going directly into my projects.

I wrote a similar library based on interfaces to access properties, but using inheritance, implementation and generics with a set of helper base classes. His approach is superior.

@Sources({ "file:~/.myapp.config", 
           "file:/etc/myapp.config", 
           "classpath:foo/bar/baz.properties" })
public interface ServerConfig extends Config {
    @Key("server.http.port")
    int port();

    @Key("server.host.name")
    String hostname();

    @Key("server.max.threads");
    @DefaultValue("42")
    int maxThreads();
}

Interfaces to access properties is right. Among benefits you get strong typing of configuration and your IDE provides code completion.

HTML5 quoting

Great explanation in Quoting and citing with <blockquote>, <q>, <cite>, and the cite attribute.

PIP 446

From the difficulties of advancing a well-established code base:

We are aware of the code breakage this is likely to cause, and doing it anyway for the good of mankind. (Details in the section "Backward Compatibility" below.)

— PEP 446 -- Make newly created file descriptors non-inheritable