Sensibilité à la casse des noms de classes Java

Si l'on écrit deux classes Java publiques avec le même nom insensible à la casse dans des répertoires différents, les deux classes ne sont pas utilisables à l'exécution. (J'ai testé cela sur Windows, Mac et Linux avec plusieurs versions de la JVM HotSpot. Je ne serais pas surpris s'il y a d'autres JVM où elles sont utilisables simultanément. Par exemple, si je crée une classe nommée a et une autre nommée A comme ceci:

// lowercase/src/testcase/a.java
package testcase;
public class a {
    public static String myCase() {
        return "lower";
    }
}

// uppercase/src/testcase/A.java 
package testcase;
public class A {
    public static String myCase() {
        return "upper";
    }
}

Trois projets eclipse contenant le code ci-dessus sont site web.

Si j'essaie d'appeler myCase sur les deux classes comme ceci:

System.out.println(A.myCase());
System.out.println(a.myCase());

Le typechecker réussit, mais quand j'exécute le fichier de classe généré par le code directement ci-dessus, je reçois:

Exception dans le thread" main " java.lang.NoClassDefFoundError: testcase/A (mauvais nom: testcase/a)

En Java, les noms sont généralement sensibles à la casse. Certains systèmes de fichiers (par exemple Windows) sont insensibles à la casse, donc je ne suis pas surpris que le comportement ci-dessus se produise, mais il semble faux . Malheureusement, les spécifications Java sont curieusement non-engageantes sur les classes visibles. La Java Language Specification (JLS), Java SE 7 Edition (Section 6.6.1, page 166) dit:

Si une classe ou un type d'interface est déclaré public, alors il peut être consulté par tout code, à condition que l'Unité de compilation (§7.3) dans laquelle il est déclaré soit observable.

Dans la Section 7.3, le JLS définit l'observabilité d'une unité de compilation dans Termes extrêmement vagues:

Toutes les unités de compilation du paquet prédéfini java et de ses sous-paquets lang et io sont toujours observables. Pour tous les autres paquets, le système hôte détermine quelles unités de compilation sont observables .

La spécification de la machine virtuelle Java est également vague (Section 5.3.1):

Les étapes suivantes sont utilisées pour charger et ainsi créer la classe nonarray ou interface C désignée par [binaire nom] n Utilisation du chargeur de classe bootstrap [...] Sinon, la machine virtuelle Java passe L'argument N à une invocation de a méthode sur le chargeur de classe bootstrap pour rechercher une représentation supposée de C dans une plate-forme de manière dépendante.

Tout cela conduit à quatre questions par ordre décroissant d'importance:

1. Existe-t-il des garanties sur les classes qui sont chargeables par le(s) chargeur (s) de classe par défaut dans chaque JVM? En d'autres termes, puis-je implémenter un JVM VALIDE, mais dégénérée, qui ne chargera aucune classe sauf celles en java.lang et java.io?
2. S'il y a des garanties, le comportement dans l'exemple ci-dessus violent la garantie (c'est à dire le comportement d'un bug)?
3. est - il possible de charger le point D'Accès a et A simultanément? Est-ce que l'écriture d'un chargeur de classe personnalisé fonctionnerait?