Regarding the command line flag: At this point we aren't ready for it, this change doesn't change the logic of building the TypeOracle at all - we've been using byte code generated from JDT for a couple of years now. This change just reorganizes TypeOracleMediator so I can feed it byte code directly without using CompilationState, mainly for testing.
http://gwt-code-reviews.appspot.com/1217801/diff/1/3 File dev/core/src/com/google/gwt/dev/javac/TypeOracleMediator.java (right): http://gwt-code-reviews.appspot.com/1217801/diff/1/3#newcode256 dev/core/src/com/google/gwt/dev/javac/TypeOracleMediator.java:256: On 2010/12/15 13:13:08, jbrosenberg wrote:
I'm not sure why this declaration is transient. Is TypeOracleMediator
ever
serialized?
I'm not sure either, although I did try to serialize TypeOracle once. I migrated the three transient variables into one context so I kept the transient qualifier.
Also (and this might just be a stylistic point), I think it might be
cleaner to
have the context passed down to the methods that need it, rather than
having it
be an instance variable. It might be more of an issue later if we try
to make
this multi-threaded (e.g. if multiple AddNewTypes happen
simultaneously). Of
course, this would not be the only thing that would need refactoring
for
thread-safety...
What I did I consider a compromise. Before there were 3 variables that were initialized for a single pass of addNewUnits() and then cleared at the end. I tried this before and it was pretty disruptive, but I think I'll give it another shot. http://gwt-code-reviews.appspot.com/1217801/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
