How not to implement Comparable

I have already blogged about the danger of numeric overflows. I recently came across this example in Java course materials (!!!):

public class Foo implements Comparable<Foo> {
private int number;
public int compareTo(Foo o) {
  if (this == o) return 0;
  return number - o.number;
}
}

How do you think Integer.MAX_VALUE compares to negative numbers? It will appear smaller. This reminds me of even worse case we encountered in a real codebase. Look at this:

public class Foo implements Comparable<Foo> {
private long id;
//...
public int compareTo(Foo o) {
  if (this == o) return 0;
  return (int)(id - o.id);
}
public boolean equals(Object o) {
  return o != null && (o instanceOf Foo) && compareTo((Foo)o) == 0;
}
}

How do you think new Foo(8325671243L) and new Foo(25505540427L) compare? They are equal, but I will do it ala Weiqi Gao and leave you to find out why... :-)

Static initializers - update

After some interesting comments to my previous write-up I decided to make a follow-up post with some additional details.

Here is the code from Effective Java:

public class Person {
 private final Date birthDate;
 //...
 private static final Date BOOM_START;
 private static final Date BOOM_END;

 static {
   Calendar gmtCal = Calendar.getInstance(TimeZone.getTimeZone("GMT"));
   gmtCal.set(1946, Calendar.JANUARY, 1, 0, 0, 0);
   BOOM_START = gmtCal.getTime();
   gmtCal.set(1965, Calendar.JANUARY, 1, 0, 0, 0);
   BOOM_END = gmtCal.getTime();
 }

 public boolean isBabyBoomer() {
   return birthDate.compareTo(BOOM_START) >= 0 &&
     birthDate.compareTo(BOOM_END) < 0;
 }
}

and here's how I would have changed it:

public class BabyBoom {
 private static final BabyBoom boom = new BabyBoom();
 private Date start = null;
 private Date end = null;

 private BabyBoom() {}

 public static BabyBoom getInstance() {
   if (boom.start == null || boom.end == null) {
     Calendar gmtCal = Calendar.getInstance(TimeZone.getTimeZone("GMT"));
     gmtCal.set(1946, Calendar.JANUARY, 1, 0, 0, 0);
     boom.start = gmtCal.getTime();
     gmtCal.set(1965, Calendar.JANUARY, 1, 0, 0, 0);
     boom.end = gmtCal.getTime();
   }
   return boom;
 }

 public boolean contains(Date birthDate) {
   return birthDate.compareTo(start) >= 0 && birthDate.compareTo(end) < 0;
 }
}

public class Person {
 private final Date birthDate;
 //...
 public boolean isBabyBoomer() {
   BabyBoom boom = BabyBoom.getInstance();
   return boom.contains(birthDate);
 }
}

I didn't synchronize getInstance, because initializing the dates twice does no harm, so it's not worth the price of synchronization. However I did check that both fields are initialized before returning the object in getInstance. 

A case against static initializers

"Effective Java" is an excellent book. I recently bought the 2nd edition, and it is absolutely fabulous, priceless. However after quite some time in the industry, I've learnt not to take any advice blindly. First edition was also excellent, but several of the items were revisited since then. So here's an item that I have mixed feelings about - Avoid creating unnecessary objects. The advice is to use static initializers for the expensive computation. 

Static initializers are double-edged sword. It's like with the stock exchange in times of crisis - for a particular individual it may be a good idea to sell the stock, but the trouble is that everybody's doing it, and in the end everybody's losing big-time. Same applies to static initializers. One or two may seem harmless, but they add up and together create a big problem. The fact that static initializers are (edit) may be invoked at program start-up affects everybody and since they potentially interfere with classloading, it's very hard (edit) harder to debug them if anything goes wrong.

Here is how it usually gets out of hand: people start with initializing static members in static blocks. Map of values, sort of configuration details. That alone sounds harmless. But soon comes the time when the values in a map need to be read from a properties file, so here we got IO within static block. Uh oh, better catch these exceptions. Before you notice the whole thing turns into a puzzler. Don't believe me? Here's a real problem I had.

Server in Java, client is either applet or JNLP. On certain machines, only one of them can run. You run server first - client never comes up, no error whatsoever. You reboot and connect as client to another machine - no problem. But if you try to start up the server locally - silent death. A team in India spends months on it. In vain. The whole release is detained, escalation to senior management. The thing ends up on my desk after a ruthless blame game between teams. Long story short: it's a DirectX problem. Why the **** does the server need DirectX? Ah. What's next after reading defaults from a properties file? Reading them from the database. Oh, but it's a different process, and the database needs to be up. So we not just connect to database from initialization block, we wait for the database process to be up. Great idea. How? We follow "best coding practices" and reuse: find a poller utility somewhere in the JDK. Apparently there is a java.awt.Timer. Why not? Great idea. Apparently, a touch of one AWT class causes a bunch of other AWT classes to load, which in turn loads DirectX and OpenGL dlls. And guess what - Windows on some machines has a nasty bug, that only allows to load them once per machine, regardless of the user. And when another user tries to do it - the loading gets stuck. And our server is of course a system process, while the client belongs to the logged in user. 

