Enum declared outside class scope

Question

I went to this interview for a software developer position and they gave me a test with some corner-case-code situations, with usually 4 options to choose.
One of the questions had an enum declared outside the class scope, I promptly checked the "does not compile" answer and went ahead with the other questions. It was something like:

enum Colors {BLUE,RED,GREEN}

class Test {
    //other code, not really important with my question
}

This code actually compiles.
Besides the fact that an interview like this (might or) might not be useful to find out if one is a good developer, what worries me is: why would I declare an enum like this? Why I can only do this with enum? I did some testing and found out that it is visible inside the class, but not to other classes.

Sidenote: I scored really poor :P. I got the max on the theory but near the lowest possibile on the corner-case-code situations. I don't think I'll get the job.

Answer 1

It's not just enums. Enums are just special kinds of classes. In general you can have multiple classes declared in one file (as long as no two of them are public).

Answer 2

No, without an access modifier, the enum is package-private. This means it can only be used by classes in the same package. And you can't only do this with an enum, classes can also be made package-private.

More info: http://java.sun.com/docs/books/tutorial/java/javaOO/accesscontrol.html

Answer 3

Sometimes this idiom can be sensible - for example, imagine you have an UploadHandler class (or something like that) which can return a status from an upload. It seems quite feasible to me to implement this status as an enum - and since the enum (e.g. UploadStatus) clearly "belongs" to the UploadHandler class, it seems fine to declare it in the same source file. (This does assume of course that it only needs to be package-private - if it's truly public it would need to be declared in its own file, which would probably make sense if it's not an internal thing any more).

As it happens, in this case I would probably make it a static inner class to make the relationship more explicit. But declaring multiple classes in the same source file isn't always bad and can sometimes help readability by setting the expectation that this is a borderline-trivial, subsidiary class. (By the same token, I don't think classes like this should do anything particularly complex or unexpected.)