Creating a Java annotation

So I created a new (method-level) annotation that basically just takes a string, and when the target method is invoked, via aspect I get that string. The annotation looks like this (name changed to protect the innocent):

public @interface Annotatable { String value(); }

After a few hours of banging my head, trying to figure out why everything compiled correctly, yet when testing I could never get the find the annotation on the target method. Turns out, this was soooo poorly documented by Sun/Java gods, you need to annotate your annotation, like this:

import java.lang.annotation.*;

@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
@Inherited


The RetentionPolicy enum tells the compiler to keep the annotation around AFTER you compile, instead of throwing it away (like it does by default). The Target annotation tells the compiler which types of elements your annotation can apply to (classes, methods, params, all, etc.). The long and short of it is: don't forget to annotate your annotations.

NUMA and the JVM

Good blog entry from Jon Masamitsu about NUMA optimizations in Java 6 on Solaris. NUMA, essentially, and vastly simplified, is to access a region of memory that is physically closer to a processer on a multi-processor system. This way there's less latency when reading/writing to the general memory region. For Java, the optimizations are made primarily to the Eden (young generation) heap space, as well as assigning a thread to a particular CPU.

To enable the feature. it's a command-line param to the JVM at startup: -XX:+UseNUMA .

Java 6 threading article

An article on Java 6 threading optimizations recently appeared on infoq. It's a good article in two parts, but here I'm just going to capture some of the interesting notes about the different locking features now in the JVM (most of this entry is paraphrase - that is, notes to myself).

Escape analysis - determine the scope of all references in an app. If HotSpot can determine the refs are limited to local scope and none can esacpe, it can have the JIT apply runtime optimizations.

Lock elision - when refs to a lock are limited to local scope (for example creating an modifying a StringBuffer), no other thread will ever have access to object; hence it is never contended for. Then, you really don't need the lock anyway and can be elided/omitted.

Biased Locking - most locks are never accessed by more than one thread, and even when multiple threads do share data, access is rarely contended. Long story short, this makes subsequent lock acquisitions less expensive by holding onto lock until somebody else wants it. Java 6 does this by default now.

Lock Coarsening (or merging) - occurs when adjacent synchronized blocks may be merged into one (if same lock is used for all methods). For example. when calling a series StringBuffer append() operations. Locks are not coarsened inside of a loop because the lock will be held for (potentially) too long.

Thread suspending versus spinning - When a thread waits for a lock, it is usually suspended by the OS. This involved taking it off the stack, rescheduling, etc. However, most locks are held for very brief time periods (based on profiling), so if the second just waits a little bit without being suspended, it can probably acquire the lock it wants. To wait it just goes into a busy loop - known as spin locking. Was introduced in Java 1.4.2 with a default (fixed) spin of 10 iterations before suspending the thread.

Adaptive Spinning - Spin duration not fixed anymore, but policy based on previous spin attempts on same lock and state of lock owner. If spinning likely to succeed, will go for a longer iterations count (say, 100); else, will bail on spinning altogether and suspend.
Introduced in Java 6.

devWorks Benchmarking article

This is a great article from the IBM devWorks site about Java performance benchmarking. I'm just capturing some notes in this entry.

Measuring time:

1. System.currentTimeMillis() - gets the "wall clock" time, but the updates from the OS are hardware dependent and may only occur every ~10 ms. call to OS returns instantly
   
2. System.nanoTime() - returns a differential time, measured in microseconds, bu the call to the OS itself can take microseconds.
3. ThreadMXBean - JMX extension that offers to read a Thread's CPU usage (may be misleading due to I/O and it's uage may be expensive)

Code warmup:

• Class loading can be observed via ClassLoadingMXBean
• Most VMs run the code for while in interpreted mode to gether stats before performing JIT compilation. Sun's Hot Spot defaults: 1500 time for client VMs, 10,000 for server. Could use CompilationMXBean to measure JIT time, but impl is hosed. Alternative is to watch stdout with -XX:+PrintCompilation JVM option
  

Grails + email service

Alright, finally getting back into to grails coding after a long time away. For my test pet store application, I decided to take a day and create newsletter sender. Basically, it just takes an email address (submitted via a little form widget thingy), and stores it in a separate table the database. I'm not bothering with user accounts yet for the site, so I'm just keeping it in a stupidly simple table with just a database id and the address itself. There's also a controller function for removing an address from the list (handy I should think).

Now that I've got email addresses to send to, I need to actually send the newsletters. Before tackling that, though, I want to send out the newsletters on a periodic basis, so i need a scheduling/cron like component. I decided to use the Quartz plugin for Grails. We use it at my $DAYJOB, and it's been an excellent workhorse there. After installing the plugin (grails install-plugin quartz), and creating a job (app-home/grails-app/job/SendNewletterJob.groovy), I was 80% done. I just had to define my scheduling and implement the execute() method, which calls my message send service. Easy! Here's my source:

class SendNewsletterJob {
def timeout = 9000l //runs every nine seconds (only for testing!)
def emailService

def execute() {
emailService.sendNewsletter()
}
}

Now for actually pushing the newsletter to the users. I created an app-home/grails-app/services/EmailService.groovy. In Grails parlance, from what I understand, a "service" is not a web-service (REST or SOAP), per se, but more like the Eric Evans DomainDrivenDesign notion of a service. Currently (May 2008) there is no nice plugin for sending email, but there is a nice document on the Grails site that describes how to create a mechinism that wraps Spring mail. I just ripped off the example EmailService, dropped my smtp host values into my grails-app/conf/spring/resources.xml, and I'm business.

Altogether, this project took less than four hours, most of which was fishing around playing with config settings and such. I'm trying to think what the parallel time investment would have been for a straight-up Java implementation. Hmmmmm.........

Pat Helland speech

Wow - another reason why Pat is truly one of my heros: Speech from 2007 TechEd EMEA

Starting with Grails

In an effort to branch out an learn my "one language per year" like a good little developer, I've decided to start tooling around with Groovy and it's most famous offspring, Grails. I spent a week on a test app just to get my feet wet with the Grails conventions for GSPs/Controllers/Domain object and such, and I must admit that it's been soooooo easy to get things up and running. And not having to recompile and bounce the web-app every time I make a change is nice - even though when I change a domain class the web-app bounces itself (controllers are better in this regard).

For a nice-sized project with Grails, I'm going to implement a basic e-commerce site as I have a little bit of experience in that domain :). I'm planning on attacking it in a TDD manner, and applying lots of YAGNI (wow, I really need to master that skill!). I'm also going to integrate with Google Checkout for doing purchases - all test/beta/sandbox, nothing for real. I've done integrations with credit card processors, loyalty point programs, and PayPal, so I figured I'd checkout Google's API and see what I find.

I'm also curious to see how grails can deal with HTTP header things like ETags and If-Modified and such. I'm not totally sure if that's the domain of the web-app or web server, but I'm itching to find out - as I'm on a limited bandwidth host, and I need to conserve by bandwidth bytes!

More reports as I progress.

Apache HTTP Client and proxy settings

I don't how many times I've had to do it (and how many times I've screwed it up), but I can never remember just how to set up proxies for Apache HTTP Client. So, to keep a record of my googling and experimenting, here's the entries that really helped:

• Java, Commons HTTP Client and HTTP proxies (Aaron Johnson). Check this the first example if you just need to set proxy name/host.
  

• jGuru - just the last thread comment (Vivek Singh - Aug 16, 2007). Check this out if you need to set authentication parameters, as well.
  

Essentially here's what I ended up with (if you just need proxy name and port):

HttpClient client = new HttpClient();
client.getHostConfiguration().setProxy(proxyHost, port);