Folco (./1961) :
C'est dingue d'avoir des programmes comme ça. A plusieurs niveaux je trouve, fiabilité, maintenabilité, réutilisabilité, mais même au niveau des contributions dans un projet, trois lignes à la con qqpart et tout part en vrille. M'enfin, si "c'est bien", c'est que je dois pas comprendre les choses...

Il est évident que modifier des champs techniques comme cela, c'est pas une bonne idée et ça n'a pas le moindre intérêt pratique. Persone n'utiliserait ça dans un vrai programme.
Mais heureusement, là il s'agit de champs techniques qu'on est pas près d'utiliser sans faire exprès : il faut déjà savoir comment trouver le cache d'entiers car son accès n'est pas documenté. Ensuite il s'agit d'un champs privé dont on force son l'accès via setAccessible(true) : c'est le genre de manœuvre dont on sait que ça peut conduire a n'importe quoi sur un objet que l'on ne maîtrise pas. D'ailleurs cette manœuvre peut être interdite suivant les réglages de sécurité de la JVM.
En C ou au C++ ou il est très facile de faire des trucs incorrects avec la mémoire qui vont provoquer des comportements complètement inattendus sans s'en rendre compte.

PpHd (./1963) :
Déjà je ne comprends pas pourquoi java fournit un cache pour les entiers ?

C'est un des fâcheuses conséquences de l'auto-boxing qui permet de convertir automatiquement les types primitif (byte,short, int, ...) dans leur représentation équivalente sous forme d'objet (Byte,Short, Integer, ...). Pour éviter de ré-allouer systématiquement un objet pour chaque nombre, les objets correspondant aux nombres de -128 à 127 sont mis en cache.