So it seems I'm exhibiting a huge amount of naivety about how car rental works at Budget Inc. Four strong indications:

1. Assumption: the online reservation system "knows" about the number of cars available at a rental location. It will not let you make a reservation when no cars are available and it will not send you a "confirmation" mail saying "your rental car has been reserved".
2. Assumption: Representatives at the rental location are aware of your reservation and are expecting you at the time indicated therein.
3. Assumption: A representative that - after debunking assumptions 1 & 2 - offers to transfer your reservation to another location nearby has a better overview of availability in her software and will make sure a car will be waiting for you there.
4. Assumption: The map handed to you by the representative actually carries the correct address of that other location.

Needless to say, all four assumptions have been proven wrong at Budget Embarcadero, San Francisco, and FWIW said representative had already closed shop by the time #3 came to pass. It wasted like 2 hours of a precious Saturday that I had planned to spend on the road - boy am I pissed. And I just refuse to accept the idea of having to question every statement made by a representative and jotting down the name of every person I talk to. Get your shit together, Budget, before I rent with you again.

Reginald quotes Blodgett's Law and points to verbos languages:

A development process that involves any amount of tedium will eventually be done poorly or not at all.

If I read him correctly, Reginald is trying to say: "Programming Languages that require a handwritten test suite to prove basic type correctness will eventually be abandoned." Happily trolling away ...

Yet another installment in that long list of pleasant surprises (example made up). Imagine I've written a method that takes a map and prints its entry set. Now I want to generalize this method to print any set and to make the caller pass in the entry set himself. Highlight map.entrySet() and press Apple-Alt-P:

Notice the last option "Remove parameter no longer used"? It makes my refactoring just one consistent operation, one I'm doing quite regularly and this is really just awesome. Steve Yegge dismisses it as "industry excitement about manipulating code as algebraic structures". He's happier pushing around compressed ASCII. Matter of taste.

Anyway, making my employer buy IDEA licenses is already a form of positive feedback, but I think it's about time to extend a BIG thank you to the guys at JetBrains. You have fundamentally and continually improved my work experience over the last >5 years --- I can't even remember anymore when I retired emacs. Cranking out and massaging code is what I do and every friction removed helps keep me sane.

</vendor-promotion>

There are so many complaints that variable declarations in Java are written like so: type var = new type();.

Not in my IDE. In my IDE, it's: new type() CTRL-ALT-V/F/C var RETURN. Or type var = new SHIFT-CTRL-SPACE RETURN. And should I want to change the type, I typically rinse and repeat.

This is not to say that it doesn't inhibit readability and that a compiler shouldn't do the job. But people who actually type the type twice today simply don't use the right tool.

[2008-01-06] Kevin writes: You must be joking. That's not type inference. Of course I'm joking and not. Type inference refers to the process performed by the programming environment that fills in -redundant- type declarations that have been omitted from the source code, typically in two cases: variable declarations (type is that of the initialization expression) and function calls (type parameters derived of value parameters' types). This process is hopefully defined by the language specification.

However, we have to keep in mind that this definition is very focused on the textual input that is source code. The underlying assumption is that the programmer types and reads the source code as a sequence of characters --- so we need the source code to be as concise as possible. I'm saying that we need to factor programming environments in more. I'm saying I don't need type inference for locals as badly as other people seem to because my interface to Java is much more than the JLS and a text editor, my IDE helps me.

There are more examples like this. No one argues against long variable names because they are so hard to type. Opponents of extension methods as recently proposed say that a reader of a call site can no longer figure out easily where the method is defined. Not in my world: CTRL-Hover over the symbol and I see the definition site. Smalltalkers don't ever bitch about the class definition syntax since they almost never see it. And why has no one ever proposed getting rid of the package declaration statement in Java although it is predetermined by the directory location? Exactly, no one writes these by hand anyway.

In the end it's a language vs tool argument: what I say makes the IDE great, linguists say they wouldn't need if the language were better. Don't get me wrong, I'm all for local variable type inference. And I loathe code generation. I'm just getting pretty tired of endless my language vs your language when the comparison is based on the textual representations and not on the net programming effort.

[2008-01-07] Rémi and Ben raise an important point below: some types cannot be written down in Java, especially of anonymous inner classes.

Comments

 list = null;
foo := null;   // inference here
list.add(foo);
]]>

JAXB is great. Not a doubt. Just as an academic exercise, in order to write a big document, can we avoid building the object graph in advance? Could we still profit from strongly typed binding? The best answer I found was this:

Write an interface that corresponds to your complex type. Where JAXB expects a property to read from, have a method that accepts a closure that accepts an instance of the child element type. For elements of simple type, provide a simple setter:

          public interface Artist {
          public Artist name(String name);
          }

          public interface Album {
          public Album artist({Artist=>Void} artist);
          public Album title(String title);
          }
        

In order to produce an Xml document with this, we need to bootstrap ourselves an Album instance and write through typed calls:

          write("album", Album.class, {Album a =>
          a.title("mein leben")
          .artist({Artist a =>
          a.name("Charlotte Saenger")
          })
          });
        

Not pretty. The best I could think of. Seems like this won't have a great future... Just for the sake of completeness, an implementation _sketch_:

          public class StreamBinder {
          Model m;
          ContentHandler out;


          <T> void write(String uri, String element, Class<T> c, {T=>void} t) {
          out.startElement(uri, element, "", new AttributesImpl());
          t.invoke(bind(c));
          out.end(uri, element, "");
          }

          <T> T bind(final Class<T> c) {
          return c.cast(Proxy.newProxyInstance(c.getClassLoader(), new Class[] {c}, new InvocationHandler() {
          public Object invoke(Object o, Method method, Object[] args) throws Throwable {
          String uri, element = model.lookup(c, method);
          Class elementType = model.lookup(c, method);

          // ##handle simple content
          write(uri, element, elementType, args[0]);
          return o;
          }
          }));
          }


          public static void main(String[] args) {
          model = reflectOver(Album.class);

          new StreamBinder(out, model)
          .write("album", Album.class, {Album a =>
          a.title("mein leben")
          .artist({Artist a =>
          a.name("Saenger")
          })
          });
          }
          }
        

So I tried Transmit, Forklift and S3cmd and _none_ allows me to set the content-type. Only s3cmd can make items world-readable in an easy way. I can't believe I just had to hack s3cmd to make '--mime-type' work.

Also sad: this file as application/atom+xml would be spec compliant, but Camino only renders application/xml. So I'm going to stay with xml I guess...

I want to second Harry and Patrick's comment over at Bill's blog. I think all of Bill's concerns can be addressed:

Trust: If you have multiple clients, you need to do access control anyway (they might PUT to each other's items, even if created by POST).

Accidental overwriting: handled by 'If-None-Match'.

Conflicts: with PUT, you can route requests according to URI and do efficient conflict resolution/avoidance on the local server shard.

Apart from idempotency: let's remember that Atom is for syndication - that typically entails already existing items with client-specific ids. That an Atom server forces its own id space onto me that I need to map to mine is a nuisance, not a feature. And for the really stupid clients: serve an Atom feed of fresh, unused ids.

On the same level, I've never been into the "primary keys must be database-generated" mantra.

As a consequence of my move to Zurich, I had to change providers for mernst.org. I was torn between two extremes: a "real" server where I could experiment and put Java services on the web and a minimalistic approach where http file delivery and mail run with the big guys. I have chosen the latter route - a mere domain registration with a german provider, http traffic is CNAMEd to my bucket www.mernst.org at Amazon S3, email lives on Google Apps.

What I'm still looking for is a free/pay per usage service that would accept [captcha'd] [XHR] POST requests for my domain, store them and offer them as a feed that I could process at my discretion, i.e. when I'm online.