Since it was a last minute fix, we solved it with some JVM flags that disabled DirectX and OpenGL. The problem was not the fix, but the diagnosis. If it was part of the regular code, it would have been easy to connect with a debugger, see what call gets stuck, investigate it from there. But as it was part of start-up, people didn't know where to look. Not to mention the man-months accumulatively spent by developers who waited for the server to restart when testing. 

So... what's the lesson here? Life is better without static, avoid it as much as you can. 

Java... tea?

No clone for you!

Java Practices call Cloneable/Object#clone API pathalogical and suggest to avoid it. I have to agree. Here's my little story. 

I have a method that receives a certain object, which is Cloneable. Now I want to actually clone that object, so I am calling the clone method. Makes sense, no? Apparently not. My slightly outdated version of IDEA was confused, just as I was, and did not complain. But Javac was cruel and uncompromizing. No clone for you. 

Because Cloneable does not require a clone() method, and Object#clone() can be protected. WTF? My objects subclass different not-necessarily-cloneable classes, so they can't have a common cloneable superclass. So I'll define my own ReallyCloneable interface that has a public clone method, sounds simple enough...? Not!

public interface ReallyCloneable extends Cloneable {
    public Object clone() _
}

Now I realize there's CloneNotSupportedException to throw. A checked exception. I have 2 options: be a good girl, adhere to best practices and clone the signature of Object#clone, or ... not. Let's explore both options. 

public interface ReallyCloneable extends Cloneable {
    public Object clone() throws CloneNotSupportedException;
}

