Joseph D. Darcy's Sun Weblog

Synaptic Sugar

When I misspelled "syntactic sugar" the other day, the helpful spell checker suggested "synaptic sugar" as a replacement, a replacement that fits surprisingly well! The goal of the best syntactic sugar, like the enhanced for loop in JDK 5, is to be sweeter for your brain by removing the need to see repetitive details, like the standard induction variable patterns.

Syntactic sugar makes tradeoffs between two general effects:

• A more explicit program is easier to understand.
• A shorter program is easier to understand.

These two effects are antagonistic; when the extra explicitness comes with a large increase in relative size, the greater verbosity outweighs the clarity of seeing everything written out. The trend to a more declarative programming style based on annotations favors the latter factor and the much briefer resulting programs. (2006-09-26 18:02:34.0) Permalink

Bug Tracking Blues Last week, I attended a talk by Matt Doar about Common Problems with Bug Trackers or, phrased more directly, Bug Trackers: Do They Really All Suck?. The talk was hosted by the Silicon Valley ACCU; I'm scheduled to give their October talk about common floating-point issues and misperceptions.

Matt had a number of interesting observations about the often mundane process of working with a bug tracker. First, a poll of the audience revealed that while nearly everyone uses a bug tracker regularly, no one loves their bug tracker. In contrast, many people will passionately defend tools for other infrastructural tasks like source code management (CVS, Subversion, etc.). A likely cause for this lack of affection is the multiple parties who use a bug tracker, engineers, quality organization, program management, and the disparate ways those groups use the tool and the resulting compromises in the tool's design. Matt identified four broad problem areas with bug trackers:

1. Designing Workflows (What is the state transition diagram?)
2. Meanings Of Fields (What does "priority" mean? How do priority and severity differ?)
3. One Bug, Many Releases (How should the same problem being fixed in multiple releases be tracked?)
4. Trusting History (Can time-based queries be performed?)

These are consistent with discussions and concerns I've had about bug trackers over the years. One observation was that a priority field should implicitly or explicitly include a notion of what party to whom the priority applies, the customer, engineering, testing, etc. (2006-09-20 11:47:06.0) Permalink

JSR 269 in proposed final draft I'm happy to announce that JSR 269 has progressed to the proposed final draft stage of the JCP process. This draft corresponds to the version of JSR 269 implemented in build 98 of JDK 6. Please send comments to jsr-269-comments@jcp.org.

Changes from the public review draft include:

• Adding originating elements var-args parameters to the Filer create methods to enable better management of dependencies.
• Changing the return type of the getFooName methods to a separate Name extends CharSequence interface.
• Revised Type visitor structure
• Included a description of the annotation processing discovery process.
• Various specification clarifications:
  • More explicit null pointer defaults.
  • The modeling API is meant to be used for multiple purposes, including but not limited to annotation processing.
  • More notes on anticipated evolution of the API.

(2006-09-18 17:44:45.0) Permalink Comments [2]

Iterating over the codepoints of a String Recently I wanted to iterate over the code points of a String instead of its char values. Unicode 3.1 added supplementary characters, bringing the total number of characters to more than the 2¹⁶ characters that can be distinguished by a single 16-bit char value. Therefore, a char value no longer has a one-to-one mapping to the fundamental semantic unit in Unicode. JDK 5 was updated to support the larger set of character values. Instead of changing the definition of the char type, some of the new supplementary characters are represented by a surrogate pair of two char values. To reduce naming confusion, a code point will be used to refer to the number that represents a particular Unicode character, including supplementary ones.

Therefore, a sequence of char values can be thought of as a variable-length encoding of a sequence of code points; the older characters (in the Basic Multilingual Plane) are represented by a single char value while the newer supplementary characters take two char values. The definition of language concepts, like identifiers, was rephrased in terms of code points instead of chars. The existing isFoo(char) methods in the Character class were augmented with isFoo(int) overload siblings using an int to store a code point value.

Previously, one way to iterate through the character values of a String was to look at each char value in turn:

String s = ...

for(int i = 0; i < s.length(); i++) {
    char c = s.charAt(i);
    // Process c...
}

Now, the chars need to be considered as possible members of a surrogate pair representing a single code point. Currently the canonical loop for this operation is:

String s = ...

for(int cp, i = 0; i < s.length(); i += Character.charCount(cp)) {
    cp = s.codePointAt(i);
    // Process cp...
}

At present, there is no direct API support for getting an iterator of the code point values from a String or CharSequence; perhaps one will be added in the future.

Glossary of Unicode terms (2006-09-18 16:21:22.0) Permalink Comments [2]

JDK 6 Build 97 and 98 JSR 269 API Changes Compared to build 96, build 97 only contained an assortment of minor corrections and clarifications to the API, such as fixing typos and adding additional cross references to sections of the JLS. The most systematic change was updating the javadoc of the methods in the utility visitor classes to follow the recommended pattern for methods intended to be overridden: state the general method contract (in this case with {@inheritDoc}) following by "This implementation...". This pattern is discussed in Effective Java (Item 15: Design and document for inheritance or else prohibit it) and is used in the skeletal collection implementations.

Build 98

• Tightened the specification of the Filer to disallow overwriting files in more situations.
• Added a description of the discovery process to Processor.
• Explicitly stated the language modeling hierarchy javax.lang.model.* can be used for purposes other than annotation processing.

(2006-09-07 10:22:53.0) Permalink

Recommended reading for compiler writers Some thoughts on this topic raised by Peter, while the Dragon book is certainly a classic and solidly covers the basics, it is now long in the tooth and doesn't cover important compilation and code generation concepts and techniques useful for more recent language environments, like the Java programming language and virtual machine. Requests for compilation references are a common question on the comp.compilers newsgroup and a number of recommendations (including the Dragon book) are listed in the group's FAQ.

For numerics related topics, Goldberg's What Every Computer Scientist Should Know About Floating Point Arithmetic discusses why not all floating-point "optimizations" that can be applied should be applied and Henry S. Warren's Hacker's Delight is a rich resource for low-level arithmetic tricks. (2006-09-06 19:04:29.0) Permalink