The Law of the Leaky Abstraction - English Version

Some time ago, looking for interesting content on the Internet, I came across the excellent article "The law of the leaky abstraction." I liked it so much that I decided to make of it subject of the first post in the Java.lang.Blog.

I recommend everyone to read the article, but briefly, it calls attention to the fact that the abstractions we create in the computer world, whose goal is usually encapsulate determined complexity, end up leaving, under some circumstances, this complexity 'leak' ie, we end up having to deal with the complexity anyway.

Thus, the author proposes the law of the leaky abstraction, set out as follows:

All non-trivial abstractions, to some degree, are leaky.

I will not go into the many abstractions we use in the computing environment. In fact, the article does that very well (Do not miss it!). I would, however, invite readers to reflect on the JEE platform’s abstractions. Are they also victims of the law of leaky abstraction?

I think so. And to illustrate, I’ll cite two examples in the JEE specification key technologies: JSF and EJB. Also, I'm sure the reader will be able to identify other leaks in the JEE platform.

Leaks and Java Server Faces (JSF)

Like most web frameworks, JSF tries to disregard the "details" pertinent to the development of such applications, such as form submission and type conversion. The framework would have us believe, for example, that you can simply associate a method or property on a managed bean (server-side) at the click of a button or value of an input interface (client side).

Although laudable, this abstraction is subject to leakage. What happens when the property in the managed bean is not a String? Some conversion is necessary. And what if this conversion fails for some reason? If the user decides to type "fg%# 4" in an input field connected to an Integer in the managed bean property? Unless the developer has instructed the framework how to notify this type of failure, the user will remain clicking on the submit button and the same page will remain being re-rendered as no method will be called on the server side at all. Realize the leak?

The developer must now infiltrate the complex JSF life cycle and understand, in this potentially new context, how the framework handles conversions and how to handle possible failures.

Leaks and Enterprise Java Beans (EJB)

Despite having gone out of vogue in recent times, one of the central issues of EJB technology is support for distributed systems. Even when running on a remote machine, EJB clients are able to call these components as if they were local. The complexity of the remote method call (RMI) is therefore abstracted by this technology.

This abstraction, however, is also subject to leakage - and in a very subtle way: parameters to methods calls on a remote EJB must be serializable. That's because these objects must travel through the network, being rebuilt on the remote machine that trully houses the EJB component. Thus, the fact that the EJB component is remote becomes apparent as the parameters to its methods are required to be serializable, featuring the leak.

Remember that this leak was more visible in the earliest versions of the specification, when an EJB client was required to deal with checked exceptions related to remote calls (RemoteException and subclasses). This aspect has been improved from version 3.0, replacing the checked exceptions with unchecked equivalents.

Consequences

Some consequences of the law of the leaky abstraction:

1. Abstractions do not help us much as we imagine. In an environment that so constantly refers to this feature, this is something important to keep in mind.
2. Paradoxically, the more layers of abstraction are created to simplify the development, the more difficult becomes the task of becoming a proficient developer. This is perhaps the most intriguing result. Will the efforts to simplify the development on the Java platform would be having the opposite effect than expected?
3. Be wary of tools that promise, as in magically, simplified development and multiply the productivity of the team (code generators, someone?). The abstractions in which these tools are based could leak and when that happens, often the cost is quite high.