Now all my classes (let's assume they are simple enough to contain only primitives, Strings and arrays of the above) implement ReallyCloneable and add those 3 lines:

public Object clone() throws CloneNotSupportedException {
    return super.clone();
}

But whoever clones my objects also needs to add:

try {
    //call clone
} catch (CloneNotSupportedException e)  {
    //handle it... how???
}

Because implementing Cloneable and all the rest means that JVM will not necessarity throw CloneNotSupportedException, but as far as Javac is concerned, it still may. So no matter what, the caller needs to prepare himself for the worst. Then why bother with interfaces and all that, I ask? People say Java is verbose. I don't mind verbose, but bloated with boiler-plate to this extent?! 

The other option is not to declare the exception in ReallyCloneable. This is possible because overriding rules do not require to throw the exceptions of the overridden method.

public Object clone() {
  try {
    return super.clone();
  } catch (CloneNotSupportedException e) {
    //hm...? 
  }
}

Even though JLS allows it, my IDE and static analysis tools will complain. So I have to either reconfigure them or add some "escape" annotations. More typing... By now I feel like a typomaniac. And wait, I should handle the exception - I don't want to swallow it. Besides, what if someone really objects to being cloned? There is a need for a runtime exception. 

public class CloneFailedException extends RuntimeException {
public CloneFailedException() {
super();
}
  public CloneFailedException(CloneNotSupportedException e) {
    super(e);
  }
}

and

public Object clone() {
  try {
    return super.clone();
  } catch (CloneNotSupportedException e) {
    throw new CloneFailedException(e); 
  }
}

Now at least the callers don't have to catch. But they will still have to cast, because there is no way to express a self type with Java's static types system. Sigh.

And all this why? and for what? Couldn't we just have Cloneable with a public clone and a RuntimeException to throw if we didn't want to be cloned? Simple as that? 

This is yet another example of static type system's failed attempt to protect us from ourselves. 

Brains, bucks and programming languages

The title is supposed to be a paraphrase of "sex, drugs and rock'n'roll" in a geeky context.

This autumn I went to see Paul McCartney in concert - a lifetime dream come true. For most people Paul McCartney is first of all an ex-Beatle. Indeed, during the concert he played many classic Beatles tunes to please the audience. And the audience was very pleased. Then, he cashed in the multi-million-dollar cheque and went back to England to do what he really likes - which at this point seems to be composing experimental electronic music.  To me it looks pretty fair. 

Recently I listenned  to James Gosling's keynote at the JVM Language Summit. I actually enjoyed the presentation very much. One of the things he said, was something like "My dream would be to implement Fortran over JVM ... ah, but I have a day-job".  Now, not that JVM really needs a Fortran IMO. But think about it for a second. How many people in the world can design a programming language? How many of them can design a good programming language? And a popular one? Java is more popular than Beatles. Uhm, well... even if it's not, you get the idea.  Now what can be more important for James Gosling to do during his day job than design a programming language of his choice, I should ask his employer? What? Throwing T-shirts at JavaOne attendants? No, really. Why is it that James Gosling can't do anything he freaking likes for the rest of his life?

I think something in our business is unfair. I am not saying Microsoft model is right, I am very pro open-source and free software and all that. But I'm confused - something about it isn't right. Large IT companies make loads of money, and waste a lot of it on complete crap - I've seen this from inside. So how come Gilad Bracha cannot find funding for Newspeak development? This is totally surreal!

There goes another angry post.

 

DSL - fuel for life

Do you feel that your programming language is too bloated? I do, and I know I am not alone. 

Let's take a look at Java. You may ask - what do you mean, when you say Java? Ah, good question. There is Java, the language, as described in the spec. Java the Standard. Don't you wonder where's the new edition of the book, BTW? Anyway, then there's mini-edition, enterprise edition, real-time Java... there's a huge stack of official/certified technologies (e.g. all the JEE stuff - is JSP or JSF Java? is JPQL?), for which there are often multiple vendors. That's not all, there are all the popular open-source frameworks that don't bother getting Sun's approval, and yet they possess lion-share of the market (e.g. Eclipse, Spring). There's no chance to even keep track of all this, forget mastering. And yet, I don't feel that I have all I need. I have all that, and yet I can't write a descent program the way I'd like to, because I am missing some core features. What? Let's see - how about proper modularity, closures, tuples, local type inference, properties... 

Java made the grade in expanding layer by layer - to the extent where it reminds me the state of the Earth in Wall-E. If you haven't seen the movie, I'll just say that the Earth drowned in human-produced garbage, and the garbage made it inhabitable for anything organic. The garbage in Java makes it impossible for the core, organic features of the language to grow. In the movie, people are leaving, and robots stay back to clean up - now you make the analogy. 

As a Java programmer I really identify with Wall-E. Moving tons of garbage around, day after day, in a desperate attempt to clean up the world - something obviously impossible. And man, I'd love to be that flying-iPod-looking Eve from outer space. She's so strong, so modern, so clean and shiny...  And she has a mission!

If Wall-E is my Java, then my Eve is no doubt Newspeak. 

So what does it mean in a wider sense of programming languages? I think good language should have a small core, as little redundancy as possible. And it should grow from then on. Here's Guy Steel at OOPSLA '98:

I think that the best way of growing is via internal domain specific languages, DSLs, - you don't change the core language, yet you cover more and more domains. Anders Hejlsberg also talked about it at the recent PDC conference - adding features as a DSL; and then, if the DSL is very successful and popular, add syntactic sugar to the core language, as they did with LINQ. I don't think that you need that latter part if your language is well suited for DSLs to begin with. So the language should have a small core and be well suited for DSLs. Java isn't DSL-friendly. Scala is much better, e.g. the Actors library. Haskell, Ruby and of course Smalltalk are really good at it. 

The last part is getting rid of garbage as you grow, and again, Gilad has an idea how to do that. 

I could go on forever and ever about DSLs, showing examples like parser combinators, unit-test and SQL libraries and so on. Martin Fowler is writing a book. So, instead of boring you with repeating what's been said many times, and enumerating lots of references, I will just finish with this cutest quote:

DSLs are for making languages bear-able.

For I am a bear of very little brain and long words confuse me. [Milne 1926]

The premise of this subject is that computers should adapt to the ways of people, and not the other way around.  

Types and other virtues

Here's a thought. Why do Java Generics attract so much bad vibes? If we're talking about types again, gotta visit our old friends - ML, Haskell. They are doing fine, they've got it all figured out. Hindley-Milner etc., they've proved themselves to be right.

But them and Java, it's apples and oranges. So to bring them to the same arena with object oriented languages, let's see how are they doing on the front of extensibility? Well, there are some recent advancements, polymorphic variants in OCaml, extensible records in Haskell, but it's not like the other stuff they've figured out ages ago, there's a slight hint of hesitation here.

So having types and being object oriented at the same time - maybe it's just, hm, non-trivial. If Martin Odersky says it's hard for the compiler (and he's a genius!) - then it really must be. Now look at it as a reverse Turing test - if the machine can't figure it out, how the **** are we supposed to? Which means we need an escape route. If declaring the right type is hard, we need an easy way out.

Pre-generics Java didn't bother itself too much with complex static types, the trick was to fall back on the dynamic types whenever in doubt: arrays - ArrayStoreException, collections - ClassCastException. Some say it's broken. It's a hole in a fence, but it's a way out . "Oops"

Then Generics came and fixed the hole in the fence. But, without realizing, they violated the status-quo, the eco-system, they stepped on a butterfly. Suddenly, the brain hurts, and the only way out is dumping all the angle brackets and jumping over the fence. It's a "No Exit"!

What does Scala do? Ah! First of all Scala has a much more advanced type system to start with. But the real trick is implicits. If it's too hard to declare the right type, just imperatively describe the conversion. Done deal, here's your way out. It's pretty cool, but implicits have their share of bad vibes too. Can't live with them, can't live without them, I guess.

So how about implicits for Java 7? No, actually how about Scala for Java 7? It's been done before, you know...

The Great Divide

What hasn't been said about static vs. dynamic types in programming languages? Read on at your own risk, because here I go again...

When you think of static types what comes to mind? Haskell? OCaml? Scala? Dear friend, you are better than most of us, but you have clicked the wrong URL. Peace. See you in another post...

Did you say Java? Still with me? Good. Listen, now when the others have gone, just between you and me, the guys from the previous paragraph - they're on to some good stuff. Check it out, you won't regret it. But don't quit your day job, not just yet. It's a bit complicated, but did you ever witness extreme programming methodology implemented in a big corporation? No? Then picture this: Elbonians take over Dilbert's firm and make everybody do XP. They even send pointy-haired boss to a Certified Scrum Master course. Get the outcome? It can only end like the implementation of Carl Marx's ideas in Russian countryside. I am trying to say - there are ideals, and there is reality. In reality, Haskell programs have bugs too.

So Java, you say. How do you feel about dynamic types? Cool? Get out of here. No really, it's no fun preaching to the converted. See you!

Oh no, heaven forbid, you won't touch them with a stick. You're my guy then. So let's rewind to Java 1.4 days, after all many Java developers still use 1.4 and many others look back at it with nostalgia. Are you one of them? Ok. So what about pre-generics collections, do you think they are statically typed? Hmmm... And what percentage of your code involves collections? So this code was not entirely statically checked. Now add all the reflection stuff...

But then of course came Generics. And suddenly Java is much more complex. How do I make my code compile, gee, wildcards, captures... ?! I am trying to get something done, hello!... It's easy of course to blame Generics implementation, but if we learn something from the folks whom I kindly asked to leave in the beginning, they'll tell you that finding correct static type for every element in your program is hard. They of course think that hard is good, they are noble men with ideals, they like overcoming challenges. But you and I, we're just trying to make a living. So we curse Sun and back off to an untyped collection. Hm, maybe we're just doing the right thing? Maybe sometimes we just know that our program is correct, but the compiler demands more and more typing and wastes our time?

Java 5 was all about improving type-checking. If pre-defined types were not enough, annotations came handy. Define your own and test it at compile-time or at run-time. Did it ever happen to you that there were so many annotations, that you couldn't see the code?

See, more types is not always a good thing. Unless you're very keen on intellectual challenges. James Gosling said this about Scala - functional programs will make your brain hurt, they are for calculus lovers. He's right. It's the kind of pain you feel in your muscles when you start working out, you know, that indicates they are still alive... So working out is good, but we can't afford doing it all day, ha?

Maybe the appeal of plain old Java was that it's a combination of static and dynamic checks? So it's not that all dynamic is evil, maybe it's a matter of how much and where?

Give dynamic types a break. Who knows, you may find eventually that they're good for some things.

Peace.

P.S. I've done some role playing here, just for the record. I do love Generics, even though they were hard to master. Annotations are overall very useful. Right now I don't do as much Java as I used to, and I do other fascinating languages (static and dynamic) as I, for long time, wanted to.

Two Days In A Life

The ban that Israel's government has put on The Beatles performance in the 60s disappointed not only Israelis, but many Jewish people who were part of The Beatles phenomena, like their legendary manager Brian Epstein. Over four decades later, Paul McCartney represented the Fab Four on stage in Park HaYarkon, Tel Aviv, and rocked the audience with a great show.

Negotiations for the concert have been tough, but after a series of rumors and denials the deal was finally set. Ticket offices were stormed on opening, 50,000 tickets were sold eventually, filling the park with fans and music lovers.

Read more in this illustrated account of Paul McCartney's visit to the Holy Land...

Beware of the subs

No, I don't mean these cute yellow things beneath the waves. I am going to talk about List#subList and String#substring methods in Java.

Apparently many people are unaware of what exactly these methods do. Unfortunately their ignorance may lead to unpleasant consequences. So getting straight to the point: both methods do not copy a portion of the original data, instead they create a view, or, in other words, a proxy to it. The important thing is that the new wrapper object holds a strong reference to the original object.

The Javadoc of subList at least admits that it's a view, as for substring, the only way to find out is by looking at the source - the method redirects to this constructor:

//Package private constructor which shares value array for speed.
String(int offset, int count, char value[]) {
  this.value = value;
  this.offset = offset;
  this.count = count;
}

So what's the problem? Let's look at the following snippet from a real code-base:

List leaky = ...; //long list of big & hairy objects
leaky = leaky.subList(from, to);

Assuming that leaky wasn't referenced anywhere else in the code, there is no way for the programmer to access the elements that lie beyond the (from,to) range. But these bytes aint going to rehab, no, no, no - as far as JVM is concerned they are still strongly referenced. So if you really mean to extract a portion of a list (or string), and throw the rest away - copy it manually to a new list (or string). For example:

List sneaky = ...;
sneaky = new ArrayList(sneaky.subList(from, to));

Is there any better way a "sub" could be implemented? Well, maybe the reference to the original data could be kept weak, and only when (if) the original object is enqueued for garbage collection then the data could be copied into the "view". This would require backwards references from "original" object to "views", which would also need to be weak, so... overall this doesn't seem worth the effort, and hence avoiding leaky lists and strings shall remain the responsibility of the programmer.

Speaking of subList, another nasty thing about it is that sub-list is not Serializable, nor Cloneable or anything like that, even if the original list was. And speaking of leaky things that are caused by undercover strong references - never forget non-static inner classes that refer to their enclosing instance.

Take care, and keep your head above the water :-)

Software: Live and Let Die

This week I was lucky to attend Gilad Bracha's guest lecture on Networked Serviced Programming at the Hebrew University. He has been talking about Service Objects for some time now, but nothing compares to hearing it live - Gilad's presentation was witty and fun!

So here is my interpretation and some take-aways.

What's the problem with software? It is too damn complex. Projects crumble under their own weight. It happens to successful projects - our dearly loved Java, for example. Also look at Vista, if you dare. And it's certainly true for the monster-size projects I used to work on. Once upon a time our team took the corporate "quality improvement" policy seriously and decided to investigate what causes bugs in our multi-million lines of code project. We collected all sorts of statistics and ran all possible metrics (which was tricky 'cause some of the tools would choke on such a huge code-base) but long story short our finding was this: the only metric that correlated clearly with defectiveness was LoC. It is hardly news, but a cure to the disease has yet to be found.

There are certainly several things to be done, but what this talk focused on is getting rid of code which shouldn't be there, or in other words - dumping unused code and backwards compatibility. The way we work today - we are bound to not just specs and APIs, but to all the accidental behaviors and bugs in the previous version of our code. It seems that Gilad views code as if it was a live organism. Staying alive means being connected (and network plays a central role in his vision), but we should make way for evolution and some code should die - Gilad calls it "bit rot".

So how do we turn software into a healthy living organism? According to Gilad, there are several things to be done on the technical front first.

• Take advantage of the network: maintain a bi-directional connection with the control center - let programs pull upgrades from the net, but also send back operation statistics. This means that programming platform has to be aware of the network, and aware of the fallacies of distributed computing. This is cloud computing utopia: Internet as a platform, browser as an OS, and Javascript as the low-level programming language into which other languages can compile (in a GWT kind a way).
  
• Modularity: it should be possible to extend and replace individual objects without interference to the whole organism. Gilad has a well developed theory about how modularity should be done in a programming language, based on principles of object-orientation using mix-ins, nested classes and inheritance hierarchies; his new language, Newspeak, is going to implement it.
• Explicit Dependencies between modules - no static, no imports, modules are truely independent and dependency management (wiring) is performed by passing other module instances as parameters to module constructors. This allows to maintain clear boundaries between modules and flexibility in module composition.
  
• Frequent Updates: to allow the "clients" of the object APIs to deal with changes, in addition to maintaining modularity, the changes should be made small and frequent. Call it agility, if you like. That means that we can't afford reboots, and we need to find out when the system is quiescent so that upgrade can be performed, which brings us to the next point...
  
• Reflection and Hot-swapping: objects should allow other objects to find out both static and run-time information about them without breaking the encapsulation. Objects should also allow other objects to modify them "live". Gilad and his team at Cadence are building the support for these features in Newspeak using Mirrors, a concept that originates in Self programming language. It's worth noting that there exist dynamically typed languages that implement hot-swapping today - Erlang being one of them.
  
• Security is important in any distributed system, and even more so if we allow remote objects to mess with the program. So in addition to dynamic typing and pointer safety, Gilad proposes mirrors to be guarded by capability-based security, similar to the one in E programming language.
• Synchronization: many programs need to work with persistent data and it is important to keep the program and the data in-sync. Gilad proposes orthogonal synchronization, based on Smalltalk orthogonal persistence idea, where objects are split into transient and persistent ones by marking object tree roots accordingly. Persistent objects are upgraded whenever the corresponding part of the program is upgraded, and transient objects are lazily recomputed. If the data is ever to outlive the service, it would be exported into some generic format, such as XML.
  
• The most extreme and bold part of this vision is probably No Versions and No Releases - there would be only one version for every program out there. Gilad sees software becoming more of a service than a product, but in order for this to realize we'll have to overcome not just technological, but also psychological and economical barriers - we will have to change the way we develop software and the way we make money of it.
  

Bottom line, all this may sound too futuristic, but "software as a service" and "platform as a service" are making their way in the industry and this wave, if strong and successful enough, may bring the significant change Gilad is predicting.

P.S. As for the rest of us, living in the JVM world, some of the ideas ring a bell. We hope that modularity JSRs and OSGi will improve Java. Those of us who survived Ant and Maven, and felt the weight of a DI framework, will probably appreciate the amount attention Gilad is putting into software composition. It's worth noting the attempts to address hot-swapping on JVM, such as JavaRebel and Jonas Boner's experiments with Scala Actors and Terracotta. Terracotta server also utilizes some ideas which (in my mind at least) look quite similar to the orthogonal synchronization scheme.

JunkedIn

Indeed LinkedIn runs on Java, no doubt about it:

Noble cause

Duchess is an on-line community of female Java developers with members from all over the world, but currently active mainly in the Netherlands. I figured they could use some promotion, besides it's a perfect excuse to put this cute mascot on my blog:

Typesy Turvy

Lambda The Ultimate feed just notified me that types are considered harmful. Ah yes, I heard this before, so what's the news? The news is that it's not Stevey vs. Cedric or anything like that, this is Benjamin C. Pierce in his own write. Benjamin C. Pierce, from "Types and Programming Languages" and "Advanced Types and Programming Languages", King of ML, Lord of the Functional Programming Commonwealth, Defender of Type Systems Faith!

Nice presentation, BTW. I think it's one of these situations when a big shot computer scientist is confronted with a real life problem. So you say the language is perfect for writing a compiler - good for you. How about a database application with a web front-end?


(click to see full-size)

Mr. Language Designer, where are you in this picture? Yes you, who designed the mousetrap which "the bug" has safely escaped from. Now it is here, so are you at least by the developer side, handing him something heavy to throw at "the bug", or are you on the bed with the rest of the crowd going "ah ah ah, what do they teach computer science graduates these days..."?

One thing that impressed me during otherwise boring (let me just read you aloud the tutorial) JRuby on Rails preso I recently attended - here is a system that tries to serve the needs of the developer. Not server vendor, not language designer, not JSR politician, not some brandthirsty marketing person or buzz-oriented architect, THE DEVELOPER. I am not used to that. So all I have to say - programmers of the world, unite! Stand for your rights! We deserve better tools, because we are the ones getting the job done.

Thank you for reading.

In whining there is truth?

What do Java developers want? Hard to say. But here is what Java bloggers don't want Sun to do:
No evolving Java syntax - no properties, no closures, etc. - fix what is already there first.
No extending Java capabilities via annotations.
No investing in a new JVM language (JavaFX, or JRuby in the past)
Ok, maybe add Groovy, but don't change JVM spec.
Hey, wait, why are key people leaving Sun? We didn't want that either!

Girl Power

I have been reading recently that women are abandoning computer science, and that percentage of women in our profession is not just low, but getting lower. I'm not sure actually that the situation here is as bad as in North America, but it's certainly true that software engineering and computer science are not very popular among women. Why? To be honest, I don't have the answer.

Here is what comes to mind:

• Geek-ness is viewed in the society as the opposite of being attractive; this is much more important for young women, than for men. For a guy - a nice high-tech salary will provide the attraction instead.
  
• Sitting in a cube by the computer all day and doing one thing, coding, is probably not very attractive for most people, but for women especially, since most of us are better at performing a variety of tasks and interacting with people - I mean there has to be an explanation why "secretary" or "teacher" are such typical women professions.
• Hi-tech jobs are very demanding, too demanding. For most women family life is at least as important as professional life, and usually family comes first. But there just aren't many positions you can find after getting computer science degree that allow you easily balance work and family life.
  
• Hi-tech is for young people - look around, how many programmers you know are over 45? Why? For the same reason you don't see many women - it's hard to compete with the smart kids when you are pregnant, or haven't slept for a week, or worried about some family matter.
• But can't we just switch roles with the husband? well, go back to first bullet, double standards of the society certainly don't make it easier on us or our partners.
  
• People we are surrounded with (nerdy young men mostly) are pretty anti-social creatures in the first place, even more so with species of the other sex, even more so with the ones that don't fit social stereotype.
  
• Now suppose you survived all the obstacles, because you passionately love science and engineering. Did you watch the knack? There's a grain of truth there... society became less tolerant of weirdness, and people who 100 years ago may have been referred to as crazy geniuses nowadays live "normal life" on prescribed medications. And for a girl it's even stranger to be a crazy genius then for a boy.
• Male domination in the field - yes, it's chicken and egg problem. The field will change only if there will be enough women in it to drive the change from within and help other women. So I will devote the rest of the post to the ones who made it.

Lady Ada (Byron) Lovelace

She was more of a technical writer really, but she was a visionary.

Admiral Grace Hopper


The inventor of COBOL and debugging.

Professor Barbara Liskov


The one from the substitution principle. I chose her among several prominent computer scientist women because she was the first female computer science Ph.D in the US.

SVP Jayshree Ullal


I originally thought to put the Google princess here, but having personally met Jayshree (she was my manager's manager's manager at one point) and impressed by her personality and professionalism (she is so clever, and yet such nice and humble person), I decided she's a better candidate to represent successful women in computer industry.

Alice, Dilbert's workaholic colleague

What did she achieve exactly? Surviving in the office should not be underestimated! So I am going to honor another ex-colleague, although we never met, for providing inspiration for a character I can identify with :-)

Keep coding girls!

Net, Goddess of Wisdom

No, it's not a joke or some kind of wordplay.


Net (also Neith) was an ancient Egyptian goddess, not very well known perhaps, unlike her Hellenistic reincarnation - Athena. Net was a warrior goddess, just like Athena, and the goddess of weaving - "weaver" is actually the translation of her name.

Athena was a weaver too, according to the Arachne myth, and of course the goddess of wisdom.

So why weaving, or net, and wisdom? Well, for several reasons. What our ancient ancestors have probably recognized is that wisdom is acquired via communication. Today we know in addition that human thinking is powered by neural net in our brains. Net, yes net. We even use the same word. Internet, collective intelligence... "there's nothing new under the sun" said another wise ancient man.

Synthetic bridge method annotations

Update regarding "walls and bridges": Sun has kindly opened an enhancement request on my behalf for the issue. Please vote if you are affected by it too.

Java properties links

Since I am trying to keep up to date with what's going on in "Java Properties" land, I started with Alex Miller's collection and have been adding things that I find either relevant or influential. Another idea I nicked from Alex was to put them on Tumblog.

A disclaimer: this is a personal collection, so if something looks irrelevant, it means that I think it is influential :-)

