FWIW, that is not a Maven-ism that is actually inherent to Java (the language and the runtime)[1]. Including case-sensitivity for the filename, which was an especially bold choice for Sun to make back in 1990, although I guess they're all "we'll sell more Solaris workstations!!1" or something
For example:
$ mkdir foo
$ cd foo
$ printf 'package jimbo;\npublic class Foo2 {}\n' > fred.java
$ javac -g -d . fred.java
fred.java:2: error: class Foo2 is public, should be declared in a file named Foo2.java
public class Foo2 {}
^
1 error
The only exception that I'm aware of is that inner classes don't have to live in their own filename (given that they're more or less property of the owning class)
The Maven-ism that I'm aware of is the by default structure of {src/main/java, src/main/resources, src/test/java, src/test/resources} but (of course) those are customizable via the pom.xml if it jams up your project that much
Package hierarchies are used during class loading from a directory, but there is nothing in the spec that mandates that kind of directory structure for the source code. Your link only uses the word "might", not "must".
For example:
The only exception that I'm aware of is that inner classes don't have to live in their own filename (given that they're more or less property of the owning class)The Maven-ism that I'm aware of is the by default structure of {src/main/java, src/main/resources, src/test/java, src/test/resources} but (of course) those are customizable via the pom.xml if it jams up your project that much
1: https://docs.oracle.com/javase/specs/jls/se6/html/packages.h... (it's the oldest spec version they still link)