Guy Wiener

I thought that my trustworthy Dell laptop with 2 GB of RAM will serve me throughout my Ph.D, but that was before I had to develop an Eclipse plug-in. A single instance of Eclipse Galileo modelling edition chews up 360 MB of RAM just for starters. Running another instance in debug mode doubles the weight, at least. Pile upon that a couple of UML2 documents with their fancy editors, et voila! Half of the RAM is gone.

Why is that? Even the notoriously hoggish IntelliJ IDEA 8 doesn’t take that much RAM. I don’t know for sure how comes Eclipse became the new memory hog in town, but I have a guess: It has something to do with EMF.

EMF stands for “Eclipse Modeling Framework”. It’s the underlying layer that enables all those nice property sheets and graphical editors. Basically, it adds highly-detailed reflection to Plain-Old Java Objects (POJOs) by generating a massive amount of code. This reflection is needed for auto-generating all that fancy GUI, but it requires supporting data structures - And that shows up on the system monitor.

(Btw, if you’re willing to pay the price for reflection, why not use a language that have native reflection, such as Python, and get rid of those code-generated monstrosities? Just a thought.)

No solution this time. It is a ranting post.

The following Java code is legal, believe it or not:

public enum MyEnum {
  INST1() {
    public void foo() {
      //...
    }
  },
  INST2...;
}

What the f…?!

Continue Reading »

I was preparing a sketch-of a solution for the assignment I’m going to give to the students in OOP. It’s a Java program, so I used IntelliJ IDEA. The following piece of code had a warning sign on it:

System.out.printf("0, %s, %s, %s, %d\n",
  reg.getUsername(), reg.getFirstName(), reg.getSurname(), reg.getSalary());

The warning was: “format string does not match the types of its arguments.”

The reason: “getSalary()” returns float, not an integer, so the last arg should be “%f” and not “%d”.

Son Of A Bitch! That cocky IDE watches over my format strings!

The next logical step, I suppose, is to do SQL syntax check to query strings, and then warn against SQL injection attacks (a.k.a “Little Bobby Tables“), and then write code instead of us, retarded humans.

The question is: If an IDE can do that - Why it cannot be a language feature? Why doesn’t the compiler steps in?

My Advisor, Dr. Mayer Goldberg, claims that object-oriented programming is like functional programming, only with named arguments. Objects are closures. Constructors are lambdas. Invoking a method is applying the closure. That’s it.

I faced a good demonstrations of that claim while I was working on a small code generator. I wanted to exploit Java’s annotation processing, so I can make this generator a part of a build process. The annotation processing mechanism uses the visitor design pattern extensively. By “extensively” I actually mean “you cannot get a concrete value without using at least two visitors”. These visitors are:

1. Element visitor: Since Java code is composed of packages, classes, methods and so on, you need a visitor to tell you which kind of element you are currenly holding.
2. Type visitors: A type in Java can be a declared type (class, interface, etc.), an array type, primitive type and so forth, so you need a visitor to tell you which type is which.

The task that I had at hand looked simple: Given a class with methods that has a parameteric return type, get the type argument that is not the class. For example, for this class and method:

public class A {
  Association<A,B> getAB();
}

Return the element representing the type “B”. Simple enough, no?
Continue Reading »

When it comes to Java projects, I’m a big fan of JetBrain’s IntelliJ IDEA. I’ve been using it for many year. I even owned a personal license when my work did not gave me one. So when version 8 came out, I upgraded quickly. Luckily for me, I did not delete right away the installation of version 7 that I had. IDEA 8 was practically un-usable. It was one of the very few applications that I have ever downgraded. It was so sluggishly slow that I practically could not use it. IntelliJ IDEA is a notoriously fat application, but it was so slow that I could not type a single line. But don’t worry! It’s not a ranting post. Solutions follow.

Continue Reading »

Bruce Eckel commented in this post earlier this year that Java is reaching an evolutionary dead end. While hacking my way through the javac code + listening to the SOA lecture, I couldn’t help wondering if he’s right. Java might be  too complex to evolve.

Continue Reading »

I had a creepy experience this morning. One of my former students met me in the hallway and told me that he sees a lot of my code nowadays. He works in the same company that I left to start my Ph.D.

I left this company (in good terms) about two and a half years ago. I wrote that specific piece of code even before that. So the original code was written at least three years ago. It was not even code for one of my main projects. I contributed this specific class to a friend’s project. However, because IntelliJ put a file header with my login on it, it became “my code”.

Code never dies. I hope someone maintains this code. Surely I didn’t for the last couple of years. Code ownership, apparently, never dies too. Until someone will be kind enough to erase my login from the class comment, it will remain “my code”.

It’s tempting to finish this post by saying “Remember this next time you code”, but the truth is that no form of coding standard or documentation can remain valid forever. The only way around “code rot” is if the current developer is reminded to review and fix relevant codes automatically. As long as we lack such a tool, our codes will continue haunt us.

When I try to remember the Data Structures course I did some years ago, I recall vaguely that:

1. Linked lists should take less memory then array-based lists
2. Hash tables should take more memory then tree-based maps

I actually put these believes to the test today. I profiled a small Java program that added 100,000 elements to these collections. The results were surprising:

1. Unless you delete a lot of elements, linked lists take twice more memory then array lists
2. If you have a good hash functions, hash tables consume only a small amount of memory more then tree maps

The explanation, in both cases is as follows: Array lists and hash tables are supposed to consume more memory then their array-based counterparts because the array-based implementations must keep an array that is larger then the exact capacity, while the size of node-based collections is concise. However, since the size of a reference is the same as of an array cell, the math is different: Array-based collections keep an array that is 1.5 larger then needed, so their size is 1.5N. Each node in a linked list or a tree map must keep a couple of references at least, so their size is 2N or 3N.

This is true in the case of reference-based languages, such as Java et al. The exception is for value-based languages, such as C++, for collections of concrete elements instead of pointers. In this case, the size of an empty array cell is the same as of a stored element, so the array wastes more memory.

Conclusions:

1. In Java, if you have a collection and you do not add and remove elements frequently, use an array-based implementation rather then a node-based one
2. Validate your assumptions! As the great sensei Steven Segal once said, “Assumption is the mother of all fuck-ups”

In Smalltalk (a.k.a OOP’s Latin), it takes a single call to get all the classes that inherit from class X:

X subclasses

It sounds like a bit of an exotic task, but actually it’s a single-liner for a plug-ins mechanism. Just load a class that extends “MyPlugIn” into the Smalltalk image and Voila! Your plug-in is loaded.

I thought that this mechanism is missing from Java (a.k.a Smalltalk-wannabe), until I found out that the good fellows from the Apache foundation did that too, and named it commons-discovery. The equivalent Java command is a bit more complicated:

DiscoverClass discoverClass = new DiscoverClass();
Class x = (Class)discoverClass.find(X.class);

But it’s still a neat trick. Kudos!