I am baffled by the comments that this older weblog entry is receiving.  As you can see, I am simply announcing that I moved some of my projects over to java.net.  Since then, it appears that a group of Indian students have not only misunderstood the point of that post, but are also maintaining the delusion that I am offering to provide ideas for Java projects that they could do for their final year exam (on what major or studies?  I have no idea).

The phrasing of the request is also quite rude, and even though English is obviously not their native language, they are most likely able to express themselves fluently in this language.  At any rate, it doesn’t give a very good impression.

Also, none of them seem to have noticed that I haven’t offered a single idea, but the presence of the comments seems to maintain this illusion.  Maybe I should just delete the comments once and for all.

Or can a fellow Indian reader shed some light on what’s happening?

In J2ME, MIDP is the library that allows you to build user interfaces (among
other things) and its functionalities obviously much simpler than even AWT. 
The two classes of interest are:

• Form, which supports structured widgets called Items (TextField,
  ChoiceGroup, etc…)
• Canvas, the lowest-level class, where you need to paint everything
  yourself.

Faced with the task of building a User Interface, a J2ME developer will typically
consider the following options, in increasing order of difficulty:

1. Use a Form with the standard Items.
2. Use a Form with custom Items.
3. Use a Canvas.

For obvious reasons, the standard Items are pretty crude and offer only the
simplest functionality.  On the other hand, writing a Canvas from scratch is quite challenging
and requires a lot of geometric calculations and 2D drawing.  Therefore,
option 2 presents a strong appeal, striking a good balance between the other two
options.

Taking a look at the Item class, we see that it has three abstract methods,
one of which is paint() and the other two return size-related information. 
So far, so good, it seems simple enough.

Except that…  Sun made it impossible for you to extend Item in MIDP
1.0.

Why?

Because the Item class only has package-protected constructors:

public abstract class Item {
Item(String label) { ... }
Item(String label, int num) { ... }

And a closer look at the class reveals that even the abstract methods
mentioned above are package-protected as well…  I’m not sure what genius came up with this design but more distressing
is the fact that Sun actually shipped this class, which is installed on millions
of devices as we speak. 

Interestingly, they seem to have realized their mistake because MIDP 2.0
comes with a new class, CustomItem, which exposes the carefully hidden
constructors to the outside world:

public abstract class CustomItem extends Item {
protected Item(String label) { ... }

It’s too bad that MIDP 2.0 will not be widely available on phones before at
least a couple of years…

Until then, it’s back to good-ole Canvas programming.  It feels like
1996 all over again.

Mike Spille’s article on Inversion of Control containers was, as always,
thoroughly researched and quite illuminating.  It also brought up the old issue of cyclical dependencies, which are usually identified
as a very ugly practice.  Software fundamentalists are quick to point out
that if you see a cycle in your classes or your packages, you should immediately
remove it.

I wish it were that simple.

The sad truth is that sometimes, cyclical dependencies are not only
necessary, they are actually quite essential and contribute greatly to making
your code more readable and maintainable.

The dangers of cyclical dependencies are well-known (stronger coupling,
fragile build, etc…) as are the remedies (the introduction of an interface is
usually a good start).  For example, the following dependency:

public class Person {
public List<Account> getAccounts();
}
public class Account {
public Person getOwner();
}

can be refactored like this:

public interface IAccount {
}
public class Account implements IAccount {
}
public class Person {
public List<IAccount> getAccounts();
}

By introducing an interface, you have decoupled your two concrete classes,
which is usually a good thing.

The point of this post is not to offer a
critique of this method but to bring up two points:

• Your code is more decoupled but it’s also more complex.
• The concept of a "cyclical dependency" is highly dependent on the
  language you are using.

The second point is obvious:  the perception of a "cyclical dependency" is very different in
Java and, say, in C++, where you will usually declare and implement two coupled
classed in the same file, thereby reducing the physical dependency (but not the
logical one).

The first point is more subtle.

In the example code above, you now have three classes where you used to have
two.  And two of these three classes need to be kept in sync (IAccount must be modified whenever
you modify Account).  As I said earlier, it is usually a good thing, but
not always, as was the case with Mike’s JobDispatcher example.

I find that most of the time, cycles are created as a consequence of a
previous refactoring in which you have been breaking down one complex class into
two smaller ones.  There is clearly tension between two goals that are
sometimes at odds:  you can’t always decrease both the complexity and the "coupledness"
of your code (I know it’s not a word, sorry, couldn’t come up with a better
one).  If you improve one, you will probably make the other worse.

Overall, introducing an interface in your code is usually the right choice,
but there are some exceptions.  Keep them in mind the next time someone is
trying to convince you that your code is evil because two classes have a
circular dependency on each other.

I personally find that this code snippet demonstrating constructor chaining is hard to read.

This code makes it very hard to identify which of the many constructors is the "real" one:  the constructor that does the real job and that I should call if I add a new overloaded constructor.

This is why I use the following two rules when I write overloaded constructors:

• Have all your constructors converge toward one unique private method that you will name consistently throughout your code base (e.g. init) and that will contain the entirety of all the parameters that your constructors may receive.
• Don’t add any logic to the constructors, all they should do is invoke init with the right parameters and null for default ones.

Here is an example, from worst:

public class Person {
  private String m_firstName = null;
  private String m_lastName = null;
  private long m_ssn = 0;
  public Person(String lastName) {
    m_firstName = null;
    m_lastName = lastName;
    m_ssn = getSsn();
  }
  public Person(String firstName, String lastName) {
    m_firstName = firstName;
    m_lastName = lastName;
  }

…
to better:

public Person(String lastName) {
  this(null, lastName);
  m_ssn = getSsn();
}
public Person(String firstName, String lastName) {
  m_firstName = firstName;
  m_lastName = lastName;
}

… to best:

public Person(String lastName) {
  init(null, lastName);
}
public Person(String firstName, String lastName) {
  init(firstName, lastName);
}
private void init(String firstName, String lastName) {
  m_firstName = null;
  m_lastName = lastName;
  if (null == m_firstName) {
    m_ssn = getSsn();
  }
}

Here is why the latter form is preferable:

• It doesn’t duplicate any code.
• It makes the initialization rules clear : "if no firstName was given, then ssn gets initialized".
• The signature of init gives a good indication of the various parameters this class needs to be initialized, while a multitude of overloaded constructors obscures this fact.