A blog about software – researching it, developing it, and contemplating its future.

Archive for July 2007

What’s Gilad Up To?

leave a comment »

The legendary “computational theologist” Gilad Bracha is on the verge of another divine revelation.

Gilad, as many know, was for years one of the gurus of the Java language design, delicately dancing on the infinitely thin edge between semantic integrity and linguistic flexibility. Until, that is, he got tired of the need to continually choose between poor alternatives and quit Sun last year. Since then his new blog, the cheerily named Room 101 (one of my must-reads), has been putting forth all kinds of evidence about his new venture.

It’s clear that it’s a startup, and that they’re working on a new language. But what kind of language? And for what purpose?

Start with Gilad’s previously-mentioned-here paper on Objects As Software Services. This paper discusses the possibilities of downloadable software objects — with behavior and state — that can provide offline functionality, transparent synchronization to the server when reconnected, and dynamic upgrade. He goes into some detail on the language properties these objects would benefit from — specifically, reflective tracking of field accesses (via a mirror-based reflective mechanism), and a typing semantics that is flexible enough to allow code upgrade without entering classloader hell.

In more recent posts on Room 101, we’ve seen other pronouncements of what good languages look like. For one, his excellent recent post on why constructors are considered harmful, which is because they are far too tightly coupled to the specific class in which they’re declared. Most of the time you want object creation to be a matter of policy, but constructors are pure mechanism — all you get is the instance of the class you’re specifying, which is totally inadequate in most cases (the majority of cases where you want an object that fulfills some interface, but you want the framework to pick the appropriate class, since it knows more about the classes involved than you do). The canonical solution here is factory methods, but Gilad considers most of the factory method idioms in, e.g., Java to have many of the same problems — you can’t override a static factory class, you can’t extend or replace it. He suggests instead a mechanism for encapsulating object-creation methods within a parameterized class definition, allowing full virtualization of object creation without the overly tight coupling to the class itself. So Gilad’s seeking a language that has the structural purity of Smalltalk, with some of the warts removed.

There’s also his post on why tuples are good, which is relatively straightforward as Gilad’s posts go. Again, tuples give you a single language mechanism that covers a variety of important uses. We’re seeing a real focus here on The Right Thing. It must be a blast for Gilad to be working with a clean sheet of paper after a decade in the immensely constrained Java space.

Finally, there’s his post on why message passing is good. This is not going to be any surprise to anyone who’s enamored of message passing languages, such as Erlang and (at least at the distributed level) E. Pure message passing gives you a degree of isolation and security that more tightly coupled languages can’t match. It also has a very real performance cost — we don’t yet know how to build an optimizer that can make a message-passing loop be as efficient as an inlined C++ function-call loop — but Gilad’s main concerns, as we’ve seen, are linguistic flexibility and expressiveness for use cases including distributed programming and dynamically upgradeable software objects, not achieving the maximum possible performance for typical modern architectures (which has always been one of Bjarne’s key goals).

Also, Gilad recruited Peter Ahé away from Sun, and Peter’s spilling some beans of his own.

So putting all this together, what do we have? Gilad is working on a new language that:

  • is a pure message-passing language (a la Self)
  • refines Smalltalk’s metaclass structure to allow parameterized factories and basic constructors to be implemented as virtualizable instance methods
  • supports a flexible enough typing structure to enable dynamic upgrade of the code of stateful objects
  • has a mirror-based reflective mechanism suitable to allow, among other things, logging of all object field accesses for subsequent orthogonal synchronization
  • has tuples 🙂

It’s going to be very interesting to play with this language of his once it’s done. And it even looks like he’s hiring, so things may be pretty close to public visibility! If nothing else, his new venture is going to provide a lot of food for thought. New languages always have a hard time achieving critical mass, but with Gilad’s sense of history and design skills behind it, this new one has a much better than average chance.

Written by robjellinghaus

2007/07/27 at 03:35

Offlining Soon (Temporarily)

leave a comment »

