Skip navigation

BlueJ is a tool for teaching OO programming in Java that is very well regarded in the CS education community. Microsoft engineers who were familiar with the BlueJ "workbench" added a similar feature to Visual Studio, didn't give credit to the BlueJ inventors, and filed a patent application. Not the way to win the hearts and minds of the education community.

What is BlueJ?

BlueJ is a tool for teaching students about objects and classes. One of its key features is a "workbench" that contains icons denoting objects. New objects can be placed on the workbench by clicking on class icons. Methods are invoked by clicking on the icons.

???

Before I used BlueJ, my CS1 students kept asking "What is the difference between an object and a class?" Now they no longer ask--they know that classes are the factories for objects, and that objects execute methods. They know it not because I told them but because they experienced it. That makes a huge difference.

This functionality was first developed in BlueJ's predecessor Blue by Dr. Michael Kölling in his 1994 Ph.D. thesis and described in various published papers.

What did Microsoft Do?

In 2005, Microsoft added an "object test bench" to Visual Studio--see Microsoft's documentation or Dr. Kölling's analysis with side-by-side comparisons.

???

Microsoft then filed a patent on this feature.

There is a question whether people inside the Visual Studio development team were aware of BlueJ. I have met many Microsofties and Visual Studio users who seem to think that Microsoft is the only source of innovation in the universe—I once had a hard time convincing someone that refactoring in the IDE was not invented by Microsoft but was present in Eclipse years before Microsoft saw the light.

But the team that markets Visual Studio to educators is keenly aware of the competitive landscape. I had many conversations at the annual ACM CS education conference with Microsoft representatives about the various products, and they were well informed and certainly knew BlueJ. They are also relentless. I am a member of the College Board's development committee for the AP Computer Science exam, and not a year goes by without a request from Microsoft to the College Board to make the exam more Microsoft-friendly. (Visual Studio doesn't handle Java 5, which is currently used for the programming questions on the exam.)

Of course, Microsoft is a large company and the fact that one group knew about BlueJ doesn't necessarily mean that the company committed fraud by filing a patent without referencing it as prior art. But Microsoft is also a fabulously wealthy company, and it would have been an easy matter for them to do more research into prior art, had they chosen to pursue this with the same relentlessness as dogging the College Board.

What Now?

Now the cat is out of the bag. It's even on Slashdot, where it immediately degenerated into the usual rant on how the patent system sucks. I know it sucks, but to me, that's not the point.

My point is this. Dr. Kölling is very nervous that Microsoft might shut down BlueJ. Unlike Microsoft, he and his university are not fabulously wealthy, and even filing a simple objection with the patent office is a hardship. Microsoft wants to play nice in the educational community. Relentless but nice. To me, nice would mean that they apologize to Dr. Kölling, belatedly give public credit to him, and withdraw the patent application. I'll update this blog once they do that.

Update:According to this blog, Microsoft is doing just that. Over the weekend, they reviewed the situation, realized they made a mistake, decided to withdraw the application, and apologized to Dr. K

Mapping Design Intent to Code

???Chapter 3 in Fowler's UML Distilled discusses class diagrams. His firstdesign concept: properties. Fowler describes the role of properties in OO design and how they are mapped to language features in Java and C#.

In Java, a public read-write property can be mapped to a getter and setter pair. The design concept

/** the name of this widget */
public property String name;

gets mapped into

/**
   Gets the name of this widget.
   @return the name of this widget
*/
public String getName()
{
   return . . .;
}

/**
   Sets the name of this widget.
   @param name the new name of this widget
*/
public void setName(String name)
{
   . . .;
}

What's wrong with it?

  • Not very DRY
  • Humans and tools need to rediscover the designer's intent

Making the mapping from design to code clear and traceable should be the job of the programming language.

After all, why do we program in Java? You can implement classes in C—just use struct, write the virtual method tables with macros, and use some discipline.

Or, to use a more recent analogy, consider the enhancedfor loop. Why do we prefer

for (String w : words)

to

for (int i = 0; i < words.size(); i++)
{
   String w = words.get(i);
   . . .
}

