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