My wife is within days of delivering our second child. We’ve already got a two-and-a-half year old girl, Sophie, who’s a little bundle of shining happiness — seriously, this kid is one of the cheeriest tots you’re likely to meet, and my wife and I are totally smitten with her. Well, now her baby brother Matthew is on the way, and it’s happening Real Soon Now.

So at some point in the not-very-distant-at-all future, I’m going to be going offline in a big way, possibly for up to a month. Do not fret. I shall return in force, once we’ve gotten the hang of juggling TWO little ones in the house, and once we’ve made darn sure that Sophie feels OK with everything.

Written by robjellinghaus

2007/07/27 at 03:15

Posted in Uncategorized

Classloader Hell

leave a comment »

I really like Java. It’s definitely my favorite language, and the one I’ve written the most code in, by far. Its balance of static typing, great libraries, OS independence, “no surprises” philosophy, and unsurpassed tool support mean that I’m more productive in Java than in any other language I’ve tried.

But that’s not to say it’s perfect. There can never be an objectively perfect language, since there are too many kinds of software that need to be written, and all languages have expressive tradeoffs that affect their usefulness for those purposes. But even on its own merits, Java’s got some major issues.

The biggest issue is the infamously named “classloader hell”. All reasonably experienced Java programmers know it bitterly well: the difficulties of running code within application servers or other kinds of complex deployment situations, where there are multiple sub-projects all loading code at runtime and attempting to operate with each other. (Briefly, for those who don’t know, Java code is loaded by objects named “classloaders”; classloaders define a name space of loaded classes, and a single class, if loaded by multiple classloaders, is considered to be two distinct — and non-interoperable — classes.)

This is one area where Java’s original standard was written in haste. The model of classloaders delegating to each other, the way that classes are considered to be different if loaded from different classloaders, and the many problems this can cause — all are fundamental problems that manifest in a variety of confusing and confounding ways.

The problem gets much worse when you get into code interoperating between multiple systems on a network, each of which may have subtly different versions of the system’s code. The entire Remote Method Invocation standard was predicated on the assumption that Java’s ability to load code over the network would enable code to travel alongside the network messages that reference that code. It feels to me like a case of “wow, Java lets code run anywhere! Just think of what that lets you do for a networking protocol!” The problem was that the versioning issues weren’t well understood, and that has caused bitter pain in actual usage.

It’s not like Sun isn’t aware of the issues. This technical report covers the basics: it’s possible to set up RMI scenarios where perfectly innocent messaging patterns result in systems being unable to send messages to each other at all. Worse, the runtime behavior is difficult to analyze or understand.

These problems aren’t merely abstract. Another Sun paper discusses an entire advanced networking system that was well into development, based on Jini and RMI, when these problems reared their ugly heads and fundamentally destabilized the entire project. The ultimate reason for abandoning the project was its business infeasibility, but it’s clear that Sun’s own technologies — as currently implemented — were deeply broken.

Now, security, versioning, and interoperability are notoriously hard problems, and it’s far from clear that anyone has really great solutions to them. Certainly Sun can’t be too deeply faulted for not getting it right — Java did get many other things right (including OS independence, dynamic compilation, dynamic inlining, garbage collection, and much more). So I don’t mean to pick too deeply on Java; I just mean to highlight some of the biggest outstanding issues with the language.

There’s work going on to fix at least some of this: for example, the Java module JSR, #277, is intended to bring at least some rigor to the entire classloading system. The .NET framework has a better grasp of module loading issues, though I’m not aware of how .NET messaging compares to RMI or whether it’s exposed to any of the same issues. The Fortress language is taking a much more rigorous approach to component versioning and component assembly as well. But most of these seem dedicated to fixing the module loading problems in a single environment; I don’t know of much work on addressing the security and versioning issues associated with network messaging (though JSR 277 does address some of the naming issues that break RMI and Jini).

Still, that’s the great thing about software: there’s always more that needs fixing, and more great things to build! Expect many more posts on this general topic….

Written by robjellinghaus

2007/07/13 at 04:57

Every Two Weeks

leave a comment »

[Crossposted to my other blog.]

