Utils

[Colin Alworth]

I've spent a little time over the last week trying again to tease apart GWT into smaller modules and working out dependencies between them. This is in part to see about a not-ant build system, and in part to see why a minimal GWT app is surprisingly big. The target here isn't the user lib, but the compiler and associated other pieces that are all compiled together: emulation, internal annotations, the generator/linker api, commandline tools, testing infrastructure, etc.

Along the way, the biggest snarl I've run into so far is Util, and its siblings, Utility and StringUtils. "A smattering of useful methods" indeed.

Utility has the benefit of depending on very little outside the JRE, but gets used all over the place (in Util, the compiler, dev mode, linkers, generators, command-line tools...) - not such a big deal by itself, just need to make sure it is in one of the core modules so that everything else can lean on it. StringUtils likewise depends on nothing and is used all over with one additional usecase: servlets.

Util on the other hand depends on the generator types (treelogger, UnableToCompleteException), on SpeedTracer (what is the status of SpeedTracer these days?), and on the org.w3c.dom library. It also gets used pretty much everywhere, which adds transitive dependencies to the above: the compiler, dev mode, generators, linkers, command line tools. It also has this confusing Javadoc:

> Methods in this class are candidates for being moved to {@link com.google.gwt.util.tools.Utility} if they would be generally useful to tool writers, and don't involve TreeLogger.

Only six methods (out of dozens) take either the logger or throw that UnableToCompleteException

I'd tend to say that all generators shouldn't depend on org.w3c.dom or SpeedTracer to be on their classpath just to compile including any ResourceGenerator for ClientBundle (and yes, admittedly, Generators and Linkers are going away when GWT3 starts showing up, but until then...), the Link.main() likely doesn't need to depend on generators, etc.

To that end, I'm looking at teasing apart some of these into distinct classes, purpose-built for where they are used, and only with the dependencies they need. Any objections to this that would prevent it getting merged into master?

It is just over 1000 lines long (plus another 350 for Utility), and the first cut appears to be taking out org.w3c.dom. This slices out just over 10%, and at no real cost that I've noticed yet - all the methods were private, and at least ant dist-dev passes without them, I'll be running a longer build soon.

Thoughts?

[Jens]

I like it. IMHO if utility methods depend on something other than pure JRE they should live in their own utility class for that package/library/purpose. So I would be fine with W3cDomUtils, SpeedTracerUtils, etc. 

-- J.

[Goktug Gokdogan]

wrt general refactoring:

I think the biggest value to take apart is emulation + annotations.

You might want to take out the testing infra so it is not compiled together with the rest. Similarly SDM as well.

For the rest I don't see much value trying to separate into multiple pieces.

PS: Speedtracer is probably already dead; at least for us internally for very long time.

On Sun, Nov 13, 2016 at 8:31 AM, Jens <jens.ne...@gmail.com> wrote:

I like it. IMHO if utility methods depend on something other than pure JRE they should live in their own utility class for that package/library/purpose. So I would be fine with W3cDomUtils, SpeedTracerUtils, etc. 

-- J.

--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/ef94e2e8-0ff1-4a7a-b4ce-b5363c8b7b90%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.