I'll be more than glad to hear suggestions for more links or feeds.

My OO My

No, I don't mean the song, but it's to do with Scandinavia. Mads Torgersen mentioned this during interview with Joe Armstrong (highly recommended, there is also a part II), and later I saw another reference in a paper: apparently there is "Scandinavian school of object orientation", sometimes compared to "American school".

Here are some insights on the difference between the two. The point is that the former is about concepts and philosophy, and the latter is about pragmatic aspects like software reuse and organization. I am not gonna pretend that I'm smart - all I know about it comes from searching Google, so you can go there and find out for yourself.

* On a side note, since I am linking to MSDN here, I want to say that even though my last post wasn't very favorable to Microsoft, to be fair - the company plays an important role in renaissance and democratization of functional programming (LINQ, F#, etc.), with guys like Mads Torgersen and Erik Meijer largely responsible.

Open the source, sesame

About a month ago a big shot from Microsoft came to speak at the university - looks like he's on some kind of a tour, and his mission is to convince universities to teach Windows operating system aside Unix/Linux. He waved at the audience with a free license and tried very hard to prove that some aspects of Windows design are better than Unix, mainly because it is "newer" design and better suited for nowadays computers.

Long story short, one of the things he said, was that open source is bad, because engineer who looks at the source of a library will design his application assuming particular implementation, which is now tightly coupled to library internals - bad. Obviously a discussion erupted - design by contract and Eiffel were thrown in the air, relation between programming language and operating systems..., but frankly all I could think of is my distant past as a VB developer and those 1000 pages "Windows *** Unleashed" books. They were written by hackers who used trial-and-error against Windows DLLs trying to make some sense of the APIs - the formal documentation was either sloppy or intentionally incorrect to misguide us, Windows application creators outside Microsoft, since we were potential competitors. Things were so different when I moved to Java. (Though my first Swing experience made me - believe it or not - miss VB, but that's another story.)

Anyway, statement like this coming out of the mouth of a Microsoft employee, even if he has an impressive Unix record, was easy for me to dismiss. But here is a respected Smalltalker saying

"I think people should have the source ...not to get miss quoted saying I'm against open source, but I think it's important class libraries should be viewed like caves."

(Ah, wait, he is from IBM - he can be ignored too... just kidding)

I mean, seriously look at this puzzler for example - it's pretty cool, but the solution heavily relies on a particular implementation, I would even say this is actually a hack. And sometimes a hack is necessary... or is it? Is there or will there ever be a perfect environment where we can program without hacking?

P.S. The reference to Ali Baba tale in the title is intentional. Open source is good, very good, it's a treasure and in the world dominated by large corporations - almost a miracle. But IMO we should resist the temptation to exploit it to the last bit, because we might find ourselves locked in the cave.

Static methods as function objects

In one of the earlier posts I described a policy object created by "functional style programming" in Java. The basic idea is to make methods into Function and Predicate objects and then composite the logic from these building blocks. The problem though was that the policy implementation looked alien to Java. To re-cap: I wanted to invoke a different function based on the class of the object - classical multi-dispatch with a single argument.

So inspired by extension methods idea I added a new mechanism to define properties (and functions in general) - via static methods. You define a bunch of static methods with the same name (or appropriately annotated) like this:

static int size(Collection c) {
 return c.size();
}
static int size(Map map) {
 return map.size();
}
static int size(Object obj) {
 return (obj.getClass().isArray() ?
   Array.getLength(obj) : 1);
}

Now assuming I have a property declaration

Property<Object,Integer> size =
 new Property<Object,Integer>(0) {};

The underlying implementation of the size.of(object) would be a "policy" (composite function) dispatching to one of the static methods according to run-time type of the object. So that size.of("foo") is 1, size.of(Arrays.asList("a","b","c")) is 3 and size.of(null) is 0.

There are couple of issues though.

Issue #1: automatically ordering the rules. Now when rules are not added manually, I should be careful to test for more specific class first. The solution is to calculate a distance between two classes and always look for a best match - basically same algorithm javac uses when choosing methods at compile-time. This isn't fully unambiguous though: if class C implements 2 interfaces A and B, having different implementations of size(A) and size(B) would put me into a dilemma which one to choose for size(C). Javac in such a case reports an error - thanks to Java being statically typed. But once I make it a run-time decision the only logical solution is to report an error at run-time. To make the problem less acute, I could add an annotation that controls ordering of the methods.

Issue #2: this is less generic than a general predicate-based policy - it is limited to "instanceof" predicate. One of the policies I use internally in the properties project is reflectively invoke getFoo() if the class has a "getFoo" method. This isn't possible with static methods.

Issue #3: reflection. It's not really a problem, but rather an enhancement I want to make: instead of using reflection I could generate the functions at compile-time with APT, like Bruce Chapman does here. This is one of my next adventures, which I will hopefully describe in a future post.

Digg a pony

Here is another post with no helpful information, sorry, I meant to write a meaningful piece but I am on vacation and in fun spirits :-)

