À l'aide de l'Enum valeur ordinale en cas de commutateur déclaration

C'est la façon dont est fait, à condition d'avoir un sérialisé ordinale quelque part, quelque part. La manière habituelle de persistance d'un enum est par son nom, pas ordinale. Aussi, vous ne devez pas utiliser ordinale dans des circonstances normales, à moins d'essayer de mettre en place quelque chose comme EnumMap/Set. Bien sûr, l'enum peut être juste un port de C pareil les choses et de traiter avec l'inévitable int, a besoin d'une transformation de l'Enum objet.

Suffit d'utiliser Enum.values() pour obtenir un tableau commandé par ordinal(), puisque le tableau est cloné à chaque fois, en gardant une ref vers est ok.

enum E{
 A, B, C...   
}

final static E[] vals = E.values();//copy the values(), calling values() clones the array
boolean f(int variable){
  switch(vals[variable]){
  case A:
...
  case B:
...
//break;
  default:
...
   }
}

---

Viens de remarquer que vous devez seulement le vrai et le faux, qui est un Ensemble de type de comportement. Vous pouvez utiliser java.util.EnumSet ou un simple long, si elle se sent courageux (et ne pas avoir plus de 64 enum constantes). par exemple:

private static <E extends Enum> long ord(E e){
  return 1L<<e.ordinal();
}

static final long positiveSet = ord(E.A)+ord(E.B);
boolean f(int ordinal){
  return 0!=(positiveSet&(1L<<ordinal));
}

OriginalL'auteur

La réponse des cibles @Riaan commentaire sur la constante vs méthode des énumérations et des raisons de performances et il ne répond directement à l'OP question, de sorte qu'il peut être considéré comme du bruit, je suppose.
Cependant, je crois que c'est une question importante pour comprendre comment les rouages.

J'ai pris de l'indice de référence hors de son exemple et de l'améliorer afin de supprimer la collecte des ordures et de la chaîne de création qui prend plus de 90% du temps d'exécution. Ajouté phase chaude pour assurer hotspot effectivement compile les méthodes.

Il y a un peu plus, l'indice de référence est effectivement callsite test. L'optimisation pour les callsites sont assez différents pour 1, pour 2, pour un peu plus et de plus en plus. Un callsite est une invocation abstraite (ou simplement remplacée) méthode.

Ci-dessous le test avec 6 enums constantes:

package t1;
public class ZEnums {
public enum MyEnum {
A { boolean getBooleanValue(){ return true; }},
B { boolean getBooleanValue(){ return true; }},
C { boolean getBooleanValue(){ return false; }},
D { boolean getBooleanValue(){ return false; }},
E { boolean getBooleanValue(){ return false; }},
F { boolean getBooleanValue(){ return false; }}, 
;
abstract boolean getBooleanValue();
}
public enum MyEnumAlt {
A (true), 
B (true),
C (false),
D (false),
E (false),
F (false),
;
private final boolean isTrue;
MyEnumAlt( boolean isTrue){ this.isTrue = isTrue; }
boolean getBooleanValue(){ return isTrue; };
}
public static void main(String[] args) {
log("Warming up...");
//10k iterations won't do since not all paths for MyEnum are invoked 10k (default) times to warrant compilations 
long warmum = testEnum(100000 )+ testAlt(100000)+testEnum(100000 )+ testAlt(100000);
log("Warm up: %d", warmum);     
//no info from +XX:+PrintCompilation below this one, or the test is invalid
testMain();
}
public static void testMain() {
int iterations = (int)4e7;
log("Testing %d iterations%n", iterations);
log("====");
log("Testing with Overridden method...");       
System.gc();
{
long start = System.currentTimeMillis();
long len = 0;
len = testEnum(iterations);
long time = System.currentTimeMillis()-start;
log("Overridden method version took %dms, length: %d ", time, len);
}
////////////
System.gc();
{
log("Testing with Constant in c-tor... ");
long start = System.currentTimeMillis();
long len = testAlt(iterations);
long time = System.currentTimeMillis()-start;
log("Constant in c-tor version took %dms, length: %d ", time, len);
}
}
private static long testEnum(int iterations) {
long len = 0;
for(int i=0; i<iterations; i++){
MyEnum tmpEnum = MyEnum.A;
if(i%3==0){ tmpEnum = MyEnum.A;        
}else if(i%4==0){ tmpEnum = MyEnum.B;
}else if(i%5==0){ tmpEnum = MyEnum.C;
}else if(i%6==0){ tmpEnum = MyEnum.D;
}else if(i%6==0){ tmpEnum = MyEnum.E;
}else{ tmpEnum = MyEnum.F; 
}
String tmp = tmpEnum.getBooleanValue()?"XXX":"ABCDE";
len+=tmp.length();
}
return len;
}
private static long testAlt(int iterations) {
long len =0;
for(int i=0; i<iterations; i++){
MyEnumAlt tmpEnum = MyEnumAlt.A;
if(i%3==0){ tmpEnum = MyEnumAlt.A;
}else if(i%4==0){ tmpEnum = MyEnumAlt.B;
}else if(i%5==0){ tmpEnum = MyEnumAlt.C;
}else if(i%6==0){ tmpEnum = MyEnumAlt.D;
}else if(i%6==0){ tmpEnum = MyEnumAlt.E;
}else{ tmpEnum = MyEnumAlt.F; 
}
String tmp = tmpEnum.getBooleanValue()?"XXX":"ABCDE";
len+=tmp.length();
}
return len;
}
static void log(String msg, Object... params){ 
String s = params.length>0?String.format(msg, params):msg;
System.out.printf("%tH:%<tM:%<tS.%<tL %s%n", new Long(System.currentTimeMillis()), s);
}
}