When you deal with non-blocking IO your IO tasks turn from methods into state machines. You do some IO on every transition, each state representing what kind of IO you would like to do next. In combination with something like theyielder iterator byte rewriting framework, we can turn these back into iterator methods that yield interest sets, making NIO a little easier again:

          // this is sample code that neither implements proper error handling
          // nor a tunable buffer allocation policy or anything ...
          // it just demonstrate how an NBIO task looks as an iterator of InterestSets
          public class Copy extends Yielder<InterestSet> {
          public final ReadableByteChannel source;
          public final WritableByteChannel target;

          public Copy(ReadableByteChannel source, WritableByteChannel target) {
          this.source = source;
          this.target = target;
          }

          protected void yieldNextCore() {
          try {
          ByteBuffer b = ByteBuffer.allocate(4096);
          while (true) {
          switch (source.read(b)) {
          case -1: // EOF
          yieldBreak(); return; // yieldBreak() actually necessary?
          case 0:
          yieldReturn(new InterestSet().read(source));
          break;
          default:
          b.flip();
          while (b.remaining() > 0)
          if(target.write(b) == 0) yieldReturn(new InterestSet().write(target));
          }
          }
          } catch (IOException e) {
          // hmm what about that
          }
          }
          }

          ... where:

          public class InterestSet {
          public final HashMap<Channel, Integer> interestSet = new HashMap<Channel, Integer>();
          public Long delay;

          public InterestSet withInterest(Channel c, int op) {
          interestSet.put(c, or(interestSet.get(c), op));
          return this;
          }

          public InterestSet waitFor(long delay, TimeUnit u) {
          this.delay = TimeUnit.MILLISECONDS.convert(delay, u);
          return this;
          }

          public InterestSet read(Channel c) {
          return withInterest(c, SelectionKey.OP_READ);
          }

          public InterestSet write(Channel c) {
          return withInterest(c, SelectionKey.OP_WRITE);
          }

          public InterestSet connect(Channel c) {
          return withInterest(c, SelectionKey.OP_CONNECT);
          }

          public InterestSet accept(Channel c) {
          return withInterest(c, SelectionKey.OP_ACCEPT);
          }

          private int or(Integer a, int b) {
          return a == null ? b : a|b;
          }
          }
        

Disclaimer: I haven't actually run this code yet - just to get an idea how it would look like.

Comments

Three steps of refactoring I often perform: given a complex expression exprA(exprB)

• extract local "b" on exprB: b=exprB; exprA(b)
• extract method "a" on exprA: b=exprB; a(b)
• inline local "b": a(exprB)

Wouldn't it be great if this were part of the extract method refactoring? I.e. you get to choose subtrees of the expression's AST to form the parameters?

Example at hand: my expression is "interestSet.get(ch)|op" and I want to extract a method "or(Integer a, int b)" where "interestSet.get(ch)" would form the first parameter. In the next step I would change the method to return "a == null ? b : a|b".

The Java language specification requires that a call to a super(...) be the first statement in a constructor. That rule has often felt overly restrictive to me. For example, it forbids code like the following:

          Constructor() {
          T local = expr;
          super(local);
          }
        

However super(expr) is allowed although both versions are provably equivalent. What's the motivation behind that rule? It's twofold: one, it garantuees that we do call a superclass constructor. Two, it (kind of) garantuees that we do not access "this" before that. The second point is kind of moot because the compiler still has to prove that "expr" does not access "this" either.

The whole situation reminds me very much of definite assignment: with JDK 1.1, the rules for initialization of local final variables were relaxed. You do not need to provide an initialization expression at the point of declaration but you can assign a value later, iff the compiler can prove that a) you only assign once and b) you do not access the variable before.

I personally believe :-) that the same relaxed rule could be applied to super constructor invocations. Take http://java.sun.com/docs/books/jls/third_edition/html/defAssign.html, replace the variable by "this", "definetely assigned" by "definetely initialized" and "assignment expression" by "super constructor invocation". Then the following code could be legal:

          Constructor(x) {
          if(x != null) {
          super(x);
          } else {
          super();
          }
          }
        

Am I missing something?

Comments

 max) { throw new IAE(...); }
   super(min, max);
 }
}

Typically validations are single, such as

class Derived extends Range {
 public Derived(int min, int max) {
   super(min, max);
   if (min < 0) { throw new IAE(...); }
   if (max < 0) { throw new IAE(...); }
 }
}

This you can get away with using a validation method, but it's ugly.

class Derived extends Range {
 public Derived(int min, int max) {
   super(isNonNegative(min),
       isNonNegative(max));
 }
 private static int isNonNegative(int val) {
   if (val < 0) { throw new IAE(...); }
   return val;
 }
}

I'm not a language designer, but I'll ask: how about getting multiple return values? Then we could have

class Derived extends Range {
 public Derived(int min, int max) {
   super(validate(min, max));
 }
 private static int validate(int min, int max) {
   if (min < 0) { throw new IAE(...); }
   if (max < 0) { throw new IAE(...); }
   if (max < min) { throw new IAE(...); }
   return (min, max);
 }
}        ]]>

I've always enjoyed walking to the office on good weather (in Hamburg that means no rain), a habit that I'm determined to continue in Zurich. Here's a rocky rendition of my round about 25 minute commute, shot from the hip every ten seconds, stitched together with iMovie:

On a side note, I'm amazed how, let's say old fashioned the Youtube upload form is. Empty required fields are flagged only after submit/reload, the categories combo and my location map are reset in that moment. Not to mention that I have to invent yet another user name, even if I log in with my Google account - the obvious ones have already been harvested, of course.

Comments

Friday was my last day atCoreMedia, after a long long time. I've had a great time and got to work with a bunch of people I highly respect. Fare well!

Later this year, come find me in Google Zurich.

Folks, thanks for all the good wishes!

Comments

Some interesting stuff I've been working on recently: the never ending story of object-relational mapping. Instead of breaking objects into relations, I've looked into mapping annotated classes directly onto Oracle user-defined object types, or basically records.

What you get is: in combination with VARRAYS you get arbitrary nesting and can persist an object tree in a single column. It's about the same usage model as with XML serialization: if you can get used to non-cyclic, non-shared, trees of value objects you'll like it. Performance is great, on the order of several hundred items per second on a standard PC with Oracle/XE. In contrast to just serializing blobs, the database actually understands your schema and we can define indexes on simple properties or easily have the database server maintain index-organized tables for joining against property paths that may be array-valued. All important operations can be performed in single statements, no hidden roundtrips to maintain several tables or open/close lobs are necessary. (Actually not a 100% true, creating an instance of a struct requires to acquire a StructDescriptor first but that can be reused for all instances in the same batch).

No object identity, no sessions to flush, no second-level cache: this is just about making the database understand structured complex values. I'm beginning to think of it as my JAXB for persistence.

I would like to see this on other databases but the support for structs and arrays and their respective JDBC counterparts doesn't look great. On DB2, it seems like the path leads to their XML store anyway.

