Re: [gwt-contrib] What constitutes an acceptable emulated String.format implementation?
I'm curious if anyone knows, what is 10KB, percentage wise, vs the size of the average GWT project? I don't know if the one I work with is average or unusual weighing in at 7.2MB. I'm wondering if my perspective is skewed. 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=emailutm_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
Re: [gwt-contrib] What constitutes an acceptable emulated String.format implementation?
I'm curious if anyone knows, what is 10KB, percentage wise, vs the size of the average GWT project? I don't know if the one I work with is average or unusual weighing in at 7.2MB. I'm wondering if my perspective is skewed. I guess that question is irrelevant. You will always have small and large apps. For example at work we have a small app that only handles SSO logins (300kb or so) and larger apps (4+ MB). But as everything is gzip'ed by the web server anyways additional 10KB are pretty much negligible. GWT has a long history of compiling out stuff that you don't use, however with String.format() your have lots of formatting options available through a single API which makes it pretty difficult to compile out formatting code that is not needed because your app never uses it (e.g. maybe you never format a date, so lets prune all date formatting code) I am kind of against emulating String.format() and Formatter itself because IMHO formatting is useless if you can not do it in a locale sensitive way. Since String.format() and Formatter uses java.util.Locale which GWT does not support it is useless to emulate both. If GWT would fully support java.util.Locale I would vote for a full String.format() / Formatter emulation even if that means we pull in 10kb of formatting code (as long as it fully compiles out if String.format() / Formatter isn't used at all in an app). A developer should be aware that a single versatile formatting API will pull in quite some code. -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/93bc2d31-6d21-4aef-a952-541d234f7117%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] What constitutes an acceptable emulated String.format implementation?
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 bpd9...@gmail.com 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+unsubscr...@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=emailutm_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. 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=emailutm_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
Re: [gwt-contrib] What constitutes an acceptable emulated String.format implementation?
Also Daniel's point about compile-time errors are important. That could be potentially handled with error-prone checkers. On Mon, Feb 9, 2015 at 9:39 AM, Goktug Gokdogan gok...@google.com wrote: On Fri, Feb 6, 2015 at 8:31 PM, Benjamin DeLillo bpd9...@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 We may have 'known' limitations. Would an implementation lacking the Date/Time conversions be acceptable? Yes, I think that is a possibility. Would an implementation that wraps sprintf.js be acceptable (if the licensing is compatible)? https://github.com/alexei/sprintf.js I prefer stuff in core to be pure Java if there is no strong reason to do otherwise. What about a minimal positional substitution implementation and nothing more? Not sure about this one; perhaps other people may have a good arguments for one way or the other. -- 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/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=emailutm_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/CAN%3DyUA2rhkYhiOcCuvHa36ciH3KyVCH-0tQcaQNyZ-5mn%2BhfyQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] What constitutes an acceptable emulated String.format implementation?
On Fri, Feb 6, 2015 at 8:31 PM, Benjamin DeLillo bpd9...@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 We may have 'known' limitations. Would an implementation lacking the Date/Time conversions be acceptable? Yes, I think that is a possibility. Would an implementation that wraps sprintf.js be acceptable (if the licensing is compatible)? https://github.com/alexei/sprintf.js I prefer stuff in core to be pure Java if there is no strong reason to do otherwise. What about a minimal positional substitution implementation and nothing more? Not sure about this one; perhaps other people may have a good arguments for one way or the other. -- 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/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=emailutm_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/CAN%3DyUA1NRNSdG-u%3D1pPyQKiNaeqWkdmeTvsuZ4wWJC3JHsF_6Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] What constitutes an acceptable emulated String.format implementation?
Hi Benjamin, thanks for reaching out to us. Answers are inline. On Sat, Feb 7, 2015 at 5:31 AM, Benjamin DeLillo bpd9...@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+unsubscr...@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=emailutm_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. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CALLujir_g5%2BZhbDbF_CnbHdKyfKAYomz9%2B9x3asZvu0O7vGQKg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] What constitutes an acceptable emulated String.format implementation?
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 javascript: 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+unsubscr...@googlegroups.com javascript:. 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=emailutm_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. 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. For more options, visit https://groups.google.com/d/optout.
[gwt-contrib] What constitutes an acceptable emulated String.format implementation?
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 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 What about a minimal positional substitution implementation and nothing more? -- 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/bc6afdc0-eb87-4815-b076-6db912f8f94c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
