Hi Liu, I agree and share your considerations, but I think it is best to address the issue with a better modularization of the whole GWT distribution.
In fact it is not just a problem of the gwt-servlet.jar, but it is a problem also affecting gwt-user.jar and gwt-dev.jar: all features of GWT in these years have been added to a monolithic project (sub-framework like GWT RPC, activity and places, UiBinder are all coupled into the same jar, only request factory is modularized). GWT Java modularity only makes distinction between runtime code (gwt-user) and build time code (gwt-dev). The gwt-servlet is not a real component, it is jar with a bunch of classes filtered out from the other two. I would not say this is a best practice as it causes broken dependencies, with undesired java import which are not resolved and work as long as the gwt-servlet.jar classes are "supposed" not to use that code, and it is causing me a lot of issues as I'm using GWT in OSGi environment :-). Now GWT packages are polluted with dependencies hard to maintain, and so modularizing GWT is HARD! So, I definitively would tolerate that 6 MB jar for the moment (but I must say that honestly in my OSGi approach the war is a Skinny War and it does not include gwt-servlet.jar => maven.apache.org/plugins/maven-war-plugin/examples/skinny-wars.html), and encourage the community toward a better modularization of GWT for example in GWT 3.0. In any case, you could try to make your customized gwt-servlet.jar removing unnecessary code and use it when you deploy your webapp: you would not do anything architecturally worst than what GWT does (remember you don't use get-servlet.jar for building). I take this opportunity to make stronger a position of mine on the GWT build system: I believe the bad modularization to be an historical legacy of having used Ant for build, it's high degree of freedom has made GWT source code grow in a improper way (note that inside google they don't use Ant and probably this is why this aspect is of poor quality). Other web framework like Apache Wicket (built with maven) achieve a better degree of modularization. Probably also Gradle would orient the project in a better direction. There have been already many discussion on the subject, I suggest you to search for this topic (GWT modularization) on this group for getting an idea of the actual problems in advancing in this direction and would be glad if you'll participate to the discussion next time it arise. Regards, Cristiano 2014/1/16 dapeng liu <[email protected] <javascript:_e({}, 'cvml', '[email protected]');>> > any follow up on this? > > would like to see a saner gwt-servlet.jar > > include a 6M jar just to serve a single RemoteServlet is just absurd ... > > > > On Friday, June 25, 2010 4:09:29 AM UTC+8, Freeland Abbott wrote: >> >> Right now, if you pore through servlet/build.xml, we build >> gwt-servlet.jar by first building the classes for gwt-user, then filtering >> out a set of blacklisted packages from it. As we've added things, of >> course, the secret blacklist has grown stale, and that explains why some >> never-sane-in-server-context things like UiBinder are now packaged into >> gwt-servlet.jar. >> >> I'd like to change that, but it's breaking at least theoretically if >> anyone *had* found a server-side use, sane or otherwise. The fix would >> be easy (nothing stops you from dropping gwt-user onto your server, I >> suppose), and I'd be a bit disturbed if you did have a sane server-side >> use... but hey, I've been surprised before, which is why I'm asking. >> >> It also turns out that I-think-too-many legitimately server-side things >> (like, say, RPC) need to touch "client" packaged classes for things like >> enums and whatnot, and the classes with those enums then pull in a large >> list of other client things, and so client-only stuff like DomEvents turns >> out actually to be required. I'm not---at least not yet---talking about >> refactoring those things, just about getting to a whitelist algorithm for >> gwt-servlet with a minimal set of "grandfathered" client classes. >> >> As near as I can tell, the new definition of gwt-servlet would be, using >> ant ** and * wildcards mixed with shell-style comments 'cause XML ones are >> ugly: >> >> # what I actually want to keep in gwt-servlet: >> >> com/google/gwt/**/server/**/*.java >> com/google/gwt/**/shared/**/*.java >> >> # What server and shared RPC need, despite the "client" designation: >> >> com/google/gwt/user/client/rpc/*.java >> com/google/gwt/user/client/rpc/impl/AbstractSerialization*.java >> com/google/gwt/user/client/rpc/RpcRequestBuilder.java >> com/google/gwt/http/client/*.java >> com/google/gwt/xhr/client/ReadyStateChangeHandler.java >> com/google/gwt/xhr/client/XMLHttpRequest.java >> com/google/gwt/user/client/Timer.java >> com/google/gwt/user/client/rpc/SerializationException.java >> com/google/gwt/user/client/rpc/SerializationStreamReader.java >> com/google/gwt/user/client/rpc/SerializationStreamWriter.java >> com/google/gwt/rpc/client/ast/*.java >> com/google/gwt/rpc/client/impl/CommandSerializationStreamWriterBase.java >> com/google/gwt/rpc/client/impl/CommandClientSerializationStre >> amReader.java >> com/google/gwt/rpc/client/impl/EscapeUtil.java >> com/google/gwt/user/client/rpc/impl/ClientSerializationStreamWriter.java >> com/google/gwt/user/client/rpc/impl/Serializer.java >> com/google/gwt/rpc/client/impl/HasValuesCommandSink.java >> com/google/gwt/rpc/client/impl/SimplePayloadSink.java >> com/google/gwt/rpc/client/impl/RemoteException.java >> >> # and what they need, at least for compilation, and i'm not sure about >> all code paths: >> >> com/google/gwt/core/client/GWT.java >> com/google/gwt/core/client/JavaScriptException.java >> com/google/gwt/core/client/JavaScriptObject.java >> com/google/gwt/core/client/JsArray.java >> com/google/gwt/core/client/Duration.java >> com/google/gwt/core/client/Scheduler.java >> com/google/gwt/user/client/Window.java >> com/google/gwt/user/client/Window*.java >> com/google/gwt/user/client/BaseListenerWrapper.java >> com/google/gwt/user/client/Element.java >> com/google/gwt/user/client/Event.java >> com/google/gwt/user/client/EventListener.java >> com/google/gwt/user/client/EventPreview.java >> com/google/gwt/user/client/NativePreviewEvent.java >> com/google/gwt/user/client/History.java >> com/google/gwt/user/client/impl/HistoryImpl.java >> com/google/gwt/user/client/impl/DomImpl.java >> com/google/gwt/user/client/HistoryListener.java >> com/google/gwt/user/client/Cookies.java >> com/google/gwt/user/client/ui/Widget.java >> com/google/gwt/user/client/ui/HasWidgets.java >> com/google/gwt/user/client/ui/AbsolutePanel.java >> com/google/gwt/user/client/ui/ComplexPanel.java >> com/google/gwt/user/client/ui/IndexedPanel.java >> com/google/gwt/user/client/ui/InsertPanel.java >> com/google/gwt/user/client/ui/Panel.java >> com/google/gwt/user/client/ui/AttachDetachException.java >> com/google/gwt/user/client/ui/UIObject.java >> com/google/gwt/user/client/ui/RootPanel.java >> com/google/gwt/user/client/ui/WidgetCollection.java >> com/google/gwt/event/dom/client/HasNativeEvent.java >> com/google/gwt/event/dom/client/PrivateMap.java >> com/google/gwt/event/dom/client/DomEvent.java >> com/google/gwt/user/client/DOM.java >> com/google/gwt/user/client/impl/DOMImpl.java >> com/google/gwt/user/client/impl/WindowImpl.java >> com/google/gwt/dom/client/*.java >> com/google/gwt/core/client/impl/Impl.java >> com/google/gwt/core/client/impl/StackTraceCreator.java >> com/google/gwt/core/client/impl/SchedulerImpl.java >> com/google/gwt/core/client/impl/AsyncFragmentLoader.java >> com/google/gwt/core/client/JsArrayInteger.java >> com/google/gwt/core/client/JsArrayString.java >> com/google/gwt/core/client/RunAsyncCallback.java >> com/google/gwt/i18n/client/constants/*.java >> com/google/gwt/i18n/client/impl/*.java >> com/google/gwt/i18n/client/*.java >> >> >> As you might guess, I made that list by making gwt-servlet compile itself >> instead of using user, which probably isn't smart from a compile-time >> perspective. We can look at exactly what's "really" reachable from the >> server and shared root set, to see if we can prune at least the silly ones >> like DomEvent. My main objective, though, is to get to a whitelist >> approach at all. Anyone think that's a bad idea? >> > -- > 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]<javascript:_e({}, > 'cvml', > 'google-web-toolkit-contributors%[email protected]');>. > For more options, visit https://groups.google.com/groups/opt_out. > -- 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.
