30

BookeldOr (./25) :
Bon, j'ai voulu faire un test avec ça :

public class DefineAdt {
    public enum Adt { CONS0, CONS1, CONS2 } ;

    public Adt get () {
	return Adt.CONS2 ;
    }
}


public class UseAdt {
    public static void main (String[] argv) {
	DefineAdt x = new DefineAdt () ;
	String value = "NOT SET";
	switch (x.get ()) {
	case CONS0 :
	    value = "CONS0" ;
	    break ;
	case CONS1 :
	    value = "CONS1" ;
	    break ;
	}
	System.out.println ("Got " + value) ;
    }
}


Mais ça compile nickel, sans warning, et affiche simplement "Got NOT SET", y'a des flags à mettre ?

benjamin@benjamin-laptop:~/Work/Stuff/java_adt$ java -version
java version "1.6.0_03"
Java(TM) SE Runtime Environment (build 1.6.0_03-b05)
Java HotSpot(TM) Server VM (build 1.6.0_03-b05, mixed mode)


edit : Oh, j'avais mal lu, J2SE5, moi j'ai le 6



En fait ton exemple compile/s'exécute très bien aussi avec le J2SE5 (VM 1.5.0_06) 1

Mon *problème* n'est pas d'être obligé de gérer tous les cas dans le switch (d'ailleurs on n'est effectivement pas obligé), mais simplement que pour le cas où justement toutes les valeurs d'un enum sont traitées explicitement, le code correspondant au default ne pourra jamais (?) être atteint, et que par conséquent c'est débile d'être obligé de le mettre pour que le compilateur considère que la variable value est initialisée dans tous les cas.

Pour moi c'est exactement comme s'il refusait de compiler
int a ;
if ( true )
  a= 1 ;
System.out.println(a) ;

en prétextant que a n'est pas initialisé dans tous les cas, et qu'on soit obligé de ruser en écrivant
int a ;
if ( true )
  a= 1 ;
else
  throw new AssertionError() ;
System.out.println(a) ;






1 Sous eclipse en fait il refuse de compiler parce que toutes les possibilités de l'enum ne sont pas gérées, mais je crois que c'est moi qui l'avait réglé comme ça y'a longtemps... Avec javac ça compile et s'exécute sans difficultés

31

Et bah c'est tout bête : pour se protéger du fait que Java permet la compilation séparée des classes. Ce qu'on voit à la compilation et au runtime n'est pas forcément la même chose.
MyEnum.java :

public enum MyEnum {EN1, EN2};

TestMyEnum.java :

public class TestMyEnum {
	public static void main(String[] args) {
		if (args.length != 1) return;
		MyEnum e = MyEnum.valueOf(args[0]);
	switch (e) {
			case EN1:
				System.out.println("EN1");
				break;
			case EN2:
				System.out.println("EN1");
				break;
			default:
				System.out.println("Oh No!");
		}
	}
}

Un test :
> javac *.java
> java TestMyEnum EN1
EN1 # rien d'excitant

Je modifie maintenant MyEnum.java en :
public enum MyEnum {EN1, EN2, EN3};
Je reteste :
> java TestMyEnum EN3
Oh No! # Tada

32

Ah ben oui, effectivement. Y'a intérêt à ne pas oublier l'AssertionError alors ! Merci bien smile


dehors

33

gcj -Os --main=TestMyEnum MyEnum.java TestMyEnum.java -o TestMyEnum et après je souhaite bonne chance pour modifier MyEnum.java dans ça. grin Mais GCJ est un peu sorti de mode maintenant qu'il y a IcedTea...
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

34

./31> Sauf que dans le cas du ./1, l'enum étant défini dans la même classe, le compilo pourrait un peu réfléchir, non ?
avatar
fabetal_ > Hier, je me suis fait monter par un pote
redangel > et en chevals, ça donne quoi?
Nil> OMG I think I'm gay

35

Non, la classe générée est TestMyEnum$MyEnum.class, elle est toujours modifiable. Et de toute façon avec les techniques d'instrumentation de bytecode, le compilateur ne veut pas avoir confiance.

36

En fait, c'est bien ce que j'essayais de tester avec mon ./25 en utilisant deux classes séparées, je ne savais pas qu'il était possible de modifier les classes locales séparément, c'est bon à savoir smile

Kevin > Aux dernières nouvelles, GCJ n'a jamais été "à la mode" grin </troll>
avatar
fabetal_ > Hier, je me suis fait monter par un pote
redangel > et en chevals, ça donne quoi?
Nil> OMG I think I'm gay