Unfortunately the design of the JRE is such that a large amount of complexity is exposed through what is an otherwise fairly slim class, which I'm sure just punches a hole out to java.util.Formatter to do the heavy lifting anyway. Would having Formatter.format instead of String.format make things more palatable? It doesn't actually change the code size cost, but makes the choice to use it a little bit more explicit.
I'm not too familiar with the GWT core development process: Does a first implementation need to be as close to perfect (in code-size) as possible, or can it provide currently completely absent (but expected) functionality, and be optimized in future releases? If not the former, where does the line fall? On Monday, February 9, 2015 at 11:19:39 AM UTC-5, Colin Alworth wrote: > > Its not that 3k is huge, its that it would be (to a developer, accustomed > to GWT's policies) massively larger than normally expected for built-in > methods. Just ran SOYC on a project (OBF but not closure), and the largest > java.lang.String method is 466 bytes, greater than twice the size of the > next biggest method. The entire class is only 1,749 bytes, and the entire > java.lang (for this project) is 10,535 bytes. > > Adding String.format, once, using only %s to substitute in strings easily, > would add 30%. > > On Mon Feb 09 2015 at 8:26:49 AM Benjamin DeLillo <bpd...@gmail.com > <javascript:>> wrote: > >> Dan, >> >> Thanks for the response. >> >> sprintf.js is 3kB minified and 7.5kB uncompressed weighing in at just >> under 200 LoC, you mention this would be too big. Just how small would an >> implementation have to be to be acceptable? How large are other JRE >> emulation implementations by comparison? I spoke with Ray at GWT.Create >> 2013 and his take on this was that although String.format was originally >> excluded from GWT for codesize reasons, that in today's browser/internet >> ecosystem the hit would be acceptable. >> >> I do agree that any less than complete implementation needs to have as >> obvious a failure mode as possible for when it diverges from String.format >> canon, and must be well documented and easy to find. How do other JRE >> emulation implementations handle this kind of divergence? Or do they avoid >> such divergence at all costs? >> >> >> >> On Monday, February 9, 2015 at 5:13:38 AM UTC-5, Daniel Kurka wrote: >> >>> Hi Benjamin, >>> >>> thanks for reaching out to us. Answers are inline. >>> >> >>> On Sat, Feb 7, 2015 at 5:31 AM, Benjamin DeLillo <bpd...@gmail.com> >>> wrote: >>> >>>> For an implementation to be accepted would it have to conform to the >>>> entire Java Formater spec? >>>> http://docs.oracle.com/javase/7/docs/api/java/util/Formatter.html >>>> >>>> I think supporting the entire java spec is impossible since we do not >>> have Locale working (for codesize reasons). So we would need to discuss >>> what a good subset would be >>> >>> >>>> Would an implementation lacking the Date/Time conversions be acceptable? >>>> >>>> Would an implementation that wraps sprintf.js be acceptable (if the >>>> licensing is compatible)? https://github.com/alexei/sprintf.js >>>> >>>> I briefly skimmed the lib and it seems huge, so I am inclined to say >>> no. In general you have to think about that any application will have the >>> hit of that method in their app as soon as they call String.format one time >>> in their code base. >>> >>> >>>> >>>> What about a minimal positional substitution implementation and nothing >>>> more? >>>> >>>> >>> Right now any code that relies on String.format will not compile in GWT >>> and thus give the author a clear indication of having a problem. Once we >>> support a subset this compile error might be gone, but we will be >>> introducing runtime errors for not supported features rather than compile >>> time errors. >>> >>> One could try to deal with these (and this is bad from the compiler >>> perspective), by looking at the parameters of String.format and only allow >>> statically resolvable arguments for the format String that are supported by >>> the emulation, but this is a very tight coupling of compiler and lib that >>> we do not want in the compiler. >>> >>> So if we want to do a minimal support of String.format these are the >>> kinds of problems we need to discuss. >>> >>> >>> >>>> -- >>>> 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/bc6afdc0-eb87- >>>> 4815-b076-6db912f8f94c%40googlegroups.com >>>> <https://groups.google.com/d/msgid/google-web-toolkit-contributors/bc6afdc0-eb87-4815-b076-6db912f8f94c%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> >>> >>> -- >>> Google Germany GmbH >>> *Dienerstr. 12* >>> *80331 München* >>> >>> Registergericht und -nummer: Hamburg, HRB 86891 >>> Sitz der Gesellschaft: Hamburg >>> Geschäftsführer: Graham Law, Katherine Stephens >>> >> -- >> 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 >> <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/google-web-toolkit-contributors/fa54c87b-c54b-4c8d-87f9-ff234c04cc35%40googlegroups.com >> >> <https://groups.google.com/d/msgid/google-web-toolkit-contributors/fa54c87b-c54b-4c8d-87f9-ff234c04cc35%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > -- 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/ea4b749d-a75d-4a38-ac2a-fd7389f20bd5%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
