Note that we are currently very closer to the first step of the externalization plan. We must only refactor 2 classes.
- Andrés Testi El viernes, 29 de noviembre de 2013 09:49:31 UTC-3, Andrés Testi escribió: > > > > El viernes, 29 de noviembre de 2013 00:51:25 UTC-3, Stephen Haberman > escribió: >> >> >> > implemented as a Java 8 compiler plugin (extension point) >> >> Interesting! I had not heard of these before: >> > > It's curious, I googled about Java 8 compiler plugins when RayC said that > you talked about a new code-gen feature in Java 8 > > >> It looks like these compiler plugins use "com.sun" packages, and are >> not a JSR, which AFAIK means no Eclipse IDE nor ecj support? What does >> that mean for your GWT-free deferred binding proposal? >> > > Yes, compiler plugins are an experimental feature, just like annotation > processing tool was in Java 5. I hope it will be formalized in future Java > versions. My plan is, as a first step, to externalize the Rebind annotation > and the Rebinding.create() method/class (a GWT-free replacement for > GWT.create()). These could be in an external package, like rebinding > (javax.rebinding would be an ideal :-P). Think about this API as a kind of > JSR330, a minimalistic API describing only what should be done, but nothing > about how to do it. Java 8 would implement it as a compiler plugin, GWT as > a compiler improvement (we already have it, just look at my github profile > :-P). > In a second step, we could externalize the generator API, may be in a > rebinding.generator package (again, an ideal would be > javax.rebinding.generator). GWT-free generators should use > javax.lang.model.type.*<http://docs.oracle.com/javase/7/docs/api/javax/lang/model/type/package-summary.html> > instead > of > com.google.gwt.core.ext.typeinfo.*<http://www.gwtproject.org/javadoc/latest/com/google/gwt/core/ext/typeinfo/package-summary.html> > . > In Java 8, these could be implemented as compiler plugins. In GWT, these > new generators would be a kind of wrappers for old generators. > In a third step, we could externalize the deferred binding configuration > (i.e. *.gwt.xml files). Annotations and/or guice like modules are > interesting options. > > >> That aside, I think a GWT-free deferred binding API would be pretty >> sexy. If one were starting GWT from scratch, I'd naively assert/agree >> that the problems of "build-time codegen" and "transpiling .java to .js" >> are orthogonal, and so should be tackled separately. Which would >> ideally make both implementations smaller/simpler/better. >> > > Yes, in and ideal world, I would like to have these compilation steps: > > JavaCode => JavaToJRibbleCompiler (Java 8 compiler plugin) => JRibbleCode > JRibbleCode => JRibbleToJavaScriptCompiler => JavaScriptCode > > As we live in a dirty corrupted world, we must replicate implementations. > For JRE/Android, we could implement it as Java 8 plugin/JDT extension (if > it exists)/whatever. In GWT, as a compiler enhancement (It already exists!). > > Anyway, it's really exciting to see your contributions, Andres, your >> write up was very good. > > > You are welcome, thanks for your feedback! > > - Andrés Testi > -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
