What constitutes an acceptable emulated String.format implementation?

[Benjamin DeLillo]

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?

[Daniel Kurka]

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-co...@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.

--

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

[Benjamin DeLillo]

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.
For more options, visit https://groups.google.com/d/optout.

[Colin Alworth]

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%.

To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-co...@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.

[Benjamin DeLillo]

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?

[Goktug Gokdogan]

On Fri, Feb 6, 2015 at 8:31 PM, 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

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-co...@googlegroups.com.

[Goktug Gokdogan]

Also Daniel's point about compile-time errors are important. That could be potentially handled with error-prone checkers.

[Benjamin DeLillo]

If trying to provide a fairly complete duplicate of the JRE functionality is too much of a point of contention, would it be more acceptable to provide a simpler/lighter-weight string interpolation implementation behind e.g. GWT.format() or to follow the NumberFormat convention a StringFormat class?

[Colin Alworth]

I'd be strongly in favor of a StringFormat class - this could be library-ized easily, letting someone opt in to even having it in their project, or call it. 

Since we're changing the API (though I assume keeping the 'format string' language), you could take other steps to ensure small complied size and best runtime performance. Consider SafeHtmlTemplates or Messages, with their abilities to interpolate strings, but knowing the format string to use at compile-time, not runtime.

This probably won't work in all cases (or be especially nice to use in the other cases), but will be faster and smaller when compiled to JS. 

--

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-co...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/9d1583ef-ae7b-41e2-9eca-207e8ef33062%40googlegroups.com.

[James Nelson]

I know that adding more magic methods is generally frowned upon,

but the advantage here is that a String literal can be made available at compile time, allowing the injection of a minimal-overhead replacement.

If, for any reason, the String is not a literal, we can emit a warning about the runtime library being included and just let it go to the runtime StringFormat tool.

Given how likely a formatting String is to be a constant, I think it would be worth it;

if anyone is interested in collaborating, I do have simple magic method injection running on my fork,

if we prototype it and it goes (provably) well, then perhaps we could submit a patch to include the new magic method in UnifyAst.

Should the team decide that we don't want any magic methods, then the other alternative would be a Java 8 compiler plugin;

I have a prototype which looks up calls to GWT.create and replaces them, so looking up String.format and emitting a super-sourced copy with a generated replacement should also be possible.

How to integrate that as a pre-build step is another question, but the important thing is that it is possible and we do have options for how we want to implement this.

[Benjamin DeLillo]

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:

[Jens]

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.