On Wednesday, May 24, 2017 at 3:41:13 AM UTC-4, Thomas Broyer wrote:
>
> It indeed does use <source> and <super-source> from gwt.xml files to
> subset/superset the compilation classpath, but it does *not* take the
> EntryPoint into consideration; not at that point.
> First generators are run and generate code, then only things are optimized.
> So a pre-compilation analysis would "only" have to possibly subset the
> compilation classpath (though ideally you'd separate out what's not
> "translatable" and just not put it in the classpath at all; actually,
> afaik, j2cl has a similar "interface" as javac where you explicitly list
> the files to translate, so that's work that'll have to be done anyway,
> though GWT 3 might do it for you, keeping the gwt.xml files; this is part
> of the "we don't know what GWT 3 will look like" bucket).
> That being said, if you agree to whitelist classes in annotations on the
> RemoteService interfaces (similar to the @ExtraTypes of RequestFactory),
> then this processing step could possibly be an annotation processor rather
> than a separate pre-processing tool/step.
>
Well, as I noted earlier... to efficiently generate code and not have to
generate it for the whole world, I need to perform reachability analysis
before I generate it, which means before J2CL does its thing. Hook would,
thus, have to be in the appropriate place. As for whitelisting, the goal is
to do *at least as good as GWT RPC* and better with whitelisting.
Specifically, no whitelisting would be needed for the apparent, declared
types of classes that are observed communicated. This can be determined
with no additional annotations.I can do even better because I can analyze
code and see which subtypes of those may be possible as well and include
those automatically. Whitelisting comes in addition to that to state
possible subtypes from the code that isn't analyzed - e.g. the server code.
> Tooling can help here (you can already do that with GWT 2.x by calling
> ModuleDefLoader/ModuleDef in your code; and those kind of use-cases might
> become a good reason to provide a CLI tool producing a list of files or
> patterns out of a gwt.xml that you could feed to other tools; see however
> the comment above about "we don't know what GWT 3 will look like")
>
That's GWT 2.x ... I don't know what will survive in GWT 3.0 or in what
form. I also don't need any of this in 2.x.
> IDEs ("on save" actions), build tools (e.g. Gradle continuous build
> <https://docs.gradle.org/current/userguide/continuous_build.html>) or
> other watchers (watchman, modd, etc.) can help here.
> Though if you change any class that's shared with your server, you'd have
> to redeploy the webapp too (with current DevMode's embedded server, that
> means clicking the "reload server" button); so possibly that step would
> better be manually triggered (YMMV)
>
> Yes, that is what I noted but I also explained what this does to the
experience. Also what will happen if someone clicks to refresh while the
code is being regenerated? Not nice.
> As said previously, one criticism of Google against the current GWT 2.x
> architecture is that it "does too much", and part of the j2cl effort is to
> split things into smaller and simpler tools, replacing some of them by
> existing tools, and (from Google's point of view) leveraging their build
> system (that promotes small compilation targets and provides fast
> incremental builds and continuous rebuilds – the latter is not yet
> opensourced into Bazel afaict).
>
"Too much" is relative. I agree that it did too much for most, because it
always did all. But if something saves you time (via reduced development
effort, resulting manually written code size, etc) or is a downright
compatibility issue, then it isn't too much. I am not asking it J2CL to do
it. I repeat, all I need is the ability to have bits and pieces of what
some need (and others think of too much) pluggable into this externally.
Some may want to plug in UI binder (I don't), for example. You plug the
right pieces you need and you get exactly the right amount of stuff - the
Goldilocks zone :)
> One thing that we need to do for GWT 3 is to somehow "package" those
> separate tools into an easy-to-use product (think polymer-cli and the
> like), so maybe GWT 3 will introduce its own daemon to monitor source files
> and trigger some actions before feeding them to the j2cl+closure-compiler
> toolchain, or maybe not.
>
Yes, something like that.
--
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].
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/575be67e-273b-4bf5-bc78-21548a72e208%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