Anyway, I just got reminded of something that crossed my mind before and is now more relevant than ever - the term John Lennon invented almost 40 years ago: "bagism". It's amazing that at the time everybody laughed - a person giving an interview in a bag. You can look this up, or even better watch the video (fast-forward about 2 and a half minutes). Here's a short re-cap:

"if everybody had to go in a bag for a job (interview) there would be no prejudice, you see, you'd have to judge people on their quality within, you know, we call it total communication..."

I think this is really the web: blogging, mash-ups, syndications, and social networks, and why all this is a lot of fun - you really know nothing about the one you are talking to, except what he (she? it?) tells you.

Dig a pony lyrics mention

"penetrate any place you go" (...internet?...)
"radiate everything you are" (...wireless?...)
"imitate everyone you know" (...blogging? syndication?...)
"indicate everything you see" (...search? google?...)
"syndicate any boat you row" (...social networks?...)

Cheers to total communication!

P.S. A tribute to Passover holiday (the reason for my vacation): there were once four boys (ארבעה בנים) - the wise and wicked one, the cute one, the quite one, and the one that can't sing... and they were fab.

Java and closures

My reaction to the likely postponing of closures till Java 8.

Mercurial adventure on Widows

With a friend at work we decided to check out Mercurial as source control system. The repository was set up on a Linux box and zillion lines of code and libraries were sucked in from ClearCase, now I just had to clone it to my lap-top running Windows XP.

