Under the hood

Edit: Changed the blog template to something that doesn’t cut off my comment lines. Also, removed extra line breaks. Wtf, Blogger? If I hand-edit the HTML, I expect zero generated tags!

Today was a relatively good day. I’m currently on a Java course at the Open University, and while there’s relatively little new they’re teaching me, it has proven to be a good source of inspiration to learn new things myself. One of those things was how to convert java bytecode to a readable representation, and to an admittedly small extent, read the converted bytecode.

(By “convert” I mean “run javap -c -private ClassName > ClassName.bytecode”, not exactly rocket science.)

That was a few days ago. The reason I did that was to prove my hunch about how many operations an array size lookup would be (given the array was an instance variable) compared to a static final integer variable — this was a case where the array was initialized to a length specified by said variable. Without actually having factual knowledge, I conjectured that a static final integer could be inlined by the compiler, whereas the array size lookup would be at least two operations. Turns out that I was right on both counts (edit: at least in this instance; I’m not experienced enough to know of any proven reason why optimizing the array size lookup would be impossible). This java code:

public class BytecodeTest {
   private static final int FOO = 42;
   private char[] arr = new char[FOO];

   public int getLength() {
       return arr.length;

   public int getFinal() {
       return FOO;

turns into this bytecode (using the Sun Java 6 compiler):

Compiled from "BytecodeTest.java"
public class BytecodeTest extends java.lang.Object{
private static final int FOO;

private char[] arr;
public BytecodeTest();
  0:   aload_0
  1:   invokespecial   #1; //Method java/lang/Object."<init>":()V
  4:   aload_0
  5:   bipush  42
  7:   newarray char
  9:   putfield    #2; //Field arr:[C
  12:  return

public int getLength();
  0:   aload_0
  1:   getfield    #2; //Field arr:[C
  4:   arraylength
  5:   ireturn

public int getFinal();
  0:   bipush  42 
  2:   ireturn


That makes it three instructions, not two. For my own benefit (since typing this out will ensure I don’t forget it), here’s a not-quite-accurate explanation of what goes on there:

  // push local variable "0" (the "this" pointer) into stack
  0:   aload_0
  // call getfield, which pops (?) "this" off the stack and pushes the field onto the stack
  // (the #2; bit is the location of the field, not entirely sure how it should be interpreted
  // note to self: find out!)
  1:   getfield    #2; //Field arr:[C
  // call arraylength which pops the array off the stack and pushes the length
  4:   arraylength
  // return integer from stack
  5:   ireturn

Compare and contrast with getFinal which doesn’t do any lookups, just says “push the following byte to the stack as an integer” and then “return integer from stack”.

Now, before anyone accuses me of premature optimization, that’s not what this was about. This was mainly about fact-checking and a desire to understand what goes on underneath. 🙂

Any day I get to prove myself right is a good day. But any day I get to learn something like this and deepen my understanding about a language I use is even better.

Culture shock

Have I ever mentioned that I hate checked exceptions? I mean, it’s not bad when a method declares that it throws one exception type, but I’ve run across methods that throw no less than four different types of exceptions, with no common superclass between them (except Execption, no pun intended).

I’m in uncharted territory here, seeing as I’m not a hotshot Java coder, so I don’t know if this is like the worst possible thing to do. However, there are cases when there really is nothing I want to do when an exception occurs, but propagating it isn’t really a good idea either, so I’d like to swallow the exceptions and possibly log them. However, swallowing four different types looks more than a bit silly, so I ended up doing this:

} catch (Exception e) {
    if(e instanceof RuntimeException)
        throw e; // My inner C# programmer screams bloody murder at me here...

    // log error, or don't

… because I don’t want four empty catch blocks, but I really don’t want to swallow runtime exceptions either.

So. Am I off my rocker?

Also, a bit nervous…

I’ve been taking university comp sci courses on the side since September. So far I’ve only completed the Intro to Comp Sci that was mostly essay writing and familiarizing oneself with the different aspects of CS. Tomorrow, however, is my first exam. The course is Intro to Databases, and while I’m fairly proficient at getting database work done, I’m nowhere near certain I’ll get a good grade from the exam.

First of all, the course was a web course, so no conversation, no teaching and very little commitment from me. Second, the terminology doesn’t quite map with what I’ve grown used to — in part because it’s in Finnish and in part because I tend to think in SQL, not relational algebra.

I’m fairly certain I’ll pass, but I’d really like to get a good grade, because it affects my chances to apply to the university. I’ve got four more courses, and if my marks are high enough, I just might get in.

Oh well, better not fret, I guess I’ll just go through the old exams again once or twice for practice and then see where I end up. 🙂

JSON update, MonoRail musings

Well, the path expression bits I grafted on to Json.NET are now relatively functional, although in terms of code quality, not much to write home about. I added a rule that says, basically, if the first call is “include” then the mode is “exclude by default” and vice versa. My MonoRail controllers currently use the serializer like so:


where “list” is an enumerable of something that holds a reference to a Foo. The resulting JSON looks something like this:

[{Foo: {Id: 1}}, {Foo: {Id: 2}}]

“Json” is a property that holds a “JsonRenderer” which is just a helper that holds a reference to both the serializer and the controller, so we can append the Render() call there.

All in all I’m pretty pleased with this, because it gives me fine-grained control over serialization, and I can nix the dependency between my domain model and Json.NET (which existed purely because I used JsonIgnoreAttribute on a couple of domain classes).

(As for any aspirations to release my changes — I haven’t had the opportunity to ask for a permission, and to be honest, the overall quality of the extension is “good enough for me” but I’d rather not show it to anyone else just yet. 🙂 Once I’m done with the important bits — that is, the application itself — I might try wrapping them up in a form that leaves the original serializer untouched.)

After managing to simplify the serialization, I noticed that a big part of my controller code looks like this:

public void SomeMethod(long fooId)
 Foo foo = FooDAO.Get(fooId);
 // ...

so I figured I should probably do something about that, too. Fortunately, writing a custom data binder for MonoRail is fairly painless.

Now, the same code would look like this:

public void SomeMethod([DAODataBind] Foo foo)

The binder by default looks for an id parameter, the name is determined by the parameter name so “foo” is looked up based on “fooId”. The attribute has a second form, [DAODataBind(“fooBarId”)] which uses the parameter “fooBarId” instead.

The implementation is a bit of Reflection voodoo. First, we use the supplied ParameterInfo to find out the type of the parameter. If it’s not one of our domain model classes, tough luck, but I have a nice exception for you. Next, we dig up the appropriate DAO from our DAOFactory which comes with a handy GetDAO(Type t) method. Finally we invoke the Get method of the DAO with the id parameter, and return the retrieved object.

Surprisingly enough, that worked very nearly on the first try — I made some assumptions about Type.GetMethod(), mostly the BindingFlags that I’d have to use, but once that was sorted out it worked like a champ.

Overall I’m impressed of how easy MonoRail has been to use and extend. At first, the lack of documentation threw me off, but then I just took the plunge and read the source, after which things were a breeze. 🙂

The things you find yourself considering from time to time…

As seen on #svn, when someone asked if it would be possible to use in-browser JavaScript to commit to a Subversion repository:

< Rytmis> Well if you can get the browser to speak WebDAV, it might
 technically be possible.
< Rytmis> You're going to have to do a *lot* of stuff by hand, 
 though :)
< Rytmis> See how the svn client library talks to a http/https 
 repository and duplicate that as XHRs :P
< Rytmis> Writing a svn client in in-browser javascript strikes me 
 as mildly insane, but who am I to judge :)

The best part of course being that I actually went through the steps of implementing just that in my head.

Some progress

Well, I succeeded in the FlexJSON port, although the resulting code is still a bit.. um. Shall we say, suboptimal. However, I did get the most relevant bit, which is the idea behind the path expressions.

Ok, I guess I could have come up with the same idea myself, but what the hey, I enjoyed the work. 🙂 I’m now working on implementing the same idea from scratch with a few modifications. The include/exclude patterns in FlexJSON aren’t quite as powerful as I’d like them to be, so my implementation will have a way to determine the most specific of two patterns, the basic rules being:

  • A longer pattern will always win over a shorter one
  • In patterns of equal length, the one that contains the first wildcard loses
  • and if all else fails, Include always trumps Exclude

This should leave me with a way to control serialization in a relatively succinct way, and lucky me, I’ve even got a bunch of real-life test scenarios to try them out on.

Another idea I’m toying with is transformers, also stolen from FlexJSON. In addition to path-based transforming, I thought I could include attribute- or type-based transforming and filtering — depends a lot on which turns out to be the most useful.

The way I’m thinking is I could have an attribute on a class or a property that is in no way tied to the JSON serializer, but I could still use it to control serialization by way of the transformer. The transformer would be a delegate, which comes with some nice implications, such as being able to easily refer to the current user of the web app (since the delegate can be an instance method on the controller) without making the serializer aware of the fact that there even is a web app. Crazy? Genius? You decide.

Oh, I’m also at this point determined to patch this stuff on top of Json.NET. 🙂

I guess it’s time to try and quit thinking about work and concentrate on having a beer, though. 🙂

Porting from Java to C#

While on the lookout for a JSON serializer that would allow me to include or exclude parts on a per-serialization basis instead of just per-class basis (which is what Json.NET gives me), I ran into FlexJSON. Unfortunately, it’s for Java, and I’m working in C#. What’s a programmer to do?

Well duh, port it, of course! What better way to learn the ins and outs of the library? 🙂

I hacked on the sources for about three hours today. I started out by changing all the file extensions from .java to .cs, then opening the things in VS.Net and pretty much mechanically changing the incompatible bits, accessors to properties and whatnot. Surprisingly little effort there — the Java and .NET reflection classes are very much alike.

I haven’t had the time to understand all of the code properly yet, for example I still need to figure out what the deal is with the chained set and iterator thing. I suspect it has to do with avoiding reference loops in object graphs.

I’m not sure whether or not this will ever be finished, but I’m going to give it some more time tomorrow. I’m hoping to get it to a point where I can start running the test cases and see what breaks.

If I should be so lucky as to actually get this thing done, I think I’ll try to wrangle a permission to publish the port. What I’d really like to see, though, is this feature in Json.NET since that’s what I’m currently using and from what I gather, it also ships with MonoRail these days. Tomorrow I’ll probably have a better idea of what it would take to add the feature. No promises though.

Edit: Json.NET does support the feature I’m looking for after a fashion — but I gather that I’d have to walk the object graph myself. So basically grafting on something similar to the FlexJSON path expressions might just do the trick.

A new beginning

It’s been a while since I abandoned my previous blog. I did it for a couple of reasons. First, I’d really like to focus more on software development and my experiences in it than the rest of my life, and second, keeping WordPress up to date was really getting on my nerves. I do like to express myself in writing, though, so I thought I’d give it another shot. I have a couple of topics on my mind already. 🙂

Till later.

1 12 13 14