Skip to main content

Multiple public classes/interfaces in a single file

22 replies [Last post]
calum
Offline
Joined: 2003-06-12
Points: 0

Why can't we have multiple public classes within a single source file, but make the restriction for main() ensure that it must be in the same class as the filename.

This is good when you have small bean-like classes and you're using composition.

i.e.
-----------One SourceFile---------
public class Holder {
....
//contains HolderItems
}

public class HolderItem{
//contains DataItems
}

public class DataItem{
...
}
-----------One SourceFile---------

This would make sense as the composition hierarchy is within the same source file, so make the understanding easier. But would allow you to create a DataItem outside of the package like any normal public class

--Calum

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
patrikbeno
Offline
Joined: 2004-10-11
Points: 0

> We do have one thing in Java that maybe helpful,
> packages. What if were allowed to map a package to a
> single file? Have a package extention like
> java.lang.package file?

Please not that since Java 5 we already have file package-info.java (in your example it would be java/lang/package-info.java) :-)
It is intended to be used for package-level javadoc comments and annotations. it's name does not fit best for public classes but it may work. Or we can introduce that package.java file that would be allowed to contain arbitrary number of public classes.

So, basically, i don't see any real problem with this (excluding possible class name conflict which can be resolved). It just a matter of rules, in this case, one more rule. It would be feasible.

However, I don't feel any great need for this. Do you?

kcpeppe
Offline
Joined: 2003-06-15
Points: 0

>
> However, I don't feel any great need for this. Do you?

nope!

patrikbeno
Offline
Joined: 2004-10-11
Points: 0

I can't believe it, we AGREE with each other ;-)

mthornton
Offline
Joined: 2003-06-10
Points: 0

For an example of a nested class (what was once confusingly called a static inner class) see java.awt.geom.Point2D.Double

You create an instance of this:

Point2D p = new Point2D.Double(1.5, 3.2);

One of the things I like about Java is that you always know the name of the source file containing a given public class --- unlike in C++ where you can put the implementation of a class in a file of any name that takes your fancy.

behrangsa
Offline
Joined: 2003-09-14
Points: 0

I have always loved the fact that Java forces to have at most one public class per file. This helps finding source code for classes way too easier...

tackline
Offline
Joined: 2003-06-19
Points: 0

Indeed. I'd like to see Mustang give a warning for
type name not matching filename. In Dolphin it should be an error.

Where does java.awt.LightweightDispatcher live?

patrikbeno
Offline
Joined: 2004-10-11
Points: 0

compiler gives an error if public class is not the file with the matching name. non-public classes are not restricted and this is good. Your LightweightDispatcher lives where it lives because it is not public class.

wingetr
Offline
Joined: 2004-01-19
Points: 0

The current system makes it easier on the compiler. Personally, I even put package-private classes into their own source files.

zander
Offline
Joined: 2003-06-13
Points: 0

I'm basically unconvinced why its a bad thing to have 3 files for 3 classes.

If you want better understanding by having them all 3 on your screen at ones; use a better text-editor that can open 3 files in a split screen..

I'm inclined to conclude you are trying to solve the wrong problem here.

patrikbeno
Offline
Joined: 2004-10-11
Points: 0

Truth is that it is unnecesary overhead to create 100 files for 100 small classes like [i]class MyClass { public int i; }[/i] (exaggerating ;-))

Too many files can be a curse: too many windows, too many I/O operations (compilation, version control, etc).
However, separate file is only needed for public classes and for others, you are free to choose.

[b]The rule "public class in a dedicated equally named file" is the good and reasonable rule. I would not revoke it.[/b]

zander
Offline
Joined: 2003-06-13
Points: 0

> Too many files can be a curse: too many windows, too
> many I/O operations (compilation, version control,
> etc).
> However, separate file is only needed for public
> classes and for others, you are free to choose.

I'm falling back to my previous claim that this problem is not a Java problem but one of your build environment.

There are filesystems that allow opening 100 small files (100 bytes) just as fast as 1 bigger file (10kb). (ReiserFs for example)
There are many editors that allow split panel (vim -o *java)
ant and javac compile all files in one go, and having 1 change makes compiling small files even faster.
I doubt that cvs or subversion or whatever is going to have ANY problem with lots of files. If you use a good tool to manage these files, neither will you. (a commandline will solve it)

