Question

According to the JLS, it is valid syntax to have multiple classes in one file, so long as only a single class in the file is public. As I understand it, this is usually to allow small classes referred to only in a single file to be maintained within that file.

One area I’m not sure about is if other files in the same package are able to safely refer to that second class in the original file – by the scoping rules it would seem valid, but I’m not sure if it is a problem while compiling. I have seen it work quite frequently, but I’ve also been told by other developers on the project that there are occasional build issues finding the symbol in question after making changes elsewhere in the system. Is this setup of referring to package private classes embedded in other class’ files introducing some sort compilation order dependency into the process that is making the build fragile?

Answer 1

Yes, that should be absolutely fine – unless you’ve got a badly-configured build system, basically. You should probably be compiling all the source for the same package in one go anyway.

I can see it potentially causing a problem for some build systems which try to work out what needs recompiling – if they assume that the name of the source file matches the name of the resulting class, they could get confused here (even if you don’t have multiple classes in the same file) but that’s a tool problem rather than a language problem.

Note that normally if I have “small classes referred to only in a single file” I’d normally make them private static nested classes:

public class OuterClass
{
    // Normal code...

    // Only used within OuterClass
    private static class Foo
    {
    }
}

That’s cleaner (IMO) than giving something package-private access, if it’s really only intended to be used from a single class.