Facebook Twitter MySpace Stumble Reddit Delicious More...

The Java Specialists' Newsletter
Issue 0802003-10-13 Category: Language Java version:

Welcome to the 80th edition of The Java(tm) Specialists' Newsletter. There is a saying in the English language: It never rains, but it pours. This means that either I am unbelievably busy, or I have time to write several newsletters at once. So, at the moment the sun is shining and I have the luxury of being able to relax with my hobby of writing newsletters.

The idea in this newsletter was prompted by a professor who attended my Java classes in China. I was talking about Java only allowing one public class per file, and he asked: "What about inner classes?" The resulting discussion ended up in this newsletter. Technically, it is possible to have lots of public static inner classes and use them as normal public classes, but I would strongly recommend against that.

Many Public Classes in One File

Some of the most common complaints that I hear about Java are these:

1. Java is slow.
2. You cannot make an "exe".
3. Every Java class has to be in a separate file.

I sometimes struggle to take these complaints seriously. Here are my standard answers:

1. The speed of execution depends greatly on the skill of the developer. I have heard of real-world applications where the Java application was faster than an equivalent C++ application. For number crunching, you will probably do better with C++, but for general applications, the advantages of Java outweigh the slight performance degradation that you may experience.
2. There are several compilers available that will produce an "exe" from Java classes. Some of these are fairly powerful. In a future newsletter we are planning to review some of them.
3. Usually my answer here is that it makes source control easier when you have a separate file for each class. As described in my newsletter "Once Upon an Oak", a reason for this restriction is to make the compilation process faster. This newsletter will demonstrate an approach where you can have several public classes in one .java file.

Before I show you this approach, please understand that I do not endorse writing classes in this way. I prefer using one file per class, even for non-public classes. I once had to work on a class that had about one hundred inner classes. It was a nightmare.

We start by defining package com.maxoft.tjsn which contains class All. This class contains all the classes as public static inner classes.

package com.maxoft.tjsn;

public class All {
  public static class A {
    public void f() {}
  }
  public static class B {
    public void g() {}
  }
  public static class C {
    public void h() {}
  }
  public static class D extends A {
    public void f() {}
  }
  public static class E {
    public void jump() {}
  }
  public static class F {
    private final E e = new E();
    public void skip() {
      e.jump();
    }
  }
}
  

It is important that the class is in a package, as we will see just now. Next we show the first approach of how we could now use classes A,B,C,etc.

import com.maxoft.tjsn.All;

public class AllTest1 {
  public static void main(String[] args) {
    All.A a = new All.A();
    All.B b = new All.B();
    All.C c = new All.C();
    All.D d = new All.D();
    All.E e = new All.E();
    All.F f = new All.F();
  }
}
  

Admittedly, this is ugly. However, there is another approach. We can import the inner classes directly, like so:

import com.maxoft.tjsn.All.*;

public class AllTest2 {
  public static void main(String[] args) {
    A a = new A();
    B b = new B();
    C c = new C();
    D d = new D();
    E e = new E();
    F f = new F();
  }
}
  

This is now a lot prettier than saying All.A and All.B. I think it only works if the class is in a package. This should not be a restriction since classes should be in packages anyway.

But, rather don't do this...

Here are some reasons why you should rather not do this: First, it is going to result in large source files. Second, all members of the classes will effectively only have package access protection. This can easily result in spaghetti code that would make an Italian Mama proud. Third, most IDEs will struggle to support this well. Fourth, I seem to recall that some compilers cannot compile importing of inner classes.

Kind regards

Heinz

Language Articles Related Java Course Discuss at The Java Specialist Club