The Open Type System vs. Code Gen

Cedric Beust took a look at Gosu’s Open Type System a few weeks back here:

Overall it was a very fair, if brief, look at Gosu’s Open Type System. There was one point at the end, however, that I want to examine:

While elegant, Gosu’s open type system is basically just saving you from a code generation phase.

This is not entirely true, but it is hard to see why at first blush.

What *is* true is that most problems that are addressed with code generation in Java today can be more elegantly addressed in Gosu by using the Open Type System. And, due to the fundamental laziness of the Gosu compilation model, it is possible to model problems with much larger potential type spaces (so long as only a reasonable subset of that type space needs to be materialized at compilation time) since it is not necessary to generate all types up front. So, yes, the Open Type System is a sort of elegant code generation mechanism.

However, it is more than that.

To understand this, consider the Protocols type loader that I wrote a while back:

Protocols are an entirely foreign concept to Gosu. They are a way to achieve “static” duck typing: you define a Protocol in a .proto file, which looks an awful lot like an interface. However, unlike Java or Gosu interfaces, a value’s type does not need to implement a Protocol for the value to be assigned to a variable that has a Protocol type. Rather, the value’s type must conform to the Protocol: for every function defined in the Protocol, there must be an invocable function on the value’s type that can be invoked safely.

An example will help clarify.

Given this procotol:

package test

protocol Protocol1 {
  function doIt()

Any value with a static type that has a method doIt() can be assigned to it:

class Class1 {
  function doIt() { print( "In Class1" ) }

class Class2 {
  function doIt() { print( "In Class2" ) }

var p : test.Protocol1 = new Class1()

p = new Class2()

// p = new ArrayList() -- Won't compile, since ArrayList doesn't have a doIt() method... 
//                        Unless you add one with an enhancement... :)

So, even though Class1 and Class2 are entirely unrelated, we are able to assign them both to a variable with a protocol type to which they both conform. We can’t assign an ArrayList to that variable, however, since an ArrayList does not have a doIt() function (although you could make ArrayList conform to the protocol by using an enhancement to add a doIt() method if you wanted to. But why would you do something crazy like that?)

I was able to implement Protocols in Gosu precisely because the Open Type System gave me more tools than simple code generation: I was actually able to implement the unique assignability semantics of my Protocol types using the IType#isAssignableFrom() method.

This is a level of control and power that mere code generation does not have.


The Dynamic Code Evolution VM

Every single java developer out there needs to know about the Dynamic Code Evolution VM (DCEVM) being turned out by Thomas Würthinger and his team:

This is truly an amazing piece of technology. It enables full hot swap in a JVM, allowing you to change method signatures, add and delete methods and so on, with impunity. You will rarely need to restart your JVM once you start using it.

And it is available…. FOR FREE.

Guidewire has sponsored the development of the DCEVM ever since we first learned about it at the 2009 JVM Language Summit. It has been a huge productivity boon for us and is a crucial bit of technology in the Guidewire (and Gosu) stack.

More people need to know about the DCEVM.

Download it, stop bouncing your JVM, and tell a friend.

Gosu IntelliJ Plugin

In an effort to further IDE support for Gosu, we’ve just open sourced the IntelliJ plugin.

If you are interested, you can clone the repository here:

Running the plugin involves:

  • Cloning the repository
  • Setting up the submodules (git submodule init then git submodule update)
  • Opening up the GosuPlugin.ipr project.

You’ll need to set up an IntelliJ SDK as well. Internally, we’ve been using the latest open source version. You can set this up as follows:

  • Check out from git://
  • build the editor using ant build
  • unzip the version for your platform in out/artifacts.

After you’ve done that, you can set up a new plugin SDK by pointing it at the directory in question.

Note that we will not be doing merges for the plugin in git, but if you’d like to submit a patch we can apply it internally and migrate it back out to the main repository.