dead classes and docs

85 views
Skip to first unread message

Colin Alworth

unread,
Nov 29, 2016, 8:42:19 PM11/29/16
to GWT Contributors
As previously mentioned, I'm walking over a lot of old GWT and playing with some ideas around structure changes. Along the way, I've found some apparently dead classes, and some very rotten docs.

For example, at the root of each zip release including 2.8.0, we have about.html, which proudly states that GWT's copyright is as of 2009, the project is called Google Web Toolkit, and makes note of a few dependencies like jetty 6 and mozilla 1.7. The file about.txt is a plain text version of the same. COPYING and COPYING.html list the license for the project itself, and then go on to list licenses for projects distributed with GWT which again, is not at all up to date. Both html files link to http://code.google.com/p/google-web-toolkit/ (though at least one of them shows off a strict doctype). They've been edited apparently by hand a few times since 2009, but inconsistently. If we have legal reasons to keep these up to date, we should probably be somewhat more aggressive about this, or else remove the inaccurate portions or the files entirely.

The 'doc' subdirectory within the project also contains some treasures, and haven't been modified since 2009 or so either (and still reference Google prominently). At least these are entirely dead and no longer among us - as far as I can tell, they are not used in the final zip at all. It appears that these assumed that the doclet code (see build_tools/doctool/ I think?) would visit these files and update them, as there are html files with @link references in them, but to classes that were removed as "obsolete documentation" again in 2009.

Along similar lines, there is a directory "helpInfo" inside of doc which contains some very short but informative snippets of html, describing some features and their gotchas within GWT. These likely all either have a place at gwtproject.org already, or are out of date and should be removed. These are _also_ shipped in the release zip, despite inaccuracies or extremely outdated details.

The doclet generating code _is_ apparently used, mostly for including example sources. It also includes a few things I can't entirely work out, and suspect aren't useful, but are still used. For example, there is a target in doc called "emul-ezt" which runs com.google.doctool.JreDocTool. One of the flags is "-out ${project.build}/emul-ezt/fragment.html", which I assume means that after this target finishes, there should be a file called fragment.html somewhere, but I have yet to find it even when running that target directly. There is also a DocTool class in the same package, which doesn't appear to be used at all. Removing these classes and the corresponding target also results in a fair bit less logspam of the variety "(use -source 8 or higher to enable default methods)" and "(use -source 7 or higher to enable diamond operator)", since apparently this tool/target was never updated beyond Java 6 or so.

I'm less certain about this one: the root directory "jni" appears to contain wiring for the old "Hosted Mode" that predated our now-deprecated Dev Mode. It was apparently all deleted once, in 2009, but quickly restored when it was found that some of the native wiring was required for windows/IE to correctly perform update checks. The other platforms likely do not need this code any more though, right? And can someone confirm that update checks are disabled by default anyway? CompilerOptionsImpl.isUpdateCheckDisabled returns true unconditionally, and ArgHandlerDisableUpdateCheck at least appears to default to disabling the check, and further marks this flag as experimental, suggesting we can safely remove it?

Finally, a few dead classes in gwt-dev that have no references to them, and deleting them seems clean: ServletContextTreeLogger, WorkDirs, ArgHandlerLink, ArgHandlerLibraries, ArgHandlerOutDir, ArgHandlerOutputLibrary, CloseableJarHandlerFactory and CloseableJarHandler. None of these are referenced directly, nor by name in any String in the codebase - is there a reason to not outright remove them, since they are within the compiler itself?
Reply all
Reply to author
Forward
0 new messages