GWT hasn't had the habit of emulating things badly, and/or with bad performance. When things are there, people tend to use them without taking much care of performance; and because it's emulation we have no place to put warnings in javadocs that would be visible to the user from his IDE (there could be the reference page at gwtproject.org, but even that page is automatically generated so I'm not sure how we'd include those warnings). …so the general idea is that in those cases it's better to not emulate at all. That said, I could understand you'd like ByteArray*Stream emulated, but I doubt it'd be enough for most people; better abstract things out and/or refactor (you could possibly use TypedArrays, they work on both client and server side).
On Thursday, February 6, 2014 10:19:22 PM UTC+1, V.B. wrote: > > The only related > issue<https://code.google.com/p/google-web-toolkit/issues/detail?id=604>I > could find about this was originally slated to be included as far back as > GWT *1*.*4*, but still hasn't made it in. > (https://code.google.com/p/google-web-toolkit/issues/detail?id=604) > > *What would it take for GWT to emulate > InputStream/OutputStream/ByteArrayInputStream/ByteArrayOutputStream, etc?* > > Naturally, FileInputStream/FileOuputStream are out of the question, but > having much of the rest of java.io available client-side would be very > useful. It would also help for certain cases where duplicate code must be > maintained for the client-side, as well as the server-side, just to avoid > such emulation issues. Nobody likes having to maintain duplicate code. > > > -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/groups/opt_out.