Installed Mercurial 0.9.5 via TortoiseHg (I am familiar with Tortoise with SVN so it was a natural choice) - very easy and straightforward so far. Issued clone command - hm, filename too long. Switching to cygwin - doesn't help.

So Ok, we have pretty deep directories structure and Mercurial makes it worse because it translates everything to lower case by "escaping" capital letters - adding underscore before the letter, so "A" becomes "_a" and a single underscore becomes a double one. Why? This is to avoid problems when working with case-insensitive operating systems like Windows. Fair enough, but what do I do with these long filenames now... Python bug? Oh, great. In the meantime the error became "file not found", but I (correctly) suspected the cause is the same.

I found this bug report (and this one) - at least it happenned to other people, it says I can use a 'usestore' workaround. Cool, found this - says change one of the scripts, but hey, they are compiled?! Ok, downloaded ActivePython (I admit, I never touched Python in my life) also downloaded the sources. But apparently I need a C compiler too for the full build from source - that's too much, I decided to just run Mercurial with the interpreter.

Found the right script, changed it. Boom, of course extra space in indentation - until now I only heard jokes about this (besides similar experience with Fortran half a life ago). Nevermind, got it now. Still not working. I take another look at the script - the if statement I just added was already there before! Oops, what's going on? Trying to understand the Python code - it is looking for some 'usestore' configuration option, which BTW is supposed to disable the "escaping". All I need now is to set it. Hm, how? Eventually I find out that I need to edit <TortoiseHg-install-dir>/Mercurial.ini adding