You could argue that the enhanced for loop is a deplorable sign of language bloat and that it is properly the job of the IDE to write the explicit loop.

Or you could argue—as the designers of this feature have—that the enhanced for loop reduces the cognitive load on the code reader because it is a more faithful translation of the programmer's intent, namely to loop through all elements.

I think the IDE argument is completely bogus. I don't care about the keystrokes. I know perfectly well how to get my IDE to type stuff. I care about reading the code later. When I read the explicit loop, I look at the indexes, the < sign, the++. When they are all just so, I say to myself “aha—I rediscovered the intent; we really want to loop through all elements”.

As you can tell, I buy into the “intent” argument. Going back to properties, when I design a class, I think of properties, not getters and setters. I want that intent reflected in the code. I don't want to piece together a dozen lines of getter/setter code, checking that all the names and parameters are just so.

Designing With Properties

The most common argument that I hear against properties is “they are bad design—just like public fields”.

There is an essential difference. Once you expose a public field, you can never change the implementation. But with a property, you can start out with a trivial implementaton andrefine it later, e.g. add error checking in the setter, or switch from field access to a computed result.

The usual trite example: Start with a trivial implementation.

/** the name of this widget */
public property String name; // compiler auto-generates trivial getter/setter

Later, refine it to

/** the name of this widget */
public property String name 
   get { return fname + " " + lname; }
   set { String[] n = value.split(" "); fname = n[0]; lname = n[1]; }

(Yes, I know the setter needs better error checking. That will be the next refinement)

(Yes, I know that the number of keystrokes isn't all that different from using a regular old getter/setter. That's unimportant. What s significant is that the programmer intent is captured by grouping the implementation features together.)

???Another commonly voiced argument is: “You should not expose all internal state through getters and setters”.

To which I say: “Amen”.

When designing a property, I ask myself whether this is indeed an intrinsic feature of the class that will always be there. Does it make sense to allow public read access? Public write access?The fewer properties, the better.

Some people argue that we shouldn't add property support to Java because clueless programmers would abuse it. But they already abuse it today, aided by the getter/setter auto-generation in the IDE. Is Eclipse a tool of the devil because it makes writing bad code so easy?

Design is hard. The class designer has the arduous task of producing a public interface that is rich enough to make the class usable and frugal enough to make it withstand change. I don't know how to simplify that task. All I ask for is that—once a capable design has been completed—the design intent is right there in the Java code, rather than making me recover it from a rubble of code.

The Rules of the Game

???

  • This is just a Gedankenexperiment. I am not seriously proposing anything for Java SE7.
  • A property is an abstract thing that has a get and set operation.
  • A "native property" is a "property done right" with new syntax. A "JavaBeans property" is what it always was.
  • I don't want to get into any syntax wars. I use an uppercase Pi (Π) to denote a property keyword (such as public Πint salary) and a lowercase pi (π) to denote property access (such as joe π salary). This "pi in the sky" syntax is absolutely certain not to get adopted. Substitute your own favorites, such as dot, arrow, or whatever.
  • For compatibility, java.beans.Introspectorincludes native properties inBeanInfo.getPropertyDescriptors.
  • Anyone who wrote tools that enumeratedget/set methods with a mechanism other thanjava.beans.Introspector should go and pound sand.
  • No bleating about "you are destroying encapsulation" and "why don't you just make your fields public". The point of a property is to encapsulate read/write operations that are deemed essential features of a class and whose implementation can evolve over time.

Mangled Methods

The way I understand Jacob's argument is that the get/set naming convention deserves to be laid to rest as a historical {accident|mistake|good idea at the time}. Thus, a native property must be manipulated with the property operator. If you define

public class Employee
{    public Π double salary;    . . . }

then you must use

double x = joe π salary;

or

joe π salary += 1000;

You cannot use

double x = joe.getSalary();

or

joe.setSalary(joe.getSalary() + 1000);

Conversely, when translating the expression

x = joe π foo; // never calls getFoo

the compiler would not start hunting for agetFoo method. If there was no property foo , the expression would simply be an error.

