On Wednesday, May 24, 2017 at 7:14:52 AM UTC+2, Learner Evermore wrote:
>
> ... continuing the above - there is more. Let's now come back to the
> analysis part. Yes, it is possible to do the "whole-world analysis" outside
> the compiler. But what perspective should the analysis take? It is
> irrelevant if it cannot reduce the number of possible classes - we don't
> want all of Java runtime library in there, for example. We need to discover
> which parts are needed from the code that *could* be executed. GWT
> determines this based on entry points and other configuration in the
> *.gwt.xml files **and** what it finds in the compilation classpath, as
> configured, including its own version of the standard library.
>
Actually, no.
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.
> So, the pre-compilation analysis tool would have to configured exactly the
> same and process exactly the same configuration as the GWT compilation
> step. This would have to evolve in lockstep with GWT. It would also be
> doing the same processing and analysis that GWT already has to do - at
> least the step of deciding which bits of code to convert to JavaScript
> before any further optimization.
>
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")
> Are we done with that? Whether or not you think that this still can or
> should be done outside and with no integration with J2CL, let's move on to
> the debugging. How about *any* dev mode where the code is to be
> automatically updated on demand? What event signifies that demand? When can
> we trigger that analysis and code gen step before, say, the Super Dev Mode
> of the future gets hold of the code? Again, without any ways to hook into
> that, we'd be relying on the analysis and code generation already having
> been done by the time SDM has to do anything with it and that means either
> manual triggering or something like "on save", if that can be monitored
> (not reliable). And how would that pre-step be configured by the developer?
> Duplicating configuration but possibly in a different way?
>
I'd say yes (this is my own opinion, also see "we don't know what GWT 3
will look like" above).
This is not much different from annotation processors actually.
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)
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).
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.
--
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 google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/f9ee5ff8-3dd6-4b9a-bf4b-f83623194669%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