So, I fully agree with you that the public class rule means a filename is a good rule.
If anyone has problems with that rule it feels to me that he should solve the problems with many files, nothing else.

kcpeppe
Offline
Joined: 2003-06-15
Points: 0

> > Too many files can be a curse: too many windows,
> too
> > many I/O operations (compilation, version control,
> > etc).
> > However, separate file is only needed for public
> > classes and for others, you are free to choose.
>
> I'm falling back to my previous claim that this
> problem is not a Java problem but one of your build
> environment.

Humm, I'd like to suggest another possibility.. it is how Java utilizes your environment.

It is true that many files are a curse in windows. It is also true that we all don't get to pick and choose our file systems. Thus it does seem like there are some improvements that could be had in this topic. That said, of all the other models that I've worked in, I can't think of one that was not without some other problems that made that solution more desireable than what we have.

We do have one thing in Java that maybe helpful, packages. What if were allowed to map a package to a single file? Have a package extention like java.lang.package file? I can think of a number of disadvantages but I'll let Patick poke holes in the idea... he's good at it ;)

mthornton
Offline
Joined: 2003-06-10
Points: 0

I can't really see any worthwhile efficiency savings to be had from reducing the number of files. If you really must, how about just packing your source into a zip file? That way you can have as many classes as you like in a single file. You just need an IDE that will compile from source in a zip file without unpacking it.

yod
Offline
Joined: 2004-10-20
Points: 0

Source analysis (in compilation, in IDEs) would possibly become slower. Since a public class could be anywhere, all source files would be needed to be parsed to solve import statements.

mthornton
Offline
Joined: 2003-06-10
Points: 0

If you want more than one public class in the same file use nested classes.

calum
Offline
Joined: 2003-06-12
Points: 0

Yes but this force you to use the follwing syntax

Outer.Inner obj = new Outer().new Inner(...)
or
Outer.Inner obj = outerInstance.new Inner(...)

And that is just horrible.
Thus allow me to do

Outer.Inner obj = new Outer().Inner();
or
Outer.Inner obj = new outerInstance.Inner();

or the best of the bunch

Inner obj = new Inner();
...without needing Inner in it's own source file,i.e. even if the source is contained within Outer.java

--Calum

vhi
Offline
Joined: 2004-10-11
Points: 0

If the Inner is a static inner-class, then you do not have to bind it to an instance of the outer class. And you can do the Inner obj = new Inner();

patrikbeno
Offline
Joined: 2004-10-11
Points: 0

AFAIK, [b]inner[/b] class always exists within outer instance. It even has access to the members of the outer instance. You cannot have static inner class.

What you describe is [b]nested[/b] class. You declare nested class using 'static' keyword. It is a standalone class with no links whatsoever to the surrounding class. Surrounding class just provides a 'namespace'.

So much for terminology :-)

afishionado
Offline
Joined: 2004-05-26
Points: 0

A static inner class is bound to the outer [b]class[/b] itself, rather than an instance of the outer class.

As a result, it can access private [b]static[/b] methods/variables of the outer class.

I think that if it is passed an instance of the outer class, it can access the private instance variables of that object as well.

patrikbeno
Offline
Joined: 2004-10-11
Points: 0

The point is that [b]inner[/b] class requires outer instance, that's why it is inner. If you make it [b]static[/b] it is no longer inner class, it becomes [b]nested[/b].

However, you are right: both inner & nested classes have full access to the outer/surrounding class, they are inherent part of it. It is because outer/surrounding class declared them and therefore they are considered trusted.

it is also noteworthy that you cannot inhibit one inner/nested class from accessing other inner/nested class' private fields (within the same outer/surrounding class)

callen982
Offline
Joined: 2004-01-14
Points: 0

To use the definitions in [i]The Java Language Specification, Second Edition[/i], any class that is enclosed in another class is a [b]nested[/b] class. A non-static nested class is an [b]inner[/b] class.

patrikbeno
Offline
Joined: 2004-10-11
Points: 0

That's it, thanks for looking it up in JLS.
So every inner class is a nested class, but not every nested class can be inner.
And something like [b]static inner class[/b] DOES NOT exist.