[format]
usestore=False

(If you use plain Mercurial, not Tortoise, create Mercurial.ini under <mercurial-install-dir>)

I do it and... voilà, the repository cloned!!! So bottom line - all I needed was ini file change. It is somewhat dangerous 'coz I still have the mixed case, but at least I have the code on my laptop. Why didn't I find it in an FAQ or tips'n'tricks or something? No idea. Hope this post helps the next person who googles for it.

Blonde Moment

Kirsten Dunst wearing Red and Sensual Java.

The taste of Java Generics

As the closure debate flames are rising, people are attacking Generics in order to attack closures. Some use it as a negative example against particular closure proposal, some try to discourage Java language changes in general and some to promote other languages. When I read articles that start with "Generics are hard" and lead into "Generics are bad", I can't help thinking of the fox and the grapes. Yeah, they are hard. So is concurrency, NIO and many other things. So? That's why people create frameworks on top of Java.

Don't get me wrong - Java Generics have faults, and they are long known. Here's a hit-parade of my biggest complaints, but I will also mention some solutions I have used:
1. Erasure
The way to work around it is by using type token or super-type token. As any workaround, it is limited, but it can solve part of the problem - Class#cast and Class#newInstance don't issue the annoying warnings.
2. Generic parameters not covariant
It is usually a good idea to use bound wildcards extensively.
3. No lower bounds support (except wildcards)
We can use static methods instead (ala extensions) with <T extends Super> rather than <S super Sub>
4. Verbosity, instead of more aggressive type inference
Not much to do, hm, learn to type faster? :-)
5. The angle brackets
Yeah, I hate them most when typing on blogger, luckily I am old enough to have been coding HTML in plain text editor a long time ago, so... back to GT and LT escapes.

