I had the same problema of getting bigger source code files. The solution: Check your Module file (Module.gwt.xml).
As the default behavior is to create GUI the default module loads the User module and this module has a lot of code that you don't use when creating non GUI libraries/applications. In my case I wrapped the "json.org" json functions (JSON.stringify e JSON.parse) into a GWT module. Since the modern browsers has those functions built-in i used deffered binding so the code was download only for IE 6 & 7. In my case all my code was removed from the permutation for moderm browser and the total download was only ~4KB and the code for IE 6/7 was 7KB (3KB for the mimified version of json.org). Most of the 4KB was jre emulation, wich will be required (and download only once) no matter how many libraries you use. That's why all libraries in GWT must go with the Java code in the JAR. When using GWT you will use it to develop larger apps, so this 4KB overhead is minimal (or you known some javascript framework which uses less than 4KB in the minimal version?) if your library is so small you should consider writing it in plain javascript, but if you want to use it as a GWT library the final overhead in the application will be very small. On Tue, Jul 27, 2010 at 5:05 PM, Sripathi Krishnan < [email protected]> wrote: > That's why, when writing a function in GWT, I expect it to compile out >> to something that doesn't exceed the size of handwritten JS for the >> same purposes. > > Compiling Java to Javascript has some overheads which you cannot get rid > off easily. These overheads are not much if you are building a > web-application; but it could prove expensive if you are building a general > purpose js library. > > *Overhead 1 : IFrame Bootstrap loader* > As lineman78 suggests, you could use the built-in SingleScriptLinker, or > you could write a custom linker (not too difficult). But this isn't the bulk > of the overhead. > > *Overhead 2 : Java emulation in javascript* > GWT has to emulate java.lang and java.util packages for you in javascript. > Every class that you write will typically have the following four methods - > getClass(), toString(), equals() and hashcode() in javascript - even if you > don't actually invoke those methods. Besides, there are overheads with the > collections emulation. You cannot write a linker to overcome this overhead. > I believe GWT team is working on a simpler collections emulation, and that > would reduce the overheads - but till then I am afraid you don't have an > option. > > The only thing I can suggest is -*XdisableClassMetadata *flag to reduce > some of the overheads. > > --Sri > > > > On 27 July 2010 22:02, lineman78 <[email protected]> wrote: > >> Once the GWT compile completes, it is up to the linker to decide how >> to package it. The single script linker should behave how you would >> like, but you will have to make sure that deferred binding is never >> used in your code unless only one permutation is possible. The >> default linker is an iframe linker, which is the bootloader you are >> talking about. Google knew some people wouldn't like this and would >> like to do exactly what you are saying, which is why they maintain the >> SingleScriptLinker. If it doesn't behave exactly as you would like >> you may have to pull the source down and modify it to fit your needs. >> There needs to be exactly one primary linker, therefore there is no >> disable bootloader compile option because a linker must be provided in >> order for GWT to know how to distribute and load the code. >> >> >> http://google-web-toolkit.googlecode.com/svn/javadoc/2.1/com/google/gwt/core/linker/SingleScriptLinker.html >> >> On Jul 26, 4:54 pm, S Rabin <[email protected]> wrote: >> > I see. So when the only thing in my loadModule function is an export >> > call, and I export the method (via Ray Cromwell's gwt-exporter >> > library, which I was already using): >> > >> > public void HelloTest(String id){ >> > DOM.getElementById(id).setInnerHTML("Hello World"); >> > >> > } >> > >> > it should compile to 25kb plus a bootloader? I'm not arguing that a >> > bootloader is a bad idea for larger code, but I was really just hoping >> > for a --disable bootloader compile option. >> > >> > To address your concern that there is 'no possible way for the code >> > size to grow', and that the GWT compiler aggressively prunes dead >> > code, yes, I'm fully aware that it is designed to do that. That's >> > why, when writing a function in GWT, I expect it to compile out to >> > something that doesn't exceed the size of handwritten JS for the same >> > purposes. There are two options here: one, I'm missing some checkbox >> > (and it's not the OBFuscated option), or two, GWT is including a lot >> > more crap it thinks I need that I'm not aware of, hence why I'm asking >> > how to fix it. >> > >> > As for whether I know better than Google when it comes to the >> > bootloader... yes, in this case, I do. I anticipate this library to >> > be approximately 10kb of handwritten javascript, and I'm not doing >> > anything that should warrant more than 1 permutation beyond browser >> > specific speed optimizations. Therefore, distributing the library as >> > a .js file instead of a bootloader plus 4 different permutations seems >> > like a better idea. >> > >> > Is my only option here really to write my own linker to output one .js >> > file, no bootloader, no browser-specific optimizations? >> > >> > On Jul 26, 12:42 pm, lineman78 <[email protected]> wrote: >> > >> > > First, let me start by saying that people are already writing >> > > javascript libraries using GWT and have been for some time. Ray >> > > Cromwell created the GWT exporter library for this exact purpose for >> > > his own usage and open sourced it. While bootloaders seem expensive >> > > it is the only way to deliver the most efficient code to the client. >> > > There is no possible way for code size to grow when compiled because >> > > if you go far enough every method will eventually make it to a JSNI >> > > method, so what you are missing in your calculations is all the code >> > > supplied by google and the small overhead code involved with the >> > > bootloader. However, there is a linker available to create only one >> > > output, but in order for this to work the compilation must result in >> > > only one permutation, which is almost impossible unless you know the >> > > browser your client will be using. You asked: "Is there a way to crop >> > > out all the unnecessary cruft GWT seems to think I need?". You can >> > > write your own linker if you feel that you know better than google >> > > when it comes to the bootloader, but as far as the compiled code >> > > itself; the GWT compiler has very aggressive dead code elimination, so >> > > any output code will be used at some point. >> > >> > > On Jul 26, 9:21 am, S Rabin <[email protected]> wrote: >> > >> > > > I've done quite a bit of searching to find any information about >> this, >> > > > but it seems that people are more concerned with writing GWT >> libraries >> > > > to keep in GWT before compilation. >> > >> > > > I would like to write the libraries I frequently use in my projects >> in >> > > > GWT, then compile and expose them to hand-written Javascript. I >> have >> > > > several issues with the way GWT seems to handle what I want to do: >> > >> > > > 1) Bootstrapping. I understand that the iframe loading method is >> > > > highly efficient for large codebases so as to make the page non- >> > > > blocking, but for a small library bootstrapping is overkill. To >> test, >> > > > I tried writing my TableGenerator library (a 7kb handwritten non- >> > > > minified library) in GWT. The result was a 6 kb deferred binding >> > > > loader file (table.nocache.js) and 4 permutations of compiled JS >> > > > weighing in at 20-30kb each. Which brings me to issue #2 >> > >> > > > 2) For compiling the code, GWT seems to produce LARGER codebases. >> > > > Fast, yes, but how does 3-5kb of source result in 20-30kb of >> compiled >> > > > javascript? Is there a way to crop out all the unnecessary cruft GWT >> > > > seems to think I need? >> > >> > > > 3) I would prefer to not have a bootloader - I anticipate the >> compiled >> > > > form of my code is going to be smaller than the bootstrap code and >> > > > would rather it just be loaded. Is there a compilation option to >> > > > disable permutations and output (obviously more to handle different >> > > > implementations) code that works in all browsers? >> > >> > > > Sincerely, >> > > > Scott Rabin >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Google Web Toolkit" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]<google-web-toolkit%[email protected]> >> . >> For more options, visit this group at >> http://groups.google.com/group/google-web-toolkit?hl=en. >> >> > -- > You received this message because you are subscribed to the Google Groups > "Google Web Toolkit" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<google-web-toolkit%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/google-web-toolkit?hl=en. > -- André Moraes Analista de Desenvolvimento de Sistemas [email protected] http://andredevchannel.blogspot.com/ -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