By default, properties would presumably be implemented as a private field and a pair of public methods, with mangled names, similar to mangling in inner classes. For example,

public class Employee
{    private double $salary;    public void $salary$set(double);    public double $salary$get();    . . .
}

The getReadMethod and getWriteMethod ofjava.beans.PropertyDescriptor return the Methodobjects of these methods, so they can be invoked reflectively in tools.

The JavaBeans specification makes it quite clear that properties are intended for tools. The GUI builder or the persistence provider has a legitimate need to access properties that may be different from the needs of the programmer. Maybe one shouldn't even have a property access operator? Or should tool properties simply be private?

When you have a private property, the methods would still be generated, but they are only accessible through introspection (when access control permits), or as this π property in other methods of the same class.

Property Annotation Issues

Of course, annotations should be updated to work with native properties. Something like

@OneToMany
private Π Collection<Choice> choices;

Ideally, a property annotation is associated with the property itself and not with a method or field. But annotations are placed into the class files. Do we want to have yet another class file format change that can express properties and property annotations???

What about compatibility with existing tools and standards? The JPA annotation processor currently handles annotations of either fields or getters. Should annotating a property automatically produce a field annotation? Should there be syntax for moving the annotation to the getter method instead? Or the other way around???

Stuff that Needs Syntax

The most common use case--a field with a trivial getter and setter--should require no boilerplate. There need to be various variations for get-only properties, properties with nontrivial getters and setters, etc. etc. I don't want to propose syntax for them, so I just tabulate what needs to be supported with some syntax

                                                 
Get-only propertyobject π property cannot be an lvalue
Set-only propertyobject π property cannot be an rvalue
Public getter/private getter?Does one want such a fine-grained control, or should the programmer just supply a private property and a public getter method?
Explicit getter/setter that does something elseThe programmer supplies a getter/setter that does something else than just reading or writing the underlying field. For example, a getter for a name property might concatenatefirstName and lastName. Of course, the method is still anonymous. For example, something like 
public Π String name get { return firstName + " " + lastName; }
would produce a method with a mangled name such as$name$get.
Explicit getter/setter that accesses hidden fieldThe programmer supplies a getter/setter that accesses the hidden field and also does something else, e.g. logging. What is the syntax for accessing the hidden field?
No fieldNot all properties give rise to a field, e.g. the nameproperty described above. Perhaps the compiler should simply see whether the getter and setter don't access the hidden field?
Bound propertiesBound properties fire listeners when the setters are called. Apparently, they are very important to some people in the Swing world. This blog article discusses some subtleties. I am really muddled about these. Would users want a separate listener for each property, or a single listener for all properties of an object? Would it be ok to synthesize the listener firing method by calling the getter before and after invoking the setter, or would users want to customize that?
Constrained properties?Constrained properties allow a veto before property changes. These are really obscure. I have never used them (except forJInternalFrame, and then only because the API forced me to). Does anyone care?
Indexed properties?The JavaBeans spec defines array-valued indexed properties with getter and setter methods for individual elements, but I have never seen them used in practice.
Property literals?A comment to this article suggests that one might want to pass around a typed property literal (such as joe π salary) for some purpose, e.g. querying its capabilities, deferred execution of the getter/setter, etc.

All of this seems pretty easy to do. The challenge is to come up with syntax that makes people happy.

I had blogged on property boilerplate and the work of my graduate student Alexandre Alves in the summer, but I didn't get much reaction then. But recently, there has been a flurry of blogs on native property syntax. Let's try this again.

Why Native Properties?

??? Many programmers are sick and tired of boring, repetitive boilerplate code for JavaBeans properties.

Here is a simple code example from the JBoss EJB3 tutorial.

@Entity
public class LineItem implements java.io.Serializable
{
   private int id;
   private double subtotal;
   private int quantity;
   private String product;
   private Order order;

   @Id @GeneratedValue(strategy=GenerationType.AUTO)
   public int getId()
   {
      return id;
   }

   public void setId(int id)
   {
      this.id = id;
   }

   public double getSubtotal()
   {
      return subtotal;
   }

   public void setSubtotal(double subtotal)
   {
      this.subtotal = subtotal;
   }