BTW Java didn't die, it has simply grown beyond its hipness age. And I am glad that it spawned even better things, such as Scala. But there is a difference between "good" and "popular". Java is popular and not that bad, other languages may be better, but not as popular. Will Scala be willing to sacrifice some of its expressive power and shortcuts (gee, stuff like that reminds me why I don't code in Perl) to become simpler to learn/read and potentially more popular? Should it? (Ruby consciously didn't and ... didn't.) We shall see.

Listen To What The Man Said

Just couple of nice quotes for today: Alan Kay on Innovation and the not so new but still relevant Edsger W. Dijkstra transcriptions - look at this Q&A for a quick feel.

"Machine capacities now give us room galore for making a mess of it. Opportunities unlimited for fouling things up! Developing the austere intellectual discipline of keeping things sufficiently simple is in this environment a formidable challenge, both technically and educationally."

Wildcards observation

"A bug in poker is a limited form of wild card."

- Wikipedia

While looking for academic references for my properties project, I bumped into the expression problem - the write-up by Phil Wadler and follow-ups by Mads Torgersen and Matthias Zenger/Martin Odersky are really fun and educative readings.

This stuff caused me to re-read the the wildcards paper and I suddenly understood why I had this strange gut feeling about wildcard usage. Almost all learning material about Generics, including the wildcard paper itself, emphasizes the distinction between read and write methods - having a wildcard in a collection parameter prevents you from adding elements to the collection, but allows reading. This is true, but somewhat misleading. Actually, wildcard in the parameter allows us to call a method that returns the thing behind the wildcard and treat it as if the returned object is of the type of wildcard bound (or an Object, if the wildcard is unbound); the wildcard prevents us, however, from calling any method that takes "the thing behind the wildcard" as a parameter. Now obviously, to add something to a collection you need to call a method that takes that something as parameter, and it is indeed prevented, but other modifications are not disallowed, e.g. clear() .

The consequence of wildcard usage applies to any method, not just "write method", for example - containment test. So looking at Kevin's example, it now seems to me that doSomeReading method shouldn't have used a wildcard if it wished to perform a safe containment test - that's the catch (or should I say, hm, capture...)

Happy New Year!