2006-10-26

Climate Matters

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.

Posted by Matthias at 24:19.17. Comment: blog@mernst.org

2006-10-24

SVG.class!

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.

Posted by Matthias at 22:36.57. Comment: blog@mernst.org
Edited on: 2006-10-25 23:59.01

2006-10-23

Ficken ist so ein schönes Wort

Schade, dass man es in den USA nicht schreiben darf.

Posted by Matthias at 22:14.24. Comment: blog@mernst.org

SVG.class?

I have to say I cringed when I saw Kirill's post because I'm allergic to code generation (unless it's necessary). Graphics are data, not program (see - I neither have a LISP nor Postscript background) - it makes about as much sense as compiling JSPs. In Suns VM, classes end up in a scarce resource called permspace, and I don't expect classloading to be any cheaper than reading a "data" file. My take: instead of generating Java code, rather serialize the render tree and interpret it.

Yet this allergy is highly opion-laden and calls for a comparison. How expensive is loading a class in comparison to parsing an XML file and binding it to a renderer tree representation? What's the memory footprint? Will a "compiled" icon enjoy any benefit from dynamic compilation? Ultimately, would the world want another file format that corresponds 1-1 to the Java 2D API or isn't that just another form of bytecode?

In the end, any means to avoid a heap of Batik jars are justified...

Posted by Matthias at 9:45.00. Comment: blog@mernst.org
Edited on: 2006-10-23 9:47.30

2006-10-17

Gilad Bracha is leaving Sun

No one has died but I feel like whatever I'll write will sound like that; please bear with my limited language. I cannot claim that I know Gilad too well. I had the pleasure to meet him seven years ago when I had the audacity to invite myself into his office to talk about our language work at Hamburg University and received the honour of my own StrongTalk tour and a lecture about mixins. I wonder how often Gilad must have cursed that the most advanced virtual machine technology aquired by Sun was used to drive such an ugly language as Java. But it's probably not overrated to say that he's been the pillar for its stability and well-definedness, reason amongst others for the commercial success of Java. Enough said! Hope there's greater adventures waiting for you. Good luck!

Posted by Matthias at 1:26.25. Comment: blog@mernst.org

2006-10-16

Neal Gafter's example is bogus

Neal makes it look like only closures could hide away the strutting of a forEachConcurrently abstraction. I'm all for closures but this is a flawed argument. What he should have compared is his closure-using code:

  List<Principal> result = new ArrayList<Principal>();
  for eachConcurrently(EventResponse r : getResponses(), threadPool) {
    if (r.mayAttend()) {
      Principal attendee = r.getAttendee();
      synchronized (result) {
        result.add(attendee);
      }
    }
  }
  return result;

to this:

  final List<Principal> result = new ArrayList<Principal>();
  forEachConcurrently(getResponses(), threadPool, new Runnable1<EventResponse,RemoteException>() {
    public void call(EventResponse r) throws RemoteException {
      if (r.mayAttend()) {
        Principal attendee = r.getAttendee();
        synchronized (result) {
          result.add(attendee);
        }
      }
    }
  });
  return result;

The supposed library implementation (exception handling and such according to Google):

  public interface Runnable1<Arg1, Ex extends Throwable> {
    public void run(Arg1 arg1) throws Ex;
  }
  
  public static <E> void forEachConcurrently(Collection<? extends E> collection, Executor threadPool, final Runnable1<E,? extends Throwable> fun) {
    CompletionService<Void> ecs =
      new ExecutorCompletionService<Void>(threadPool);

    for (final E e : collection) {
      ecs.submit(new Callable<Void>() {
        public Void call() {
          try {
            fun.run(e);
          } catch (Throwable ex) {
            LOGGER.log(Level.SEVERE, "Uncaught Exception", ex);
          }
          return null;
        }
      });
    }
    // wait for the tasks to complete
    for (final E e : collection) {
      try {
        /*discard*/ ecs.take().get();
      } catch (InterruptedException ex) {
        throw new AssertionError(ex); // shouldn't happen
      } catch (ExecutionException ex) {
        LOGGER.log(Level.SEVERE, "Uncaught Exception", ex);
      }
    }
  }
Posted by Matthias at 24:07.03. Comment: blog@mernst.org
Edited on: 2006-10-16 8:59.40

2006-10-15

First Sprouts

After me bitching about the perceived opacity of JDK 7 development, JSR 277 has released an early draft. A pretty long and detailed document (well, not a quality in itself, EJB was, too), too much to have studied it in detail yet. My first impressions:

  • there are examples and scenarios for a number of use cases
  • J2SE is expected to become modular itself - whatever the implications are for standards. Au revoir -Xbootclasspath?
  • modules and their containing repositories are fully reflected at runtime.
  • the specification predicts that JDC 4670071 bug will finally need fixing
  • the syntax for module definitions is weird. It resembles annotations but not quite. Then, in a different section, using XML for URL repository descriptions seems ok for the EG.

So far, matters related to language specification have been in conservative, if not too rigid hands, so I expect this spec will be consistent. It's hard to judge how much easier or more complicated developers' lifes will become. According to section 2.18 the authors "anticipate many higher level tools and frameworks will build upon the module system to provide greater convenience and ease of use.". Let's hope so.

So when you send your comments to the JSR comment address and hope for reply, why don't you post them on your blog or up the java.net forums as well?

Posted by Matthias at 23:05.15. Comment: blog@mernst.org

2006-10-03

JDK development from the outside

I'm sure there's a lot of people like me that would like to know where things are moving in Java 7. However, it's hard to find out. Danny points to a list of JSRs slated for inclusion in Java 7. I'm disappointed that not one of the expert groups chose a process as open as JSR166. I'm certainly not expected to join all these as an "expert" (what is that anyway?), just because I'm interested. In the average case, it will take a few months until an EG spits out a zip with JavaDoc and - if I'm lucky - a PDF with a little rationale. But a lot will be missing - what was tried but didn't work out, alternatives considered, ... And the impression I get (the wrong it may be): it's too late in the process to change something fundamental anyway.

I feel this form of development isn't very compatible with a soon-to-be open-source implementation. It may almost provoke forks.

My request: open up your mailing list archives and your CVSs, let us follow your train of thoughts, and you'll receive so much more valuable feedback and contributions. If you want them, that is.

Posted by Matthias at 16:56.08. Comment: blog@mernst.org

A long term suspicion

An observation: almost all WYSIWIG text editors suck at some point. We've been beaten up repeatedly for our CMS's text editor but in comparison we're actually doing pretty well. The editor I'm typing this text with is Swing-based and gets confused all the time. James Robertson turned off his WYSIWIG comment editor pretty quickly again. And today, after noticing the BLL competing closure proposal (someone with a U want to join that group?), I tried writely. After pasting some dead-simple HTML (just p's and text) BACKSPACE wouldn't join two paragraphs but introduce some br weiredness. A second BACKSPACE would do the job. Not intuitive.

Which leads me back to a long-term suspicion of mine: the base abstraction is wrong. A long time ago computer science decided that documents shall be trees. Things started to go down after that...

Posted by Matthias at 12:29.59. Comment: blog@mernst.org