How simple-minded have I become? Patrick Logan holds a hammer to my knee and my immediate jerk: "by no means does that pattern matching look particularly readable to me" and "I can do it just as well in Java". Although that is indeed the case, it isn't Patrick's point and I also thought I had long given up on contests like these. It must be some kind of allergy striking as soon as one topic becomes too popular. So just for your reference:

 codes = new HashMap() {
    {
      put('A', ".-"); put('B', "-..."); put('C', "-.-."); put('D', "-.."); put('E', ".");
      put('F', "..-."); put('G', "--."); put('H', "...."); put('I', ".."); put('J', ".---");
      put('K', "-.-"); put('L', ".-.."); put('M', "--"); put('N', "-."); put('O', "---");
      put('P', ".--."); put('Q', "--.-"); put('R', ".-."); put('S', "..."); put('T', "-");
      put('U', "..-"); put('V', "...-"); put('W', ".--"); put('X', "-..-"); put('Y', "-.--");
      put('Z', "--..");
    }
  };

  public static List decode(String morse) {
    ArrayList result = new ArrayList();
    decode(morse, "", result);
    return result;
  }

  private static void decode(String morse, String partial, ArrayList result) {
    if (morse.length() == 0) {
      result.add(partial);
    } else {
      for (Map.Entry entry : codes.entrySet())
        if (morse.startsWith(entry.getValue()))
          decode(morse.substring(entry.getValue().length()), partial + entry.getKey(), result);
    }
  }

  public static void main(String[] args) {
    System.out.println("decode(\".-\") = " + decode(".-"));
    System.out.println("decode(\"...---..-....-\").contains(\"SOFIA\") = " + decode("...---..-....-").contains("SOFIA"));
    System.out.println("decode(\"...---..-....-\").contains(\"SOPHIA\") = " + decode("...---..-....-").contains("SOPHIA"));
    System.out.println("decode(\"...---..-....-\").contains(\"EUGENIA\") = " + decode("...---..-....-").contains("EUGENIA"));
    System.out.println("decode(\"...---..-....-\").size() = " + decode("...---..-....-").size());
  }
]]>

Generics haven't really arrived in relective libraries yet. Most libraries reflect over class objects, not types. For example, while JAXB knows how to marshal a List<X>, when presented a Holder<X> it will reflect over the erased Holder.class and conclude that its value is of type Object, not X. Note to self: whenever designing a reflective library I will try and accept instances of Type from now on. Gafter's Gadget will be helpful as the user's input device.

Here's some handy code that helps you resolve member types in instantiations of generic types:

 classOf(ParameterizedType pt) {
    return (Class) pt.getRawType();
  }

  private static ParameterizedType cook(Type t) {
    if (t instanceof ParameterizedType) return (ParameterizedType) t;
    if (t instanceof Class) {
      Class c = (Class) t;
      Type[] args = new Type[c.getTypeParameters().length];
      for (int i = 0; i < args.length; i++) {
        throw new UnsupportedOperationException("Can't (yet) construct a wildcard argument to " + t);
      }
      return ParameterizedTypeImpl.make(c, args, c.getEnclosingClass());
    }

    // have I missed a case?
    throw new IllegalArgumentException(String.valueOf(t));
  }
        ]]>

Example: what type has iterator() in a LinkedList<String>?

    java.util.Iterator
      ]]>

Note that in their infinite wisdom, Sun have made the type hierarchy into interfaces with private implementations and you're invited to either re-implement them yourself or cross your fingers that sun.reflect.generics.reflectiveObjects.* is not gonna go away. A public concrete class in java.lang.reflect would have done the job, too, IMHO.

Comments

Eamonn McManus @ 2007-08-02 04:38:06 PDT:

Bill de hÓra:

"... Django will calculate an ETag for each request by MD5-hashing the page content, and it'll take care of sending Not Modified responses, if appropriate." That's it - you're done.

Just an observation: a Java web framework that collects all its output into a string before sending it to the client would be considered a poor, if not amateur implementation while we hail its Python competitor for it. Do Javanese have a premature optimization mindset? Indeed most Java projects never reach the point where they need to scale...

How about this approach: in absence of a more efficient alternative, calculate the ETag as a streaming digest of the content and send it as a trailer field. Iff the client sent an If-None-Match, do the calculation first over the content streamed to /dev/null. If matched, send 304. If not matched, do it again, this time streaming to the client. In an MVC architecture, we could reuse the computed model and just repeat the rendering phase. This way we trade memory consumption against additional processing overhead.

Comments

Damon Hart-Davis @ 2007-07-18 09:59:52 PDT:

... until you decide to change them all. JRoller seems to just have done so:

So I had to interface with Windows' Lsa* APIs in order to retrieve the password of my machine domain account ("$machine.acc") that allows me to authenticate as the HOST/hostname kerberos service. No problemo. Downloaded the Python Win32 extensions and had the string out in like two minutes.

Now do the same in Java. JNI is a no go. I looked at NLink and found myself annotating most parameters with @MarshalAs(PVOID) and marshalling (e.g. LsaUnicodeString) in and out of ByteBuffers myself.

Now don't get me wrong: I don't expect a native interface to implement the most wicked marshalling scheme for me. I would rather that it embraces marshalling on the Java side in an extensible fashion and only implements the absolute minimum in native code. So I came up with this for Win32:

          /**
          * Push $words words from address $stack. Invoke $function.
          * After invocation, put the result at $stack. $retType defines
          * the result type (0: void, 1: 32bit int/ptr, 2: 64bit, 3: float,
          * 4: double. If $isCdecl, clear up the stack afterwards.
          */
          public static native void invoke(
          long function,
          long stack,
          int words,
          int retType,
          boolean isCdecl
          );
        

With the very first inline assembly code of my life it was easy to implement:

          JNIEXPORT void JNICALL Java_org_mernst_maneifa_Maneifa_invoke
          (JNIEnv *env, jclass c, jlong function, jlong stack,
          jint words, jint retType, jboolean isCdecl)
          {
          int i, w;
          int *buf = (int*) stack;
          void (*f)() = (void (*))function;

          for(i=words-1; i>=0; i--) {
          w = buf[i];
          __asm push w
          }

          switch(retType) {
          case 0: ((void (_stdcall *)())f)(); break;
          case 1: buf[0] = ((int (_stdcall *)())f)(); break;
          case 2: ((long long *)buf)[0] = ((long long (_stdcall *)())f)(); break;
          case 3: ((float*)buf)[0] = ((float (_stdcall *)())f)(); break;
          case 4: ((double*)buf)[0] = ((double (_stdcall *)())f)(); break;
          }

          if(isCdecl) {
          for(i=0; i<words; i++) {
          __asm add esp, 4
          }
          }
          }
        

Easy enough. EVERYTHING ELSE CAN BE DONE IN JAVA. Well, almost. Three things I need are there but weren't public: ClassLoader#findNative finds symbols in DLLs, DirectByteBuffer#address and new DirectByteBuffer(address, cap) do the pointer fiddling.

For a different architecture this interface might need to be different (wrt registers) but that's ok. It reminds me of the approach SWT takes in contrast to AWT: instead of mapping a uniform interface to the system in tedious native code, rather use your high-level language.

Once it's settled down a little, I might describe what interfaces I use for marshalling. Now it's time for lunch. Oh, as for the name: Maneifa used to work here at CoreMedia.

Update: a MacOS/X Intel port was easy enough. Removed _stdcall and added stack padding.

Comments

Michael Nischt @ 2007-07-11 23:15:14 PDT:

Alex hates template methods and I think he's right. I prefer delegation, too, but traditionally it has a drawback: the delegate's type is obscured. In Alex' example, I have to cast to the specific ConnectionFactory type if I wanted to use one of its specific methods. That's why I've started to parameterize delegating classes with the type of their delegates like so:

public class ConnectionPool
          <CF extends ConnectionFactory>
          {
          public final
          CF
          connectionFactory;
          public ConnectionPool(CF connectionFactory, ...) { ... }
          ...
          }

          public interface ConnectionFactory { ... }
        