   public int getQuantity()
   {
      return quantity;
   }

   public void setQuantity(int quantity)
   {
      this.quantity = quantity;
   }

   public String getProduct()
   {
      return product;
   }

   public void setProduct(String product)
   {
      this.product = product;
   }

   @ManyToOne
   @JoinColumn(name = "order_id")
   public Order getOrder()
   {
      return order;
   }

   public void setOrder(Order order)
   {
      this.order = order;
   }
}

64 lines. Boring, repetitive lines.

Alex's implementation of native properties crunched it down to 12 lines. (Don't get hung up on the @Property syntax--see below...)

@Entity
public class LineItem implements java.io.Serializable
{
   @Id @GeneratedValue(strategy=GenerationType.AUTO) 
   @Property private int id;
   @Property private double subtotal;
   @Property private int quantity;
   @Property private String product;
   @ManyToOne
   @JoinColumn(name = "order_id")
   @Property private Order order;@
}

???I thought this would be a total no-brainer. Wouldn't you rather read 12 lines of code than 64 lines?

Well, apparently not everyone. There are many emotional reactions floating around in the blogosphere.

"What's the Big Deal, Dude? My IDE Writes Getters/Setters for Me!"

Does your IDE also read them to you, dude?

Seriously, maybe an IDE could do intelligent code folding and show you a one-line property when it sees six lines of getter/setter pairs in the code. That sounds rather fragile, but it would be better than nothing.

"The Arrows are So Ugly! No, they are Silly!"

???Where do the arrows come in, you ask. There are several proposals for a property access operator.

  • Danny Coward floated the arrow operator, such as item->quantity = 10;
  • Alex used the .@ operator, such as item.@quantity = 10;
  • Many people say "Let's just use the dot--it works for C#"
  • Some people say "Let's not have any property access operator. Just call the getters and setters."

The arrow got people excited. Everyone loves to hate the arrow (see here, here, and here). I don't know why--it is just an operator. Maybe.@ is prettier? Surely, there is some token that can be parsed unambiguously and that doesn't cause emotional waves.

Using just the dot is unfortunately a minefield. You'd have to look closely what item.quantity means. Is there an accessible field quantity? Is there a quantityproperty? Who wins if both are present? Or is that illegal? I am sure that one can cook up a set of rules, but is it worth it? Why are people so attached to the dot? For example, Peter von der Ahé writes: "It has to be '.' (dot). Anything else would look silly."

Having no operator at all might work. Look at the EJB3 example--most of the getters and setters invocations are done through reflection anyway.

"Getters and Setters are Evil!"

???There is a lot of sanctimonious handwringing on how getters and setters break encapsulation. Yup. They do. People should never write code like that LineItem class. But guess what...they do.

Why do good people write such evil code? Many tools require bean properties. If you write EJB3 entities, JSF components, client-side components, etc. etc, you end up writing lots and lots of getters and setters.

"Let's Break Free from Beans!"

???One of programmers at Borland once told me how, around 1996, their team showed the Delphi GUI builder to the Java group. Their eyes popped out. They had never seen a visual GUI builder. They had never understood why people preferred Visual Basic over AWT or Motif--after all, everyone knows that Basic is icky. But once they realized that a VB programmer can do in a day what takes weeks in Motif, they too wanted a GUI builder. A GUI builder shows a property sheet. Java needed properties. That's how the JavaBeans spec was born--it fakes properties as getter/setter method pairs. [I don't know if this story is actually true--I'd love to hear from the Java veterans.]

Of course, faking properties as getter/setter method pairs has been an ugly mess.

It is tempting to start with a clean slate. My guess, though, is, that we will get some integration of native properties withjava.beans.Introspector, for compatibility with legacy code.

"Don't Break My Code with a New Keyword!"

Alex used the @Property annotation in his prototype. Sure, a property keyword would have been nicer, but that breaks the gabazillion lines of code that use property as a name. Then again, annotations are not supposed to change the semantics of the class to which they are applied, but Alex'@Property synthesizes getters and setters. What can be done?

  • Abuse a rarely used keyword, such as static,super, or goto.
  • Use a token. That's what happened in Java 5. for (element : collection) instead of for (element in collection).

