To "write once run anywhere" it is necessary to have a defined mapping from
class name to the file name that will contain the class. The absence of a
strategy to address this issue results in unresolveable bugs and
interoperability failure on all platforms.

The mapping needs to be specified, rather than a choice of the implementation, in order for implementations on the same platform to be interoperable.

Some examples of the problems that need to be solved by a platform-specific specfication of the class name to file name mapping:

(1) Win32 and liks platforms are not case sensitive, while Java
identifiers are.
(2) The unix limit on the total length of a filename is much
shorter than the limit on the length of a qualified Java identifier.
(3) Java identifiers include unicode characters; none of the target
file systems do.

A further problem arises because the tools we provide to produce jar files
may have to be aware of this mapping to undo it.

Here is a sample program which the available specifications do not
give enough information to tell a compiler how to behave:

frog$ cat -n T.java
     1 /** doc for T */
     2 public class T {
     3 /** doc for id\u0ca0\u0ca1 */
     4 public static class id\u0ca0\u0ca1 {
     5 public void f() {}
     6 }
     7 /** doc for id\u0ca1\u0ca0 */
     8 public static class id\u0ca1\u0ca0 {
     9 public void g() {}
    10 }
    11 public static void main(String[] args) {
    12 new id\u0ca0\u0ca1().f();
    13 new id\u0ca1\u0ca0().g();
    14 }
    15 }
frog$

One suggestion would be to use a cryptographically strong hash function to
hash the class name to 256 bits and encode those bits to a filename that
is acceptable on all platforms.

neal.gafter@Eng 2001-03-05