Home of The JavaSpecialists' Newsletter

080Many Public Classes in One File

Posted: 2003-10-13Category: LanguageJava Version: Dr. Heinz M. Kabutz



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.

Birthday and Anniversary Special: Since the 30th November 2017 is the 17th anniversary of our newsletter and my birthday is coming up on the 4th December, we are giving away a 30% discount on our new Data Structures for Java 9 Course (Late 2017 Edition). Whether you are a seasoned Java programmer or you just want to get ready for your next job interview, this course will help you. Besides detailed lectures, the course has over 130 questions that will help you discover what you missed.

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() {

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



Related Articles

Browse the Newsletter Archive

About the Author


Java Champion, author of the Javaspecialists Newsletter, conference speaking regular... About Heinz

Java Training

We deliver relevant courses, by top Java developers to produce more resourceful and efficient programmers within their organisations.

Java Consulting

Nobody ever wants to call a Java performance consultant, but with first-hand experience repairing and improving commercial Java applications - JavaSpecialists are a good place to start...

Threading Emergency?

If your system is down, we will review it for 15 minutes and give you our findings for just 1 € without any obligation.