Blogging’s still new to me. The only thing I really know about it so far is that while there’s an infinity of posts to make, there’s only finite time to make them. And that time is in high demand, mainly from family, but also from all the other great projects that aren’t blog-writing.

So I have to set some kind of deadline for myself. And that is: two weeks. I must, and will, post in both my blogs at least every two weeks.

I’m setting that deadline because I notice my reaction when going to other blogs: if I see the latest post is a month or more old, it’s a sign that the person’s really way too busy to blog, and that the blog’s an afterthought to them. It’s also a sign that who knows when the next post might be?

But if the last post was a week or so ago, that’s still timely. Two weeks is pushing it, but based on my experience so far, it’s the most I can commit myself to.

So, that’s my promise to you: I’ll update both my blogs every two weeks at most. Feel free to flame me if I don’t!

…Except for the next month, because we’re expecting my wife to go into labor sometime in the next three weeks, which means all bets are off 🙂

Written by robjellinghaus

2007/07/13 at 04:46

Posted in blogging

GWT, JSF, declarative markup, and lunch with Gavin

leave a comment »

Just had an interesting lunch with Gavin King (original author of Hibernate and Seam), and came up with a somewhat crazy idea that needs more eyeballs on it.


The GWT toolset lacks a way to do declarative markup. The only way to compose GWT components is through Java code. Joel Webber of the GWT team said at Google Developer Day 2007 that one of his personal ambitions for GWT is to build a declarative markup system.

The Seam toolchain lacks a way to build custom JSF widgets easily. Building a custom JSF widget with plain Javascript is extremely painful. The GWTJSF integration library goes partway towards addressing this, but doesn’t currently support building composable trees of GWT-based widgets.

What if we brought the two together? What if we could create a JSF-based and Facelets-based markup system that enabled composability of independently developed JSF widgets implemented in GWT? This could both leverage an existing declarative markup system (Facelets) for GWT’s purposes, and deliver a much better toolset for creating Seam applications with richer UI functionality.

That’s the basic idea. If you Get It, then please skip to the DETAILS section. Otherwise, read on.


The first chunk of lunch was walking through my Seam/GWT example, clarifying what it does and how it does it. Basically, as the page explains, it takes GWT modules and encapsulates them in JSF components. This allows GWT modules to exist within the context of a larger JSF / Seam application, leveraging other JSF page components and directly communicating with Seam components through GWT RPC.

The main use for this, it seemed to us, is taking existing GWT modules and wrapping them as JSF components, to enable their use in a larger JSF application. This was one of the original use cases that motivated the Exadel guys (Sergey Smirnov and Alex Smirnov) to create their GWTJSF integration library.

Where do we take it from here, though? Originally it seemed to us that if all you need is GWT, then this JSF integration isn’t of much use to you. Michael Neale has already landed — in the Seam 2.0 beta — a GWT integration that doesn’t require JSF at all, but just lets your GWT app communicate with Seam components. (He hasn’t, evidently, integrated my RPC refactoring in GWT 1.4, so it doesn’t yet support native GWT-style RPC, but that’ll be easy to do now that GWT 1.4rc1 is out.)

So, is the only use case for GWTJSF really for people who want to take existing GWT components and build them into JSF apps? Well, Gavin saw the code for the GWT module in my demo, and his feeling was, wow, this is a much better programming model than writing custom JSF components in Javascript. So what would it take to make GWTJSF better at creating reusable JSF components?

There are two main things that the current GWTJSF library lacks. One of them is support for Seam conversation propagation. This is important if you want to have GWT components that can participate in a Seam web application which uses both GWT-based AND non-GWT-based components. You want the GWT components to be able to carry the conversation state in RPCs, so they can participate in the Seam server-side conversation state management. (Yes, I know it is totally against the GWT religion to even mention the words “server-side session state.” This isn’t the main point, so don’t get hung up on that.)

But that’s actually not the most interesting possible extension.


The current Seam blogging example is basically a tree view of blog posts. Each tree node can be expanded to show the full text of a blog post, with an inline edit button that lets you edit the post’s text right there in the tree.

Here’s the GWT/JSF markup for instantiating this tree-view-blog-editing component:

