Tag Archives: Programming

Lazy Deserialization in Java

Posted by on September 29th, 2011 1 comment

While coding away on our master’s project, my team and I faced a problem. In our setting, users provide Java byte code to a client application which instruments it and passes the resulting JAR archive to remote servers via RMI. The servers execute this code in separate processes and feed it inputs values fetched from the client, again via RMI. Now, this can be a problem as users may provide their own implementations for those input values. Both client and separately started processes have, of course, access to these implementations, but servers may not.

The solution intended by Sun back then is to set up a code repository servers can access and download the necessary code from. We considered this overkill given that the server does not even care about the value1: after RMI deserializes the input, we immediately serialize it again and pass it directly to its child process. Dynamically loading all classes from the archive at hand felt messy for the same reasons.

So we came up with this pattern which I call lazy deserialization:

import org.apache.commons.lang.SerializationUtils;

class Value<T extends Serializable> implements Serializable {
  private final byte[] data;
  private transient T value;

  Value(T value) {
    this.value = value;
    this.data = SerializationUtils.serialize(value);
  }

  T get() {
    if ( this.value == null ) {
      this.value = (T)SerializationUtils.deserialize(this.data);
    }

    return this.value;
  }
}

As long as servers does not access the wrapped value, everything is fine; as far as they are concerned, they are passing around dressed-up arrays of bytes. In our case, we added several primitive—and therefore trivially serializable—members of the wrapped value to this class in order to enable the server to be able to report back certain things.

I think this pattern can be of use in any situation that involves passing around serialized objects only some nodes are interested in. After all, you might want to avoid deserializing even if you have access to all necessary class files; after all, (de)serializing can take up quite some time you might want to see better spent.

  1. Especially so as we have a many-to-many relation between clients and servers, that means many repositories and many loaded classes you do not need. ↩

B. Liskov on the Power of Abstraction

Posted by on May 30th, 2011 Comments Off

Barbara Liskov giving her Turing lecture

Last week, Barbara Liskov visited Kaiserslautern and gave her talk On the Power of Abstraction. I had known her from the substitution principle named after her1 and taught to every computer scientist and programmer, but she is far more distinguished than that: Barbara Liskov is an ACM Fellow, holds the ACM Turing Award and the IEEE John von Neumann Medal and a couple of other awards, telltale of her influence on the field.

The talk she gave is actually her Turing lecture, obligatory for Turing awardees. The room was so packed that quite some people had to remain standing, and it was worthwhile to have come. You can watch the lecture—in another instance—in full here. For me as a CS novice, the lecture is a small time travel machine to the seventies: Barbara talks about the history of how abstract datatypes and related concepts came to be. As someone who grew up with languages like Java, it is hard to imagine a world where all programming there is is literally done on assembler level. So, lots of the material presented should feel trivial to the modern mind, but Barbara manages to instill the spirit of the time into her listeners. After her talk, you know why she got awards for things you take for granted today.

Since the lecture itself can be watched online, I just want to share my favorite quotes and anecdotes I wrote down during the talk; I hope I am not misquoting.

[Barbara] did not apply at MIT because she did not want to be a nerd.

I have no idea how I got that idea. [...] It was ready to be discovered.

You never need optimal performance, you need good-enough performance. [...] Programmers are far too hung up with performance.

There were no GOTOs because I believed Dijkstra.

It’s really just common sense.

Why did she get this award? Everybody knows this anyway!

Especially the last quote demonstrates, if unintentionally, the impact of Liskov’s and others’ work of that time. If something you conceive is considered common sense 30 years later, you really had a brilliant idea.

  1. She did not name it, of course. Apparently, she received an email in the 90′s by somebody asking her wether he got “her” principle right, surprising her She had not known that the principle had borne her name for years in the community. ↩

Coding Scala with Geany and SBT

Posted by on March 14th, 2011 1 comment

When I started programming in Scala I was naturally looking for a suitable IDE. Due to former experience and preference, I disregarded Eclipse and tried Netbeans with its Scala plugin but could not get it running properly. I had more luck with IntelliJ IDEA, that is it worked. But it is performing sluggishly and has a lot of bugs. In particular, many compiler errors are not found by IDEA, and some things it marks as errors are none. Scala’s complex type system is not all well implemented, so syntax completion is no help, either. That the Scala compiler itself runs at turtle speed was merely the last drop in my barrel of discomfort. As it was, working productively was impossible. Therefore, I decided to switch to a regular editor and simple-build-tool, something I saw mentioned everywhere people asked for good Scala IDEs. Read more »

Sick of Java? Try Scala!

Posted by on February 14th, 2011 Comments Off

You like Java for its tools and safety, but hate its verbosity? You like strong guarantees and pattern matching in functional programming, but feel constricted by its chains? You like Ruby, Python et al. for their flexibility and conciseness, but hate their unpredictability and tardiness? Rejoice, because salvation might be at hand. Late last year, I came across the relatively new programming language Scala and became immediately infatuated with it. The official website describes Scala like this:

Scala is a general purpose programming language designed to express common programming patterns in a concise, elegant, and type-safe way. It smoothly integrates features of object-oriented and functional languages, enabling Java and other programmers to be more productive. Code sizes are typically reduced by a factor of two to three when compared to an equivalent Java application.

That is, Scala has the full modelling power of object orientation. There is literally nothing you can do in Java and can not in Scala. In fact, Scala arguable does a number of things better than Java: everything is an object (even primitives, functions, classes), generics are more consistent and powerful and multiple inheritance is perfectly possible. Additionally, many features you come to like in functional programming are present in Scala, if not as completely as you might wish. Type inference, pattern matching and lazy members are only examples. Also, working with immutable objects (not to say values) is inherently ingrained in both language and library. Type inference together with a number of compiler trickyness can give you the illusion of dynamic programming while retaining type safety at all times.

In short, Scala enables you to model object oriented, code (almost) as concisely as in dynamic languages and (almost) as safe as in functional languages. Read more »

Vererbung mit JavaScript

Posted by on May 7th, 2010 Comments Off

In einer Vorlesung wurde das Konzept der Vererbung grundlegend erläutert und in einer Übungsaufgabe illustriert, wie das in prototypbasierten Sprachen aussehen kann. Wir sollten meine alte Freundin JavaScript mit dem Interpreter von Mozilla benutzen. Subtyping und Vererbung ist für JavaScript wohl nur ansatzweise und unbehände gelöst; zahlreiche Quellen im Web führten mich zu Lösungen, die als Prototyp eines Subtyps ein Object des Supertyps setzten. Das sah in etwa so aus:

function Person(name) {
  var name = name;
  this.print = function() {
    print(name);
  }
}
Person.prototype = new Person("A");

function Student(name, id) {
  Person.prototype.constructor(name);
  var id = id;
  this.print = function() {
    Person.prototype.print();
    print(id);
  }
}
Student.prototype = new Person("B");

Die Notation mit den Prototypen ist ziemlich unhandlich — und auch nicht korrekt. Read more »