Now a client can have aCountingConnectionFactory, and use it into a pool without casting: pool.connectionFactory.numberOfCreatedConnections.

If you don't care about the specific type, just use aConnectionPool<?>. Actually maybe the compiler/IDE shouldn't be so picky about raw usage of (especially bounded) parameterized types and just be happy with ConnectionPool. Neal's call for type inference for constructors would help to make construction more concise, too.

You may have also noticed the use of a public final field. I don't quite see the point of hiding information that my client provided in the first place (ducking and covering).

I've added some bytecode instrumentation support to Jist using the always excellent ASM library. Agent#instrument(class, methodName, n) returns an Activity that enters and exits as the method is called/returns. Example:

This code will aggregate statistical data about Thread lifetimes. Unfortunately this code contains some problems: it uses Instrumentation#redefineClasses and thus does not interoperate well with other instrumentation agents. Since Jist only pushes aggregation data every once in a while, thread-local event data may be lost when a thread exits. I guess I should inject a forced publish at thread exit and/or add a forcePublish flag to an event.

Comments

Alan @ 2007-07-01 09:30:39 PDT:

Just pressed "send" and got greeted with "your connection to gmail has expired. please log in again". Mail lost. Me seriously grumpy. I've had this type of UI with Outlook Web Access long enough.

Comments

Lee @ 2007-07-01 19:59:29 PDT:

Bob Lee @ 2007-07-14 09:19:25 PDT:

I'm always happy to hear that someone is usingariadna. Now Neil Ferguson is asking for a Windows x64 build of the agent dll which I cannot provide. Can someone help out? Thanks in advance.

Case of a refactoring gone bad:

          public volatile
          ByteBuffermessage;

          public ByteBuffer getMessage() {
          return duplicate(message);
          }

          private ByteBuffer duplicate(ByteBuffer message) {
          return (message != null) ? message.duplicate() : null;
          }
        

IDEA 7.0M1b will happily inline #duplicate so that it reads #message twice (Bug):

          public ByteBuffer getMessage() {
          return (
          message
          != null) ?message.duplicate() : null;
          }
        

Always watch your tool!

Comments

Damon Hart-Davis @ 2007-06-18 04:11:33 PDT:

Anyone else get this? I got it on two independent computers now, one Mac, one PC. Of course I can't say for sure my computer isn't 0wned but it looks bogus to me.

Comments

Thomas Darimont @ 2007-06-13 05:32:58 PDT

Björn @ 2007-06-14 00:47:12 PDT

James Snell and Bill de hÓra point to the PATCH method to handle partial updates of Atom entries through APP. I don't see that need. PUT with the If-Match: header is just enough to do the work on the client side using optimistic concurrency control. The server side patch model:

          Client Server
          --- GET(uri) -->
          <-- ETag, entry ---
          prepare patch
          --- PATCH(uri, patch) -->
          with locked entry
            apply(patch, entry)
          


        

          Client Server
          --- GET(uri) -->
          <-- ETag, entry ---
          prepare patch
            do
            newEntry = apply(patch, entry)
          

          --- PUT(uri, newEntry, If-Match: etag) -->
          with locked resource
            compare tag ? update : fail
          
          <-- 200 OK or 412 Precondition Failed ---
          if(Precondition Failed)
          --- GET(uri) -->
          <-- ETag, entry ---
          while(Precondition Failed)


        

The second version requires the same number of roundtrips if there is no conflict and we assume that you always read an entry before patching it. Optimistic concurrency control breaks down when you have heavy concurrent updates on the same entry, something I'd argue to be rather uncommon. It does require the client to handle the patching but I don't think this is an undue burden.

We just spent a great week in Berlin at the BMCO Test Camp to test interoperability of OMA BCAST Mobile TV implementations. Results cannot be disclosed but I can say it was an amazing event. Engineers from all over the world brought handsets, encoders, scramblers, smartcards, key management components and whatnot in emulation, prototype up to product quality, together with assorted IDEs, debuggers, analyzers, flashing equipment. And for a broadcasting event, way too many cables :-) Most participants demonstrated a great spirit of cooperation and were eager to help each other, running high on adrenaline to get their systems to interoperate.

Some observations: my NIO/multicast hack has run rock-solid for days except for one VM freeze. Hot Swapping is a real winner during testing. It's sad to see people programming ad-hoc HTTP clients in C (on a server!) - of course it didn't work. In a stark contrast to Java One, almost noone brought a Mac. Some people can go for days with almost no sleep (not me).

We are very happy with our results. German engineering paid off! Plus we had a lot of fun.

I was talking to someone about the type system of Tycoon2, our research language back in school, and I mentioned it had a higher order type system with type operators. So they asked me what are type operators good for. And I couldn't say.

Today I could think of something. I often wish for a Map whose key and value types aren't fixed but instead dependent on one another. Example: an XmlTypeSystem contains a map from class objects to marshallers. Given a Class<T> I can get a Marshaller<T>. Signature:
<T> Marshaller<T> getMarshaller(Class<T> clazz).

Trying to implement this method using a hashmap I cannot get away without a compiler warning since
Map<Class<?>, Marshaller<?>> marshallerByClass
is the best I can come up with in Java.

So actually I would like a Map with a signature like this:

          interface DMap<T, KeyOperator extends <T>Object, ValueOperator extends <T>Object> {
          <K extends T> ValueOperator<K> get(KeyOperator<K> key);
          }

          // or rather
          interface DMap<T,
          KeyOperator extends <? super T>Object,
          ValueOperator extends <? super T>Object>


        

To be read as such: A DMap is parameterized by a base type T and two type operators that map any type below T to a subtype of Object. The get method is parameterized by a type K below T and maps between the application of the first type op to the application of the second. This way we can assign a meaningful type to our marshaller map:

          DMap<Object, :T=>Class<T>, :T=>Marshaller<T>> marshallerByClass;

          // explicit type arguments for demonstration purposes only
          marshallerByClass.<String>get(String.class) => Marshaller<String>
          marshallerByClass.<Feed>get(Feed.class) => Marshaller<Feed>
        

So this is what type operators can be good for. I do not think they have a broad application though and I do NOT propose we do anything like this to Java.

I've finally added some crude Response-O-Matic backed comment forms to my blog. Even though they're moderated I hope this lowers the entry barrier for you. Keep them rolling in!

Here's a first patch against b13 that survives simple tests. A number of problems remain:

• It only cascades method invocations with explicit receiver expressions. Javac does not explicitly compute the receiver at typecheck time for implicit this or outer this targets and so does not have their types ready.
• super.m() has the type of the superclass, not of this.

          --- comp/Attr.java.orig.txt 2007-05-26 13:55:53.000000000 +0200
            +++ comp/Attr.java 2007-05-26 14:15:51.000000000 +0200
          
          

          --- comp/TransTypes.java.orig.txt 2007-05-26 13:56:46.000000000 +0200
            +++ comp/TransTypes.java 2007-05-26 14:15:51.000000000 +0200
          
          

          --- jvm/Gen.java.orig.txt 2007-05-26 14:00:07.000000000 +0200
            +++ jvm/Gen.java 2007-05-26 14:16:38.000000000 +0200
          
          
        

I've hinted at this before - a discussion with my colleague Stefan Aust brought the topic back up: I'm proposing to add cascading for non-static method invocations of type void to the Java language.

Informal Discussion

