I agree there are more opportunities for ordinalization here, as suggested by Scott (e.g. allow references to $VALUES, or to static fields/methods on enum instances. I can pursue those further in a follow-on release.
http://gwt-code-reviews.appspot.com/1428808/diff/1/dev/core/src/com/google/gwt/dev/jjs/impl/EnumOrdinalizer.java File dev/core/src/com/google/gwt/dev/jjs/impl/EnumOrdinalizer.java (right): http://gwt-code-reviews.appspot.com/1428808/diff/1/dev/core/src/com/google/gwt/dev/jjs/impl/EnumOrdinalizer.java#newcode439 dev/core/src/com/google/gwt/dev/jjs/impl/EnumOrdinalizer.java:439: * method, which then gets inlined. In this case, black-listing references to VALUES is the mechanism for detecting calls to the values() method, which might have been inlined. But I guess you are suggesting we could allow calls to the values() method, and thus keep the $VALUES array around. I'll ponder as a future thing, I can see it could be useful (possibly in the rpc deserializers for enums). It would require changing how we modify the clinit as well during ordinalization. http://gwt-code-reviews.appspot.com/1428808/diff/1/dev/core/test/com/google/gwt/dev/jjs/impl/EnumOrdinalizerTest.java File dev/core/test/com/google/gwt/dev/jjs/impl/EnumOrdinalizerTest.java (left): http://gwt-code-reviews.appspot.com/1428808/diff/1/dev/core/test/com/google/gwt/dev/jjs/impl/EnumOrdinalizerTest.java#oldcode857 dev/core/test/com/google/gwt/dev/jjs/impl/EnumOrdinalizerTest.java:857: * a program. Yes, actually it is now, and I'm not sure what changed the behavior, but programs with single enums, at least within this test framework, do allow ordinalization. I suspect it could be due to changes in JavaAstConstructor.java (more accurate usage of jsni methods, which prevent some inlining in the java AST). http://gwt-code-reviews.appspot.com/1428808/diff/1/dev/core/test/com/google/gwt/dev/jjs/impl/EnumOrdinalizerTest.java File dev/core/test/com/google/gwt/dev/jjs/impl/EnumOrdinalizerTest.java (right): http://gwt-code-reviews.appspot.com/1428808/diff/1/dev/core/test/com/google/gwt/dev/jjs/impl/EnumOrdinalizerTest.java#newcode251 dev/core/test/com/google/gwt/dev/jjs/impl/EnumOrdinalizerTest.java:251: assertTrue(tracker.isOrdinalized("test.EntryPoint$Fruit")); Tracker also keeps track of stats for ordinalization, and allows a report to be generated at the end of a compile with an optional (currently undocumented) flag. It keeps track of which optimization passes resulted in which ordinalizations, keeps track of which sourceInfo line number caused an enum to be black-listed. And the overall stats for how many enums are in the app. Going forward, the idea is to have the tracker data generated as part of the soyc report. I think of it as a model for what can be done to provide greater visibility into other optimizers as well. http://gwt-code-reviews.appspot.com/1428808/diff/1/dev/core/test/com/google/gwt/dev/jjs/impl/EnumOrdinalizerTest.java#newcode273 dev/core/test/com/google/gwt/dev/jjs/impl/EnumOrdinalizerTest.java:273: "String y = fruit.staticField;"); Interesting, I guess if fruit is null (or could be null), then ordinalization would have been blocked anyway (and I think the possibility that fruit is null is the only semantic difference from the Fruit.staticField case). So ordinalization could proceed in this case, it would require code to convert fruit.staticField to Fruit.staticField, as part of the ordinalization process. http://gwt-code-reviews.appspot.com/1428808/diff/1/dev/core/test/com/google/gwt/dev/jjs/impl/EnumOrdinalizerTest.java#newcode287 dev/core/test/com/google/gwt/dev/jjs/impl/EnumOrdinalizerTest.java:287: "int y = fruit.staticMethod();"); yep http://gwt-code-reviews.appspot.com/1428808/diff/1/dev/core/test/com/google/gwt/dev/jjs/impl/EnumOrdinalizerTest.java#newcode456 dev/core/test/com/google/gwt/dev/jjs/impl/EnumOrdinalizerTest.java:456: "}"); good catch, I've updated the test for this. http://gwt-code-reviews.appspot.com/1428808/ -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
