JAVA / Scala Multi Class in One Source File

Java:

That is not correct and the basic rules are different.

First let me give you a counter example:

// This is the content of X.java
class Y {
  void i() { System.out.println("!!!"); }
}
class Z {
  public static void main(String[] args) {
    new Y().i();
  }
}

First run 

javac X.java

 and then run 

java Z

. As you can see, the code runs perfectly fine and prints "!!!\n". 

The actual rules are very simple, and apply to many situations including your example:

Rule 1
Classes can have either package (default) or public visibility:

// A public class.
public class X {}

// A package-visible class.
class X{}

Rule 2
Classes that are public must be implemented in a .java source file with the same name, but non-public classes can reside in source files with another name.

// This is the content of X.java
// This is a non-public class and can be declared inside X.java
class Y {}
// This is a public class and should be declared inside Z.java
public class Z {}  // You'll get an error for this.

Rule 3
When you run a class using java, the main method of that class should be public and static with the following prototype:

public static void main(String[] args) { ... }

Just remember these very simple, intuitive rules and you're all set.

Best Practices
The best practice however is to put each class in the its own source file regardless of its visibility, except for non-public classes that are used only by classes in one source file. The reason behind this practice is that it makes it super easy for developers to lookup a class declaration just by browsing folders and looking for specific file names.

Scala:

Files

As a rule, files should contain a single logical compilation unit. By “logical” I mean a class, trait or object. One exception to this guideline is for classes or traits which have companion objects. Companion objects should be grouped with their corresponding class or trait in the same file. These files should be named according to the class, trait or object they contain:

package com.novell.coolness
class Inbox { ... }
// companion object
object Inbox { ... }

These compilation units should be placed within a file named Inbox.scala within thecom/novell/coolness directory. In short, the Java file naming and positioning conventions should be preferred, despite the fact that Scala allows for greater flexibility in this regard.

Multi-Unit Files

Despite what was said above, there are some important situations which warrant the inclusion of multiple compilation units within a single file. One common example is that of a sealed trait and several sub-classes (often emulating the ADT language feature available in functional languages):

sealed trait Option[+A]
case class Some[A](a: A) extends Option[A]
case object None extends Option[Nothing]

Because of the nature of sealed superclasses (and traits), all subtypes must be included in the same file. Thus, such a situation definitely qualifies as an instance where the preference for single-unit files should be ignored.

Another case is when multiple classes logically form a single, cohesive group, sharing concepts to the point where maintenance is greatly served by containing them within a single file. These situations are harder to predict than the aforementioned sealed supertype exception. Generally speaking, if it is easier to perform long-term maintenance and development on several units in a single file rather than spread across multiple, then such an organizational strategy should be preferred for these classes. However, keep in mind that when multiple units are contained within a single file, it is often more difficult to find specific units when it comes time to make changes.

All multi-unit files should be given camelCase names with a lower-case first letter. This is a very important convention. It differentiates multi- from single-unit files, greatly easing the process of finding declarations. These filenames may be based upon a significant type which they contain (e.g.option.scala for the example above), or may be descriptive of the logical property shared by all units within (e.g. ast.scala).

One difference between Scala and Java is that whereas Java requires you
to put a public class in a file named after the class—for example, you’d
put class SpeedRacer in file SpeedRacer.java—in Scala, you can name
.scala files anything you want, no matter what Scala classes or code you
put in them. In general in the case of non-scripts, however, it is recommended
style to name files after the classes they contain as is done in Java, so that
programmers can more easily locate classes by looking at file names.