I propose to make invocations of void methods usable as expressions. The type of a method invocation o.m(args) where m resolves to a void method would not be void but instead the type of o. The result of the method invocation could either be returned, be assigned to a variable, be used as a method argument, or be the target of another method invocation. Cascaded method invocations of void methods, especially of property setters would be possible:

final JFrame jFrame = new JFrame()
          .setBounds(100, 100, 100, 100)
          .setVisible(true);
        

Implementation: the change can be implemented solely by changing the way javac compiles method invocations. This is advantageous because no old code needs to be recompiled: after computing the receiver, it is simply duplicated on the stack. Either it is used as the result value or it is discarded as in JLS 14.8 "Expression Statements".

Required Specification Changes

JLS 15.12.2.6 Method Result and Throws Types: the type of a method invocation expression needs adjustment. The different forms of method invocation need to be discussed - either the type of the receiver expression, this or outer this.

JLS 15.12.4.1 Compute Target Reference (If Necessary): append "if the method returns void and there is a target reference, the target reference is retained and will become the result value".

There seems to be no wording about the result value in 15.12.4.5 "Create Frame, Synchronize, Transfer Control".

Required Compiler Changes

I don't have the code handy (just browsing) and it looks like two small changes to Gen#visitApply (Gen.java) and to MemberItem#invoke (Items.java) should be enough. Update: I forgot the necessary change to the type checker: that should be TransTypes#visitApply (TransTypes.java).

Conclusion

So far, a void method invocation can only be used as an expression statement, so the semantics of existing valid code remain unchanged. Setter invocation orgies can now be made a little nicer.

If I find time I'll try my first KSL hack. What do you think?

Comments

Rémi Forax @ May 23, 2007 8:19 PM:

Anonymous @ 2007-05-31 09:57:01 PDT

Peter Kehl @ 2007-06-18 03:00:24 PDT:

Ever so often I'm utterly confused over a design choice. Two alternative designs flipping back and forth in my mind with their respective pros and cons and I loathe wasting time over them. Other people are much more pragmatic. Examples in no particular order:

Embedding vs Embedded

Be a webapp or embed Jetty? Is the primary purpose of your app to speak HTTP or does it just happen to?

Synchronization vs Active Object

Thinking of it I couldn't really name you a reason to submit tasks to an object instead of having the relevant method synchronized - you have the same set of challenges and actually extra context switches. Nonetheless pooled-thread-per-object looks attractive and simple.

Mutable Object vs Replacement

Instead of changing an object under synchronization I like setting up and dropping in a replacement instead which can often be done through a volatile write. Of course that means the parent must be mutable and thus the question repeats at a different level.

Remote Service vs Multiply Installed Jar

Redundancy is dangerous. A domain rule should not be implemented twice - but does that mean that only one component in my distributed system may "physically" contain it? Or is it "ok" to have the same jar in many places? Can I promise to update it everywhere? Versioning of algorithms may help.

Multithreaded Service vs Decicated Objects

For those how aren't afraid of garbage collection anymore: how do you choose? service.service(parameters) vs instance.service()? Oh, more confusion: Spring scopes make it easy to inject a proxy representing a "current" entity into a singleton. So service could have a field representing the "current context". Ugh.

instance.destroy() vs factory.destroy(instance)

More general: object.doIt() vs service.doItTo(object)

NIH vs dependency hell

Is byteArrayToHexString worth a dependency? What if it uses a different logging framework?

I could go on forever... Are there other examples you're getting grey hairs about? Many of these have been discussed before under various names. Obviously, the pattern books don't have an answer either. They just describe the alternatives more eloquently. I guess the truth is: you just have to choose and it helps to be consistent throughout one piece of software. Maybe you know better afterwards.

Microsoft announcesDLR, the Dynamic Language Runtime. More details to come so stay tuned on Jim's blog. If I'm not mistaken it's a pure user-space implementation right now that tries to standardize functionality required for implementations of dynamic language interpreters. Once those interfaces stabilize Microsoft could go ahead and implement optimizations below in future CLR versions.

A crucial one of these optimizations, namely VM support for dynamic method invocations, was postulated by Gilad Bracha inJSR 292. Bears the question, what ever happened to this JSR? Can we expect to hear any more in this direction?

Some time it's always gonna be the first time, and this year I'm going to have my JavaOne initiation. So I built my session schedule and I'm hoping to turn some of my digital encounters into real ones. If you want to meet up, too, or have any tips for the best experience and be it "bring your own sandwich" I would be more than glad. Thanks and see you there!

Blood pressure once again at 180. Just who wants to punish me...

Exhibit A

Exhibit B

Exhibit C (fixed in Java 6)

Epilogue

 T mute({=>T throws Exception} block) {
  try {
    return block.invoke();
  } catch(RuntimeException e) {
    throw e;
  } catch(Exception e) {
    throw new RuntimeException(e);
  }
}
        ]]>

My 2cents towardsmocked annotations: when designing a library, always design a proper model in plain old classes. Make this model a public API and your library a runtime that interprets model instances. Use annotations only as a shorthand, as metadata from which a model instance can be derived. But leave the door open for alternative, programmatic access.

For example, an experimental XML binding API I've played with exposes things like the following:

: binding of a complex type to java objects of type V
JavaProperty: getting/setting values of type C into an object of type P
XmlComplexTypeBinding: binding of instances of complex type C into parent instances of type P
...
        ]]>

Apart from the programmatic aspect, I find that this model is the most precise way to document how the library works. (JAXB does have a model but it's hidden away as implementation detail). My XML binder will never be as complete or stable as JAXB or do XML mapping any "better" but it lays its cards open about how exactly it bridges between XML and Java.

Of course, this all applies just as well to other forms of configuration but we already knew that ...

This one might not sell as good.

Scrolling and paging: both well accepted and useful forms of visiting an amount of data bigger than your screen. What drives me nuts is that they are often employed in the same application. Click-scroll-click-scroll until I'm steaming. Microsoft Outlook Web Access, Google Mail, Google Search, my Xing contact list are all guilty of that. Letting me configure how many items I want per page is a poor replacement for what I really want: show as many items as fit, stupid. Second worst crime, by the way: changing the position of the "next" button from page to page.

Musée national Fernand Léger, Biot, Musée Picasso, Antibes, Musée Matisse, Nice. At least we got some sun.

I tried to find a better fix for Bug ID: 6436458 that would eliminate synchronization altogether. Basically it boils down to the problem of serializing transient final fields. In this case some fields of the Pattern class hold the compilation information of the regex that we don't want serialized but rather reconstructed on deserialization. But we can't assign them in #readObject since they're final. And we want them final so that Pattern isinitialization safe. Sounds like a Catch-22.

The solution is #readResolve. We can deserialize an intermediate Pattern instance that holds the pattern string and the flags - the transients being null - and then resolve it to a compiled instance using Pattern#compile. #readResolve is not recursive, so we won't end up in an infinite loop.

Mission accomplished: initialization safety, slim serialized form and no synchronization altogether. Patch.

• it would only run on Solaris
• I had to jump through JNI hoops
• there was only one probe
• I only had strings
• D is not exactly good for building abstractions. I found myself repeating a lot of ...-entry { self->x[y]=... } boilerplate.

So I'm trying a new approach: Jist, Java InSTrumentation. It is heavily DTrace inspired but completely implemented in Java, as a simple 55k no-dependency jar. With Jist, you can define low overhead probes in your code that can be dynamically enabled at runtime. As with DTrace, probes are merely the source of information - you define separately how you want to aggregate the data and correlate probes that were written by independent authors and just happen to run in the same code path. Probes and aggregation functions are thoroughly typed.

In comparison to DTrace, what is Jist not ? It only captures what happens in the JVM, it does not come with all-purpose providers like syscall, it is not easily invoked from the outside on an arbitrary Java process (agent attachment notwithstanding) and there is no garantueed safety from misbehaving aggregations.

Defining and Firing Probes

 Request = new Activity("Request");

  public void handle(String request) {
    Request.enter("request");
    try {
      ...
    } finally {
      Request.exit();
    }
  }
}