21:08:46.685 l'échauffement... 
148 1% t1.ZEnums::testEnum @ 7 (125 octets) 
150 1 t1.ZEnums$MyEnum$6::getBooleanValue (2 octets) 
152 2 t1.ZEnums$MyEnum$1::getBooleanValue (2 octets) 
154 3 t1.ZEnums$MyEnum$2::getBooleanValue (2 octets) 
155 4 t1.ZEnums$MyEnum$3::getBooleanValue (2 octets) 
158 2% t1.ZEnums::testAlt @ 7 (125 octets) 
162 5 t1.ZEnums::testEnum (125 octets) 
164 6 t1.ZEnums::testAlt (125 octets) 
21:08:46.716 échauffement: 1600000 
21:08:46.716 Tests 40000000 itérations 
21:08:46.716 ==== 
21:08:46.716 Tests avec la méthode de remplacement... 
21:08:47.513 méthode de remplacement de la version a pris 781ms, longueur: 160000000 
21:08:47.513 Test avec la Constante c-tor... 
21:08:48.138 Constant de c-tor version a pris 625ms, longueur: 160000000 

Le code a été exécuté w/-server -XX:+PrintCompilation options.
La différence n'est pas énorme, bien sûr. Cependant ce n'est pas la question intéressante. Si vous testez la version avec 2 enum constantes cependant, le résultat peut être sensiblement différente. Pour les 2 sites d'appel le compilateur génère le code par inlinining la méthode en question. Dans le test ci-dessus qui permettrait d'éliminer l'intégralité de l'appel à booleanValue et peut même faire exécuter le test en O(1).

Le plus drôle, cependant, est de passer de 2 à 3 enum constantes lorsque le compilateur commence à utiliser inline caches et alors la constante, et WOW magie le tout change.

---

La ligne de fond est: la bonne référence est vraiment difficile et implique une certaine connaissance de la façon dont le JIT compile, lorsque le GC peut être un problème (que ce soit de la supprimer ou de l'embrasser) et ainsi de suite.


Liens:

• Benchmakrs sur JavaOne
• Comment ne PAS Écrire Un Microbenchmark

OriginalL'auteur

Ce que vous demandez sans doute:
Si vous avez besoin de l'interrupteur dans une méthode dans l'enum lui-même:

switch ( this )
{
case A:
return true;
case B:
return true;
default:
return false;
}

Et dans une classe différente:

switch ( variable )  //Variable of type myEnum
{
case A:
return true;
case B:
return true;
default:
return false;
}

Il est facile d'oublier de mettre à jour les instructions de commutation si vous ajoutez un autre enum, donc un meilleur pari serait de placer des méthodes de ce genre dans l'enum lui-même et de l'utilisation de la constante spécifique de la méthode d'opération:

public enum MyEnum
A { boolean getBooleanValue(){ return true; },
B { boolean getBooleanValue(){ return true; },
C { boolean getBooleanValue(){ return false; };
abstract boolean getBooleanValue();
}

De cette façon, si vous ajoutez une nouvelle valeur d'enum, le compilateur va vous rappeler de déclarer la getBooleanValue méthode et il vous suffit d'utiliser A.getBooleanValue(); partout où vous en avez besoin.

Comme il a été souligné dans les commentaires, une autre option est ceci:

public enum MyEnumAlt {
A (true), 
B (true),
C (false);
private final boolean isTrue;
MyEnumAlt( boolean isTrue){ this.isTrue = isTrue; }
boolean getBooleanValue(){ return isTrue; };
}

C'est une question de préférence et varient en fonction de la situation spécifique. Si vous êtes tout simplement de retourner une valeur pour chaque enum, le constructeur version est plausible, mais je trouve ça moins lisible. Préoccupations au cours de cette exécution mieux est sans fondement comme vous pouvez le voir par les tests:

public void testMain() {
System.out.println("Testing with constructor: ");
long start = System.currentTimeMillis();
for(int i=0; i<1000*1000; i++){
MyEnum tmpEnum = null;
if(i%3==0){ tmpEnum = MyEnum.A;
}else if(i%4==0){ tmpEnum = MyEnum.B;
}else{ tmpEnum = MyEnum.C; }
String tmp = Integer.toString(i)+" "+tmpEnum.getBooleanValue();
}
long time = System.currentTimeMillis()-start;
System.out.println("Constructor version took "+time);
System.out.println("Testing with Constant specific method implementation: ");
long start2 = System.currentTimeMillis();
for(int i=0; i<1000*1000; i++){
MyEnumAlt tmpEnum2 = null;
if(i%3==0){ tmpEnum2 = MyEnumAlt.A;
}else if(i%4==0){ tmpEnum2 = MyEnumAlt.B;
}else{ tmpEnum2 = MyEnumAlt.C; }
String tmp2 = Integer.toString(i)+" "+tmpEnum2.getBooleanValue();
}
long time2 = System.currentTimeMillis()-start2;
System.out.println("Constant specific method version took "+time2);
}

OriginalL'auteur Riaan Cornelius