<!– This is a JSF component encapsulating a GWT module. –>
<bloglist:component id=”main2″>
  <!– This widget routes GWT RPC requests to the Seam component named “gwtBlog”. –>
  <gwt:gwtListener serviceBean=”#{gwtBlog}”/>

This creates a JSF component wrapping a GWT module. The GWT module exposes an interface which is implemented by the server-side Seam component named “gwtBlog”. So the GWT module uses a single interface to communicate with the server.

The GWT service interface is this:

public interface BlogService extends RemoteService {
  public Blog getDtoBlog ();
  public List getDtoBlogEntryList ();
  public String getFormattedHTML (String wikiText);
  public void updateBody (String id, String newBody);

This interface conflates operations on the whole list of posts (getDtoBlogEntryList) with operations on individual posts (getFormattedHTML, updateBody).

Overall, this widget is great and all, but it really consists of two orthogonal pieces: a tree view component, and an individual-post-editing component. They’re bound together in the current GWT code. This widget is monolithic; all it does is make a tree of blog posts. It can’t be repurposed by tweaking the JSF page.

When showing this to Gavin, his feeling was that it was not nearly generic enough. The typical Seam way of doing this would be something like (edited for brevity):

<!– Generic tree view, using a post-edit widget for each node. –>
<ice:tree id=”tree” value=”#{tree.model}” var=”item”>
    <ice:panelgroup style=”display: inline;”>
      <ice:commandlink value=”#{ item.userObject.text}”>

This builds a JSF component tree that declaratively nests multiple widgets, using Seam expression language ( e.g. “#{tree.model}”, “#{item}”) to specify where the components get their data.

Now, here’s the rub. What if you could write JSF / Facelets markup that instantiated a tree of GWT widgets this way?

Something like this:

<gwt:tree id=”tree” value=”#{blogEntries}” var=”item”>
  <gwt:blogpostedit value=”#{item.blogPost}”>

What you’d be doing here is writing a JSF page that creates a component tree that is purely instantiated on the client. The only rendering would happen on the client via GWT. The GWT components would (WAVING HANDS MADLY) have some protocol for nesting themselves, and would have some data-binding style coupling to the server components from which they pull data. The RPC could be GWT-style RPC via service interfaces generic to each specific component.

This would essentially turn the JSF UI component tree into a structure that can be either rendered purely on the server (original-style JSF controls), or rendered partially on the server and refreshed using AJAX (the Ajax4JSF / RichFaces style of user interface), OR rendered entirely on the client (GWT-style widgets). This would also enable declarative construction of GWT-based interfaces, using the exact same syntax and UI component tree as used for other JSF interfaces.

This is good for Seam, because it enables a graceful path towards Seam-based JSF apps with lots of custom UI code, without losing the compositional good qualities of Facelets. And it’s good for GWT, because it gives a declarative framework for building GWT applications, with a great story for coupling to server-side business logic.


This is not quite a half-baked idea yet. In fact I’d say it’s about 10% baked. But it’s definitely interesting, and it definitely bears more thinking about.

There are many issues with it, just a few of which are:

  • This doesn’t really let you mix arbitrary non-GWT and GWT JSF widgets; the only allowable children of GWT JSF widgets would be other GWT JSF widgets. (Unless you get really sneaky with partial rendering invoked FROM GWT, which probably isn’t worth it….)
  • I have no idea at all what Joel Webber (of GWT fame) has in mind for declarative markup, so this concept may be totally wrong for his use cases.
  • On the face of it this idea seems to imply some kind of EL (expression language) parser implemented in GWT, which is no small chunk of work.
  • Who exactly implements this is a totally open question; I still want to get back to the offline Blogger client done with GWT/Gears, which has basically nothing to do with this 😉

I don’t claim to have answers to these; this post is just a starting point.

I’m going to post in the GWT developers forum, in the Seam users forum, and in the Ajax4JSF developers forum to see what kind of reactions this idea provokes.


Written by robjellinghaus

2007/07/01 at 04:49

Posted in GWT, JSF, Seam