class ConnectionPool {
  public static final Event ConnectionOpened = new Event("ConnectionOpened");

  {
    ...
    ConnectionOpened.fire(dataSource);
  }
}
        ]]>

When an activity starts, a Context record is allocated and pushed onto the thread-local stack. As of now, there is now way to disable this, but I have the feeling that this cost is negligable in most cases - otherwise I'll employ a small thread-local cache. Events on the other hand are disabled by default. Every time an event fires it checks for enabledness through a volatile - this should be ok for most cases. As with logging, in case the event argument is expensive to compute, you can check beforehand: if(ConnectionOpened.isEnabled()) ... .

Simple Aggregation

 aggregation = Aggregation.of(Count.ofEvents, ConnectionPool.ConnectionOpened);
aggregation.enable();
while (true) {
  Thread.sleep(1000);
  System.out.println(aggregation);
}
        ]]>

On #enable, the aggregation will attach itself as a listener on the Event. When the event fires, it is routed to the aggregation which will increment a thread-local counter. Only sometimes will the counter be propagated to the global counter. In that codepath we only have one volatile-get (read listeners), two invoke-interface, a thread-local get and a counter increment. Every once in a while do we push the counter onto a ConcurrentLinkedQueue. On my MacBook (two threads repeatedly firing events, 1.8Ghz Core2Duo, -server) that amounts to:

40 million events per second amounts to 100 cycles per event, a number that stays stable at 20 threads, too. That's pretty good.

Correlation

Now, incrementing counters is not especially interesting and can be done more easily. It gets more interesting to correlate different, independent probes. For example, we would like to know the number of connection openings per request uri . For that, we can employ a Mapping aggregation function:

> aggregation =
  Aggregation.of(Mapping.of(Server.Request, Count.ofEvents), ConnectionPool.ConnectionOpened);

number of events by Request (updated each ConnectionOpened) = {/uri2=2285635, /uri1=4571279}
number of events by Request (updated each ConnectionOpened) = {/uri2=1833648, /uri1=3667297}
number of events by Request (updated each ConnectionOpened) = {/uri2=1842779, /uri1=3685558}
number of events by Request (updated each ConnectionOpened) = {/uri2=1974581, /uri1=3949161}
        ]]>

This shows the real potential: we can see that requests to /uri1 open twice as many connections as those to /uri2. That's something no profiler and no DTrace will tell you. Another teaser (numbers highly dubious):

> aggregation =
  Aggregation.of(Mapping.of(Server.Request, Statistics.of(Duration.of(Server.Request))), Server.Request.Exit);

statistics for duration in NANOSECONDS of Request by Request (updated each exit from Request) =
  {/uri2={|sample|=1615081, sum=7.43407E8, min=0, max=64524000, avg=460.29084609378725, stddev=96321.15405584917},
   /uri1={|sample|=1615084, sum=9.26188E8, min=0, max=75908000, avg=573.4611945880214, stddev=123748.53849281174}}
statistics for duration in NANOSECONDS of Request by Request (updated each exit from Request) =
  {/uri2={|sample|=1602764, sum=9.54039E8, min=0, max=100171000, avg=595.246087384044, stddev=145823.88277769994},
   /uri1={|sample|=1602763, sum=8.40672E8, min=0, max=77095000, avg=524.5142294899496, stddev=118100.06216280891}}
...
      ]]>

Outlook

One of the perks of DTrace is that you can attach to a process and run D scripts that were not compiled into that process. I'm still pondering how to do that. A scripting solution for the definition of aggregations might be interesting, one that is defined on dynamically loaded agents or something JMX-based. Right now, you'll have to bake in aggregations and export them somehow, i.e. though JMX. Some simple class-redefinition to inject probes into foreign code would be nice, too.

To some extent I hope that aggregation of independent events will reduce the time you spend sorting log records together (".. ok, here it starts .. now lets look for the same thread, ok down here, ... go up one page again").

Get it

Now that you're mouthwatering enough, go download Jist here. Or get the most recent version: hg clone static-http://mernst.org/jist .

Germany's facing fierce resistance about moving the retirement age up to 67. Sun thinks a little more progressively in this context :-)

Anyone? http://www.sun.com/corp_emp/search.cgi?req=548725&p=

The real power of DTrace lies in its ability to correlate independently provided data in ways unforeseen by the developer. Too often have I been asked things like "nice cache eviction statistics but how can I see which algorithm, query, user is responsible for this?". D is the SQL of instrumentation: it enables ad-hoc queries over unprepared data.

As of today, DTracing Java is cool as long as you're doing relatively general performance analysis of the software - questions about "which method?", "which class?", "which monitor?" can be answered - to open the ultimate insight into application space ("which query?", "which dataset?", "which url?") we need to work a little harder.

I'm interested in two kind of probes: the ones that establish a thread-local context for a possibly lengthy period, i.e. "starting request to /url", "starting transform foo.xsl", "importing x" and the corresponding exit in order to correlate these with events such as "evicting y" or "creating temp-file z".

A simple DTrace provider for Java applications

So I want to do something like this (obviously not in one class):

 REQUEST = new dtrace.DTraceContext("request");
  static final dtrace.DTraceContext TEMPLATE = new dtrace.DTraceContext("template");
  static final dtrace.DTraceContext EL = new dtrace.DTraceContext("el");

  public static void main(String[] args) throws Exception {
    while(true) {
      REQUEST.push("/index.html");
        TEMPLATE.push("outer.jsp");
          // do some real work here
          TEMPLATE.push("inner.jsp");
            EL.push("${something.wild}");
            EL.pop("${something.wild}");
          TEMPLATE.pop();
          // do some real work here
        TEMPLATE.pop();
      REQUEST.pop();
      Thread.sleep(1000);
    }
  }
	]]>

The DTraceContext class looks as follows. It does some stack management and ultimately fires entry and exit events through JNI:

 {
    private static native void init();
    private static native void fireEntry(String name, Object top, Object previous);
    private static native void fireReturn(String name, Object top, Object previous);

    public final String name;
    private final ThreadLocal> value = new ThreadLocal>() {
      protected ArrayList initialValue() {
	return new ArrayList(5);
      }
    };

    public DTraceContext(String name) {
      this.name = name;
    }

    public T get() {
      ArrayList ts = value.get();
      return ts.isEmpty() ? null : ts.get(ts.size()-1);
    }

    public void push(T value) {
      T previous = get();
      this.value.get().add(value);
      fireEntry(name, value, previous);
    }

    public void pop() {
      ArrayList values = this.value.get();
      T value = values.remove(values.size() - 1);
      fireReturn(name, value, get());
    }

    static {
      System.loadLibrary("dtracecontext");
      init();
    }
  }

  JNI code:

  // error checking yadda yadda
  JNIEXPORT void JNICALL Java_dtrace_DTraceContext_fireEntry
    (JNIEnv *env, jclass class, jstring name, jobject top, jobject previous)
  {
    if(DTRACECONTEXT_ENTRY_ENABLED()) {
      const jbyte *namestr = (name==NULL) ? NULL : (*env)->GetStringUTFChars(env, name, NULL);

      jobject tops = (top==NULL) ? NULL : (*env)->CallObjectMethod(env, top, tostring);
      const jbyte *topstr = (tops==NULL) ? NULL : (*env)->GetStringUTFChars(env, tops, NULL);

      jobject previouss = (previous==NULL) ? NULL : (*env)->CallObjectMethod(env, previous, tostring);
      const jbyte *previousstr = (previouss==NULL) ? NULL : (*env)->GetStringUTFChars(env, previouss, NULL);

      DTRACECONTEXT_ENTRY(namestr, topstr, previousstr);

      if(previousstr != NULL) (*env)->ReleaseStringUTFChars(env, previouss, previousstr);
      if(previouss != NULL) (*env)->DeleteLocalRef(env, previouss);

      if(topstr != NULL) (*env)->ReleaseStringUTFChars(env, tops, topstr);
      if(tops != NULL) (*env)->DeleteLocalRef(env, tops);

      if(namestr != NULL) (*env)->ReleaseStringUTFChars(env, name, namestr);
    }
  }

  // ... same for pop
  ]]>