I think the token approach will probably win out. I hate to give an example, because people will say "that's so ugly". But just to show that it can be done...you can put an @ after the type. For example, here is a quantity property.

public int @ quantity;

I know it's ugly. Don't tell me "native properties are a bad idea because this syntax is ugly". Someone will come up with something acceptable. Or we'll all get used to something ugly, just like we got used to the colon in the for loop.

"Native Properties are Boring. Let's Talk About Closures Instead!"

???Or reified generic types. Or XML syntax. I am glad that people worry about solving (or creating) tomorrow's problems, but property boilerplate is a problem that we have today.

Let's Go Beyond the Emotions

Before vilifying a proposal because of unsightly syntax, let's summarize what one wants in native properties.

  • The common case--a private field and public getter/setter pair--should require minimal boilerplate.
  • It should be easy to supply getters and/or setters that do some other work.
  • It should be easy to specify read-only or write-only properties.
  • Javadoc should document properties.
  • There should be reflective access to properties.
  • Properties need to integrate with annotations.

Here are some issues that have been raised.

  • Should getters and setters of native properties be regular methods?
  • Should native properties be compatible with JavaBeans properties?
  • Should there be support for bound and vetoable properties?
  • Should properties have other than publicvisibility?

The issue that has gotten the most press, namely what operator, if any, to use for property access, seems the least important one.

I haven't blogged for a while, but I have plausible deniability. We just got twins.

???

Today, I discovered the JavaScript console in JDK6. From a command shell, run jrunscript (assuming, of course, that you have $JAVA_HOME/bin on your path). You get a JavaScript interpreter that lets you script Java classes. For example, try this little program:

importPackage(Packages.javax.swing);
frame = new JFrame();
label = new JLabel("Hello, World");
frame.add(label);
frame.setSize(200, 100);
frame.setVisible(true);

You get a GUI "Hello, World" program. Pretty nifty--no fussing with type declarations or the dreaded public static void main.

???

It works even better inside Emacs, with shell mode.

???

I am not smart enough to get regular expressions right on the first try, and I usually write a trivial Java program, complete with public static void main, to test them out before plugging them into a bigger program. When I discovered the JavaScript console, I figured that I no longer had to do that. Just fire up jrunscript and try it out:

js> Arrays.toString("foo bar".split(" "));
script error: sun.org.mozilla.javascript.internal.EvaluatorException: The choice of Java constructor toString matching JavaScript argument types (object) is ambiguous; candidate constructors are: 
    class java.lang.String toString(long[])
    class java.lang.String toString(int[])
    class java.lang.String toString(short[])
    class java.lang.String toString(char[])
    class java.lang.String toString(byte[])
    class java.lang.String toString(boolean[])
    class java.lang.String toString(float[])
    class java.lang.String toString(double[])
    class java.lang.String toString(java.lang.Object[]) (<STDIN>#1) in <STDIN> at line number 1

Ok, whatever.

js> Arrays.asList("foo bar".split(" "));
[foo, bar]

Good--that worked. What about arbitrary white space:

js> Arrays.asList("foo bar".split("\\s+"));
[foo bar]

WTH? Why didn't it split? Do I need one backslash? Four backslashes?

js> Arrays.asList("foo bar".split("\s+"));
[foo bar]
js> Arrays.asList("foo bar".split("\\\\s+"));
[foo bar]

Arggh. Back to good old public static void main:

import java.util.*;
public class Test {
   public static void main(String[] args) throws Exception {
      System.out.println(Arrays.asList("foo bar".split("\\s+")));
   }
}

The output is, of course,

[foo, bar]

Why doesn't this work in JavaScript? Perhaps JavaScript's strings aren't the same as Java String objects? Finally, I tried

js> Arrays.asList(new java.lang.String("foo bar").split("\\s+"));
[foo, bar]

Sweet success. But I am not sure I understand what is going on.

I often hear about the productivity gains of scripting languages, but I am not left with the warm and fuzzy feeling that the JavaScript console will save me time in the future.