Note how the native methods take Objects but the probes carry strings: I do a callback to #toString and extract the UTF-8 sequences only after checking whether the probe is enabled. The overhead of the JNI calls for disabled probes seems good if not used in tight loops (like 22 ns per call on my machine) - if it turns out to be a problem I'll need to hoist the test into the Java code. The DTRACECONTEXT_ENTRY is a macro generated by dtrace from my provider description - see "statically defined tracing" - basically we compile a call to a dummy external C function into our code, and postprocess it with dtrace that will patch this code sequence in order to disable/enable the probe. The provider:

          provider dtracecontext {
          // args (contextname, context entered, previously active context)
          probe ENTRY(char *, char *, char *);
          // args (contextname, context left, context returned to)
          probe RETURN(char *, char *, char *);
          };
        

A note to the naming: I tried to name the probes "entry" and "return" first - I thought they would be recognized by the "-F" (indent flow) option of dtrace but unfortunately that is not so; and return is a dtrace keyword. So the first thing that came to my mind was capitalization - I will most probably change that.

You will have noticed that this provider is very static - there's only two probes for the whole Java process and the actual type comes as a string argument. All application probes are disabled and enabled together which will have a bigger performance impact - maybe I can come up with some dynamic compilation/library generation scheme later.

I haven't collected really good examples from real software yet - that's why there were no actual dtrace scripts in action but I hope you could see the possibilities. I think the potential is huge. The demise of logging? That would be too good to be true...

"HTML allowed" actually means "Comply with those angle brackets or I will swallow all your paragraphs. You have been warned.".

The Solaris 10 kernel supports a fine-grained security model, based on "least privilege" . For example, in order to run a server on port 80 you don't need to be root. The PRIV_NET_PRIVADDR privilege is sufficient.

The same applies to coniguration of the IPsec security associations and policy entries. Unfortunately, the respective command line tools 'ipseckey' and 'ipsecconf' do check for uid 0 before they even try to talk to the kernel.

Luckily, w/ Open Solaris being open source I could quickly fix that. Commented out the checks, did the ppriv thing, et voila, a normal user with SYS_NET_CONFIG can now do what I want. Neat!

Update: I've learnt that I shouldn't use privileges for that directly (will become messy over time) but rather a profile that defines the right execution attributes such as the "Network Security" profile. Yet that profile doesn't work right now for the outlined reasons (bug filed). Workaround: use your own profile and exec_attr with uid=0. No need to recompile the tools - just assign that profile to your user.

WARNING: this is an experiment and may well wreak havoc on your blog-reading experience.

I'm cheap and lazy and thus I'm not willing to pay for PHP hosting nor would I want to administer a blog system. Yet I want to host my blog on my own domain. I've been using Thingamablog until now but their editor has serious limitations, especially when working with pre-formatted code fragments. And I can only edit the blog from the one machine where the database is.

I have thus changed my blog to one major source file in the Atom format. I'm typing this entry directly in atom format into IDEA's XML editor - I have a nice live template to insert the minimum scaffolding. When I finish, this source file is then only post-processed (w/ JAXB) to derive "updated", "link", "id" and "a" elements (a process that I could still do by hand if that little piece of Java code is not handy). I have left all old ids intact and hope that they won't be re-syndicated, even if the feed format changes from RSS to Atom (this file will still be called rss.xml).

No HTML is generated, the feed is directly styled with CSS, not even XSL. A nice learning experience and the capabilities of CSS continue to impress me. As a potential downside, I'm now including all my posts in one file. Certainly more than before but not too huge if all participants make use of the relevant HTTP mechanisms.

I've tried to be as standards compliant as possible but your mileage with various readers may vary:

• Firefox renders this feed best. I had to include a lengthy comment header in order to actually enable the stylesheet.
• IE 7 fairs worst. It won't use the stylesheet (someone? DOCTYPE?) but is fooled by the comment. So you'll only see the text() nodes.
• (Fixed) Both Omea Reader and Google Reader have issues with "bleeding" anchor tags (<a../>). Obviously they're embedding the XHTML pretty directly into quirks HTML without reprocessing it.
• RSS Bandit and BottomFeeder look fine.
• Syndication to PlanetJDK has stopped :-(

The CSS element selectors don't seem to care about namespaces. I don't know whether this will continue to work with CSS3 Namespace Module .

The sidebar on the right is implemented as a dedicated feed entry that is styled differently.

So much from the low-end side of blog software - please let me know what problems you're having and whether they prohibit you from reading this journal any longer. Enhancements to the stylesheet are welcome, too. You know where you can find it.

If you're bored of the "property" word, please skip.

If not, you may note that some of the REST principles apply to properties:

We expect to read a property without visibly affecting the object. Reading properties is supposed to be a safe operation . We also expect setting the same value for a second time to have no tangible effect. Setting properties is supposed to be idempotent . The values we see from properties may or may not be the actual state of an object, they are merely a representation .

In a distributed, concurrent environment, atomicity also is of concern. I feel progressively unsure about using an array of setter invocations for reconfiguration of a service, e.g. through JMX. The REST way of PUTting an entire representation of the -desired- resource's state looks a lot safer to me. It gives the object a chance to implement atomicity. Recently, we built a service that is reconfigurable through PUTting an entire configuration document, and this approach feels really solid compared to fine grained remoted JMX-based management. The admin UI operates not on the object but on a representation of its state and then submits it to take effect.

What is my point? I believe that applying REST principles to OO programming lends itself to separate the "life" objects with their logic from "dumb" state representations that can be manipulated or bound to. We might not want to bind UI elements directly to property methods. We might rather go and implement representations through simple structs w/ fields that are also nicely transported, persisted, versioned, ... Putting that state into side-effects would be of no concern at this stage. Useful linguistic support would be compile-time checked field references so we can bind some UI element to a field of the state representation.

There's a ton of open questions - no question about that. And this may be a pile of bull. But thinking about how representations (external ones, too), state, binding, ... all fit together is definetely a larger topic than just syntactic sugar around field declarations.

Surface syntax aside, implementation-wise a property is all object-like and I'm surprised we're still talking generating methods according to a naming convention. A property *has* setter and getter, it can be referenced, especially in order to bind it to a UI component, you can attach listeners, ...

ValueModel anyone?

          public final RWProperty<String> name = new Slot<String>();

          mernst.name.get();
          mernst.name.set("matthias");
          mernst.name.attachListener(...);
          label.bind(mernst.name);
        

Stefan agreed and received comments that matters just ain't so.

I admit that my experience with XSS is not extensive, so I went reading, too. I'll try and formulate the understanding I've reached now (main source being Jeremiah Grossman ):

The fundamental threat of XSS is that a script from site A (attacker) has the browser talk to site V (victim) (using V's cookies), having V reveal some sensitive data, and consequently transfers this data to A. That's why cross-site XHR is prohibited. In contrast to XHR, SCRIPT tags cannot read the response and thus not make any malicious use of it. Instead, the SCRIPT response is evaluated as executable Javascript code by the browser. If V never responds with the data in an executable format that data is safe from A. Thus SCRIPT tags are allowed to load scripts from a different site.

Now it has become popular to return data in JSON because it is so accessible from Javascript code. When this data is evaluated by a SCRIPT it gets dangerous since a clever script can intercept the inocouusly looking array- and object constructors and intercept the data - or easier, instruct the server to pass the data to a callback function, which seems to be popular, too.

Conclusion: only data in executable format, returned on a GET authenticated through a cookie, is in danger of being hijacked through a SCRIPT tag. But that's more a fault of the server than the browser security model.

On the JSON v XML debate : what good is a same-domain requirement for XmlHttpRequest if you can do a GET on any host via a SCRIPT element? It's like saying "applets can't contact arbitrary hosts through sockets but URLConnections are ok".

On Closures and LINQ : LINQ introduces the notion of expressions. Restricting the contents of the curly braces to expressions might seem like an interesting approach. It avoids transfer-of-control-problems. But the most interesting part: LINQ allows you to reflect over an expression structure and gives you some interesting options to optimize the query.

Thank you, Axel . What can I say?

When I helped in the development of the Sather compiler, I analyzed and fixed bugs purely by studying the code - my machine was way too small to bootstrap the compiler.

I met my wife at Marcello's in the Castro district in San Francisco. With funky shoes and hair she thought I was gay and thus safe to talk to - it turned out I wasn't gay but european.

The first linux I installed came by mail-order and was a stack of 3.5'' wrapped in packing tape. I wanted it because of xeyes.

Eberhard , Alan and Grabowski .

The common wisdom: the two of them don't go together. Some official Java version in 2008 might have support, some open source derivative earlier. For those of us that need to do multicast today, here's the version that works for me with 5.0u9, Win XP, IPV4. CAVEAT: ugliness reigns and this will most certainly break with newer or non-Sun versions.

In short: we wrap the DatagramChannel's fd in a manually created PlainDatagramSocketImpl, join the multicast group and let go of the socket again:

          // UGLY UGLY HACK: multicast support for NIO
          // create a temporary instanceof PlainDatagramSocket, set its fd and configure it
          Constructor<? extends DatagramSocketImpl> c =
          (Constructor<? extends DatagramSocketImpl>)
          Class.forName("java.net.PlainDatagramSocketImpl").getDeclaredConstructor();

          c.setAccessible(true);
          DatagramSocketImpl socketImpl = c.newInstance();

          Field channelFd = Class.forName("sun.nio.ch.DatagramChannelImpl").getDeclaredField("fd");
          channelFd.setAccessible(true);

          Field socketFd = DatagramSocketImpl.class.getDeclaredField("fd");
          socketFd.setAccessible(true);
          socketFd.set(socketImpl, channelFd.get(channel));

          try {
          Method m = DatagramSocketImpl.class.getDeclaredMethod("joinGroup", SocketAddress.class,
          NetworkInterface.class);
          m.setAccessible(true);
          m.invoke(socketImpl, socketAddress, networkInterface);
          } finally {
          // important, otherwise the fake socket's finalizer will nuke the fd
          socketFd.set(socketImpl, null);
          }
        

Enjoy or let me know why this is a bad idea.

We recently celebrated crossing changelist #100000! A great moment to reminisce. We introduced Perforce in 2000 and haven't regretted it once. Fast, reliable, powerful, good support.

I will now reveal my very personal electro-codeo-gram to you:

(p4 changes -u mernst | cut -d ' ' -f 4 | cut -d / -f 1-2 | uniq -c).

I've decided not to read too much into it.

Inspired by James Snell : Fidji is deliberately Java-incompatible :-)

There's a few things that would be fun to hack into Java, now that we could actually share it with the world (Hats off to Sun!). I would

• get rid of checked exceptions. They're such a pain. As far as I understand they're purely a compile-time construct, could be easily fixed in Javac and have nothing to do with either security nor VM integrity.
• fill the void. An invocation expression of a method with return type void could be treated as if returning the receiver, enabling cascaded sends. Bean b = new Bean().setA(a).setB(b);
• add type inference for locals: todo := problems.size(); next := problems.removeFirst();
• add reliable closing of iterators in the for-each loop. for(line : File.lines("log.txt")) soutv<TAB>line (try this today without losing a file handle!). I've actually already done this one: patch
• Resource literals . Akin to X.class, a mechanism for compile-time checked references to resources.

If I needn't go to work now I could probably think of many more. The big BUT: these are all futile if no IDE recognizes them ("Das Rote ist gefährlicher Zahnbelag"). I hear NetBeans is javac-based. How much would it take?

What would you do?

I don't understand all the whining about type erasure. Au contraire, an elaborate compile-time type system without burdening the runtime is most elegant and I wish Java would rather move further into that direction instead of getting reified generics .

Al Gore's film " An Inconvenient Truth " has arrived in Germany. It is a good movie and it deserves that you go, make your friends see it with you and finally start doing something about your energy balance.

The argument I made when dissing Kirill's SVG to class compilation was the overhead of parsing the class files, resolution and verification as compared to simply parsing an XML representation into an application-level tree representation. I came around to actually measure the difference.

Note that I'm only talking about the speed of loading, not of drawing. The test I performed was: what is the fastest representation to load ? In order to get I/O out of the way, I prepared the source representation in memory.

The contestants:

• class file: 1000 byte arrays with different classes, each with a method doing 1000 method calls, are loaded into a new classloader. An instance is created for each class to make sure the class is fully initialized.
• serialization: 1000 serialized object graphs, consisting of 1000 small objects each, are deserialized
• Binding with XML: 1000 XML documents, consisting of 1000 elements each, are parsed and bound to an object graph using JAXB.
• Binding with Fast Infoset: 1000 fast infoset documents, consisting of 1000 elements each, are bound to an object graph using JAXB.
• DOM building: 1000 fast infoset documents, consisting of 1000 elements each, are transformed into a DOM tree

So how do you think the contestants fared?

Quite a surprise for me: slowest was the DOM building, followed by XML parsing&binding. Next came FI to Java binding, then serialization. And the winner is: classloading! It is faster to load a compiled representation of method calls into the VM than bind the equivalent Infoset representation to heap objects. So except for handcrafting a binary format, a jar with compiled .svg icons might indeed be the best option.

The numbers after some warmup:

• class loading: 359ms
• serialization: 500ms
• fi->JAXB: 703ms
• XML->JAXB: 1516ms
• fi->DOM: 1594ms

The test was performed using Java 6b101, server VM w/ 256MB initial and max heap. The usual caveats apply, especially the data is synthetic and simplistic. If you want to take a look at the test code, it's here .

I have to update my results again. Now with a more realistic scenario, the actual bytecode for an actual icon vs the equivalent fast infoset document, DOM and serialization are fastest, about 30% faster than classloading and binding which come out head to head. Binding spends a considerable amount parsing the coordinate and other attributes into doubles. With a more efficient representation it would be ahead of bytecode. Just using String, it is almost twice as fast. At a millisecond per icon, the difference doesn't matter that much anyway.