Obtaining a DivElement from a custom cell

[Paul Mazzuca]

Is it possible to obtain a reference to a divElement inside a GWT custom 
cell?

Many Javascript libraries (Google JS Map API, Google Charts API, etc) often 
require a div element to be passed to the javascript in order to render, 
for example, a map or chart.  Basically, I am trying to create a cell list 
of charts or maps, but cannot seem to figure out how to get a reference to 
the divElement container within each cell.

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" 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 https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: About a proposed to change to SafeHtml's UriUtils

[Jens]

IMHO it's a small enough addition that totally makes sense and it's nothing 
that would block any future direction of GWT. I don't see any real reason 
to not accept the contribution.

The points mentioned are either clunky (pull in a complete different 
library just to get a single small feature or use some workarounds), won't 
happen anytime soon (replacing GWT SafeHtml with safe-html-types or wrap it 
around) or are simply pointless (J2CL not released, no fully worked out / 
discussed future plan for GWT 3.0). 

The only valid point might be code size increase and runtime performance, 
but thats a valid point for every contribution and should simply be worked 
out until it's acceptable.

IMHO contributions shouldn't be handled too picky as long as there is no 
concrete plan for GWT 3.0. Nowadays we have GWT 2.8 and a contributor wants 
to improve it, that's it, very simple. I'll probably give +1 after 
rethinking the code size / performance point and a maintainer for SafeHtml 
should give +2 once the code is fine.

-- 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/8826b9ee-f889-4f9d-be8c-1cb13fe2576e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: GWT 2.8.0 is not compatible with java6

[Juan Pablo Gardella]

Hi all,

A workaround to use gwt-2.8.0 in Java 6 is using retrololamda
. Here how I configured it (using
maven), by adding a profile (here the gist

):


production


production





com.google.gwt
gwt-servlet
provided




${basedir}/src/env/production



org.apache.maven.plugins
maven-dependency-plugin
2.10


process-classes

unpack-dependencies


gwt-servlet
${project.build.directory}/classes






net.orfjackal.retrolambda
retrolambda-maven-plugin
2.3.0


process-classes

process-main
process-test




true
1.6





On Wed, 2 Nov 2016 at 10:53 Thomas Broyer  wrote:

>
>
> On Wednesday, November 2, 2016 at 2:38:38 PM UTC+1, Juan Pablo Gardella
> wrote:
>
> Hi all,
>
> At release notes is not mentioned that now it will support only java7.
>
>
> Good catch!
>
>
> I found tbroyer comment here:
> http://stackoverflow.com/questions/28879590/jdk-and-jre-minimal-versions-required-for-gwt-compiling-and-running
>
> Can be updated the release notes with that?
> http://www.gwtproject.org/release-notes.html#Release_Notes_2_8_0
>
> Let me know, I can create the pull request.
>
>
> Yes please, go ahead.
>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Users" 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 https://groups.google.com/group/google-web-toolkit.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" 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 https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

RF Editors .with broken upgrading 2.8 RC2-> 2.8

[Michaël Van Robaeys]

Upgrading gwt 2.8 RC2 to GWT 2.8 seems to have broken requestfactory 
editors, see unreadable stacktrace below.
Everything else but the editors are working, any clue how I could 
debug/solve this?
I checked the dependencies for conflicts, only difference I could see was a 
minor version increase for js interop?

The problem does not occur when the editor has no childs: removing the 
.with(..) parameters in the requestfactory call.


Exception: com.google.gwt.core.client.JavaScriptException: (ReferenceError) 
: Ocj_g$ is not defined
ConsoleLogger.java:32 ReferenceError: Ocj_g$ is not defined
at Igj_g$ (AutoBeanCodexImpl.java:613)
at thj_g$.whj_g$ [as extractSplittable_0_g$] 
(AutoBeanCodexImpl.java:325)
at YDh_g$.qjh_g$ [as setProperty_2_g$] (AbstractAutoBean.java:277)
at gEh_g$. (ClientPropertyContext.java:45)
at scj_g$ (ClientPropertyContext.java:53)
at gcj_g$.ocj_g$ [as set_48_g$] (ClientPropertyContext.java:137)
at _oj_g$.apj_g$ [as visitReferenceProperty_0_g$] 
(AbstractRequestContext.java:949)
at YDh_g$.dEh_g$ [as traverseProperties_0_g$] 
(SettingsProxyAutoBean_com_google_web_bindery_requestfactory_shared_impl_EntityProxyCategory_com_goo…:142)
at YDh_g$.sjh_g$ [as traverse_1_g$] (AbstractAutoBean.java:166)
at YDh_g$.Xih_g$ [as accept_11_g$] (AbstractAutoBean.java:101)
at zbh_g$.B2g_g$ [as processReturnOperation_0_g$] 
(AbstractRequestContext.java:927)
at zbh_g$.C2g_g$ [as processReturnOperations_0_g$] 
(AbstractRequestContext.java:1279)
at fqj_g$.iqj_g$ [as processPayload_0_g$] 
(AbstractRequestContext.java:373)
at kpj_g$.mpj_g$ [as onTransportSuccess_0_g$] 
(AbstractRequestContext.java:1160)
at ulj_g$.wlj_g$ [as onResponseReceived_0_g$] 
(DefaultRequestTransport.java:136)
at kTh_g$.mTh_g$ [as onResponseReceived_0_g$] 
(CustomRequestTransport.java:28)
at rkc_g$.ukc_g$ [as fireOnResponseReceived_0_g$] (Request.java:250)
at Blc_g$.Clc_g$ [as onReadyStateChange_0_g$] (RequestBuilder.java:412)
at XMLHttpRequest. (XMLHttpRequest.java:329)
at jK_g$ (Impl.java:239)
at mK_g$ (Impl.java:291)
at XMLHttpRequest. (Impl.java:77)

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" 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 https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: About a proposed to change to SafeHtml's UriUtils

[Colin Alworth]

I agree entirely, just trying to see this as a potential contributor with 
its associated steep learning curve, and address the question of "Should we 
stop adding new features?".

we're rather in a situation of "I'd like to add this new feature to GWT; 
> and this is something I could do in my own code"


If (and I stress *if*) we are prepared to stop accepting features requests 
*that 
come with technically correct code*, we should not make that decision 
lightly. There is little doubt that this would be an improvement to GWT, 
and something that generally would make GWT apps better - why should we not 
take it?

My (and your) alternative of using an external safe-* project adds 
boilerplate for using gwt-user features that are considered up-to-date and 
well supported. That is the main basis for my +1, that it isn't sufficient 
to say "well, if you want this browser API, which could be easily supported 
out of the box, here are the hoops you jump through". Find/Replace all use 
of UriUtils leads to prefixed MyCompanyUriUtils for each class in the GWT 
that could/should be better, and does make updating harder, or encourages 
forked copies of GWT which then can be difficult to rebase and keep up to 
date. 

In contrast, transforming a user into a contributor, even if only a 
fraction of them stay with us long term, improves the overall health of the 
project.

The one technical objection I see is that including Collections.emptySet() 
and its transitive tree might add some weight for small projects that avoid 
*any* java collections. String[] might be preferred, but with a minor 
runtime cost last I checked. 

If it is a technically bad patch (style, increases compile time/size in an 
unacceptable way, insufficiently tested/documented, insecure, etc), it 
should be rejected. If it *could* be done in user code (and just about any 
feature request *could* be done), this probably isn't enough to reject it, 
unless we think it is a fringe case which other users are unlikely to avail 
themselves of. But if it improves the sdk in a way that will benefit users, 
and make it clear that GWT is in it for the long haul, improving every 
release, and open to developer contributions? Why should we stand in the 
way of that?

(Again, mostly devil's advocate, trying to address the huge number of 
concerns we've had over the last year or four of "contributing to GWT is 
too hard" or "GWT doesn't move forward and stay current with modern APIs". 
This is a token changeset to address this, and probably not perfect to 
demonstrate these thoughts, but I just wanted to make the point that we 
will be sending a message *whichever direction we take* with this 
changeset.)

-- 
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/39713959-c162-47af-b6d3-803e9c5fe736%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: About a proposed to change to SafeHtml's UriUtils

['Goktug Gokdogan' via GWT Contributors]

FWIW, I agree with tbroyer's assessment and the suggestion to use a helper
sounds reasonable.

On Thu, Nov 3, 2016 at 10:40 AM, Thomas Broyer  wrote:

>
>
> On Thursday, November 3, 2016 at 5:33:31 PM UTC+1, Colin Alworth wrote:
>>
>> With 3.0 on the horizon, we've promised consistency of a sort in 2.x, and
>> without 3.0 actually in sight, 2.x is going to need to see active
>> development. Encouraging a third generation of url tools is not a bad
>> thing, but only switching over half-way leaves something to be desired.
>>
>> I'll play devil's advocate a bit - I'm not addressing the patch
>> specifically (since I haven't fully read all of it or the discussion around
>> it, and if it was a bad patch, I'm sure it would have been shot down on its
>> own merits) but the thinking to use around what goes into the 2.x branch:
>>  * (point 1) We're not ready for maintenance mode, at least until we have
>> timelines and completed APIs for GWT 3. If we are, we should be forbidding
>> all merge requests to gwt-user that don't fix critical bugs.
>>
>>  * (point 2 and 3) Can't argue with new tools arriving that solve the
>> problem better, especially if they are going into 3 as a cross-platform way
>> of solving the problem (gwt/java/j2cl). Obvious caveat here (even for the
>> devil's advocate) that with the release of 3, breaking changes off of 2 are
>> acceptable and expected.
>>
>>  * (point 4) Without transitioning the existing GWT Safe* tools,
>> SafeHtmlTemplates is stuck in the past, as is UiBinder, I18n Messages, and
>> any HasSafeHtml widget (both in GWT and in the general ecosystem). This is
>> a lot to leave behind in the name of "but the tool didn't belong in GWT in
>> the first place". We've had our chance to properly deprecate it for the 2.8
>> release, and if our past timelines are any measure, it is going to be at
>> least a year before we finally ship a release with SafeHtml, and all that
>> use it, deprecated. And once we've reached that point, unless gwt-user
>> depends on (or rebases, etc) safe-html-types or any other successor, all of
>> the above downstream classes which use SafeHtml are left effectively broken
>> (not unlike the unported Generators and Linkers we have today).
>>
>> Obviously ClientBundle/GssResource isn't actually deprecated, but we have
>> officially said that new tools should not use the features that it takes
>> advantage of. SafeHtml takes this a step further - GssResource got several
>> upgrades within the 2.8 release (unlike other generators), despite it being
>> deprecated, but with SafeHtml going out, it takes out features within many
>> GWT Widgets themselves. There will be no officially supported way to
>> correctly assign safe html content into an HTML widget.
>>
>> Now yes, a bit of hyperbole there - you can of course (as Thomas noted in
>> his email) simply asString() the not-gwt SafeHtml and use it, or provide
>> your own wrapper, but depending on your project size (and GWT users out
>> there have some big ones) that could be hundreds or thousands of sites to
>> fix in code. Yet another change would be needed for any widgets that the
>> project has which implement HasSafeHtml (so it can still be used in
>> UiBinder), UiBinder @UiFields or getters (which return SafeUri for use in
>> its embedded SafeHtml handling), Messages (to wrap any incoming url). This
>> ignores any use of Messages/Constants in a SafeHtml-using uibinder itself -
>> I'm not seeing a clear path there without the use of default methods in
>> I18n interfaces (which admittedly, would probably work, but isn't going to
>> be pretty).
>>
>
> You forgot one major point here: this patch is proposing a new API (new
> overloads to existing methods), without actually changing the current API
> (at least in terms of its contract).
> So it's not about changing "every call sites for SafeHtml/UriUtils API",
> it's about being able to take advantage of a new behavior by selectively
> calling a new API.
> If you want that behavior everywhere, then yes you'll have to update all
> call sites; but the patch doesn't change that in any way (except what you
> change your code *to*)
> All those existing usage of SafeHtml you cited (SafeHtmlTemplates,
> UiBinder, I18N and HasSafeHtml) would be unchanged and keeping their
> current behavior (and only 2 of them deal with SafeUri: SafeHtmlTemplates
> and UiBinder). And the only two cases where UriUtils is called by those
> (vs. receiving a SafeUri value from the "user") are discouraged and
> generate a warning (and would continue to only use the default whitelist
> and reject "tel:" URIs; if you'd like to allow "tel:" URIs there, you'd
> have to change to SafeUri anyway, and then the responsibility of converting
> a String to a SafeUri falls on you, so no change to UriUtils or other
> APIs/generators is actually *required*):
> https://github.com/gwtproject/gwt/blob/3a41a8067767965ff72f4e49eb015f
> 

[gwt-contrib] Re: About a proposed to change to SafeHtml's UriUtils

[Thomas Broyer]

On Thursday, November 3, 2016 at 5:33:31 PM UTC+1, Colin Alworth wrote:
>
> With 3.0 on the horizon, we've promised consistency of a sort in 2.x, and 
> without 3.0 actually in sight, 2.x is going to need to see active 
> development. Encouraging a third generation of url tools is not a bad 
> thing, but only switching over half-way leaves something to be desired.
>
> I'll play devil's advocate a bit - I'm not addressing the patch 
> specifically (since I haven't fully read all of it or the discussion around 
> it, and if it was a bad patch, I'm sure it would have been shot down on its 
> own merits) but the thinking to use around what goes into the 2.x branch:
>  * (point 1) We're not ready for maintenance mode, at least until we have 
> timelines and completed APIs for GWT 3. If we are, we should be forbidding 
> all merge requests to gwt-user that don't fix critical bugs. 
>
>  * (point 2 and 3) Can't argue with new tools arriving that solve the 
> problem better, especially if they are going into 3 as a cross-platform way 
> of solving the problem (gwt/java/j2cl). Obvious caveat here (even for the 
> devil's advocate) that with the release of 3, breaking changes off of 2 are 
> acceptable and expected.
>
>  * (point 4) Without transitioning the existing GWT Safe* tools, 
> SafeHtmlTemplates is stuck in the past, as is UiBinder, I18n Messages, and 
> any HasSafeHtml widget (both in GWT and in the general ecosystem). This is 
> a lot to leave behind in the name of "but the tool didn't belong in GWT in 
> the first place". We've had our chance to properly deprecate it for the 2.8 
> release, and if our past timelines are any measure, it is going to be at 
> least a year before we finally ship a release with SafeHtml, and all that 
> use it, deprecated. And once we've reached that point, unless gwt-user 
> depends on (or rebases, etc) safe-html-types or any other successor, all of 
> the above downstream classes which use SafeHtml are left effectively broken 
> (not unlike the unported Generators and Linkers we have today). 
>
> Obviously ClientBundle/GssResource isn't actually deprecated, but we have 
> officially said that new tools should not use the features that it takes 
> advantage of. SafeHtml takes this a step further - GssResource got several 
> upgrades within the 2.8 release (unlike other generators), despite it being 
> deprecated, but with SafeHtml going out, it takes out features within many 
> GWT Widgets themselves. There will be no officially supported way to 
> correctly assign safe html content into an HTML widget.
>
> Now yes, a bit of hyperbole there - you can of course (as Thomas noted in 
> his email) simply asString() the not-gwt SafeHtml and use it, or provide 
> your own wrapper, but depending on your project size (and GWT users out 
> there have some big ones) that could be hundreds or thousands of sites to 
> fix in code. Yet another change would be needed for any widgets that the 
> project has which implement HasSafeHtml (so it can still be used in 
> UiBinder), UiBinder @UiFields or getters (which return SafeUri for use in 
> its embedded SafeHtml handling), Messages (to wrap any incoming url). This 
> ignores any use of Messages/Constants in a SafeHtml-using uibinder itself - 
> I'm not seeing a clear path there without the use of default methods in 
> I18n interfaces (which admittedly, would probably work, but isn't going to 
> be pretty).
>

You forgot one major point here: this patch is proposing a new API (new 
overloads to existing methods), without actually changing the current API 
(at least in terms of its contract).
So it's not about changing "every call sites for SafeHtml/UriUtils API", 
it's about being able to take advantage of a new behavior by selectively 
calling a new API.
If you want that behavior everywhere, then yes you'll have to update all 
call sites; but the patch doesn't change that in any way (except what you 
change your code *to*)
All those existing usage of SafeHtml you cited (SafeHtmlTemplates, 
UiBinder, I18N and HasSafeHtml) would be unchanged and keeping their 
current behavior (and only 2 of them deal with SafeUri: SafeHtmlTemplates 
and UiBinder). And the only two cases where UriUtils is called by those 
(vs. receiving a SafeUri value from the "user") are discouraged and 
generate a warning (and would continue to only use the default whitelist 
and reject "tel:" URIs; if you'd like to allow "tel:" URIs there, you'd 
have to change to SafeUri anyway, and then the responsibility of converting 
a String to a SafeUri falls on you, so no change to UriUtils or other 
APIs/generators is actually *required*):
https://github.com/gwtproject/gwt/blob/3a41a8067767965ff72f4e49eb015f587fcfee16/user/src/com/google/gwt/uibinder/attributeparsers/SafeUriAttributeParser.java#L41
https://github.com/gwtproject/gwt/blob/3a41a8067767965ff72f4e49eb015f587fcfee16/user/src/com/google/gwt/safehtml/rebind/SafeHtmlTemplatesImplMethodCreator.java#L183
 
(warning at: 

[gwt-contrib] Re: About a proposed to change to SafeHtml's UriUtils

[Colin Alworth]

With 3.0 on the horizon, we've promised consistency of a sort in 2.x, and 
without 3.0 actually in sight, 2.x is going to need to see active 
development. Encouraging a third generation of url tools is not a bad 
thing, but only switching over half-way leaves something to be desired.

I'll play devil's advocate a bit - I'm not addressing the patch 
specifically (since I haven't fully read all of it or the discussion around 
it, and if it was a bad patch, I'm sure it would have been shot down on its 
own merits) but the thinking to use around what goes into the 2.x branch:
 * (point 1) We're not ready for maintenance mode, at least until we have 
timelines and completed APIs for GWT 3. If we are, we should be forbidding 
all merge requests to gwt-user that don't fix critical bugs. 

 * (point 2 and 3) Can't argue with new tools arriving that solve the 
problem better, especially if they are going into 3 as a cross-platform way 
of solving the problem (gwt/java/j2cl). Obvious caveat here (even for the 
devil's advocate) that with the release of 3, breaking changes off of 2 are 
acceptable and expected.

 * (point 4) Without transitioning the existing GWT Safe* tools, 
SafeHtmlTemplates is stuck in the past, as is UiBinder, I18n Messages, and 
any HasSafeHtml widget (both in GWT and in the general ecosystem). This is 
a lot to leave behind in the name of "but the tool didn't belong in GWT in 
the first place". We've had our chance to properly deprecate it for the 2.8 
release, and if our past timelines are any measure, it is going to be at 
least a year before we finally ship a release with SafeHtml, and all that 
use it, deprecated. And once we've reached that point, unless gwt-user 
depends on (or rebases, etc) safe-html-types or any other successor, all of 
the above downstream classes which use SafeHtml are left effectively broken 
(not unlike the unported Generators and Linkers we have today). 

Obviously ClientBundle/GssResource isn't actually deprecated, but we have 
officially said that new tools should not use the features that it takes 
advantage of. SafeHtml takes this a step further - GssResource got several 
upgrades within the 2.8 release (unlike other generators), despite it being 
deprecated, but with SafeHtml going out, it takes out features within many 
GWT Widgets themselves. There will be no officially supported way to 
correctly assign safe html content into an HTML widget.

Now yes, a bit of hyperbole there - you can of course (as Thomas noted in 
his email) simply asString() the not-gwt SafeHtml and use it, or provide 
your own wrapper, but depending on your project size (and GWT users out 
there have some big ones) that could be hundreds or thousands of sites to 
fix in code. Yet another change would be needed for any widgets that the 
project has which implement HasSafeHtml (so it can still be used in 
UiBinder), UiBinder @UiFields or getters (which return SafeUri for use in 
its embedded SafeHtml handling), Messages (to wrap any incoming url). This 
ignores any use of Messages/Constants in a SafeHtml-using uibinder itself - 
I'm not seeing a clear path there without the use of default methods in 
I18n interfaces (which admittedly, would probably work, but isn't going to 
be pretty).

---

Speaking for myself again, I am not prepared to outright "-2" any 
contribution to gwt-user that isn't a fix for a critical bug. I don't think 
we're ready today to deprecate everything inside of gwt-user that isn't JRE 
emulation or jsinterop-based. Ideally of course aspects of GWT will be spun 
out as community projects and maintained separately, but until we pull it 
off (or even start), any new GWT user will assume that anything in gwt-user 
is the best basis for a GWT project. Actively abandoning most of gwt-user 
is not going to help the already difficult situation we're in there.

-- 
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/63659db1-99a4-45d7-b83a-e20f8d78a63b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Google Plugin for Eclipse Mars

['Thomas Lacroix' via GWT Users]

My OS is Windows 10 Professionnel v 1607, 64 bits.

Neon.1a is the default version that install for me with the eclipse 
installer, I am not doing anything special.

As suggested I filled a bug in SDBG to move the discussion over there as it 
is not really related to GWT:

https://github.com/sdbg/sdbg/issues/155

It details the steps I am doing but no screencast unfortunately as it is 
not my personal computer but the one of my company.

Thanks for trying it out on our end. Ivan Markov from the SDBG team also 
told me the install was working for everybody else over here. I don't know 
what is going on with my environment…

Thomas

Le jeudi 3 novembre 2016 01:02:31 UTC+1, Brandon Donnelson a écrit :
>
> I just ran through the install routine again for Eclipse Neon and GWT 
> Eclipse Plugin with SDBG Javascript debugger with out an issue. So I can't 
> replicate the issue yet. What operating system are you using? Could you 
> screencast the process, maybe I'm missing something?
>
> On Wednesday, November 2, 2016 at 11:35:28 AM UTC-7, Brandon Donnelson 
> wrote:
>>
>> Can you file an issue in the SDBG issues? I think I need to test Neon 1a, 
>> I've got 1. Howd you get 1a? 
>>
>> https://github.com/sdbg/sdbg/issues
>>
>>>


-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" 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 https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Strange error with streams

[foal]

Hi Andrey,

Tried to create simple project with given classes - all works as desired. 

Best,
Stas

On Wednesday, November 2, 2016 at 2:38:25 PM UTC+1, foal wrote:
>
> Hi Andrey,
>
> No problem, even a little bit latter. 
>
> Please note that I have use GWT 2.8RC3 and preleased version of Guava. So 
> if you fix something between RC3 and the release it may be a reason.
>
> Best,
> Stas
>
> On Wednesday, November 2, 2016 at 2:31:16 PM UTC+1, Andrei Korzhevskii 
> wrote:
>>
>> Hi foal,
>>
>> We had kind of similar problems when implemented Stream support but I 
>> cannot reproduce it now
>> in a simple test like 
>> https://gist.github.com/nordligulv/9dfa0ca5ccfed3def097aefc59ea1e32
>>
>> Can I ask you to create simple maven project with these classes to 
>> reproduce it?
>>
>> On Tuesday, November 1, 2016 at 1:14:27 PM UTC+2, foal wrote:
>>>
>>> Simplified widget is in attachment. Mehod createButtons contains the the 
>>> problem code.
>>>
>>> Let me know if you need something else.
>>>
>>> Stas
>>>
>>> On Tuesday, November 1, 2016 at 11:13:41 AM UTC+1, Jens wrote:

 Use -style PRETTY as SDM parameter so that the JS code is more 
 readable. 

 Looks like a GWT bug either in the compiler because of method 
 references or inside the Stream emulation. If you can provide a minimal, 
 reproducible example then open a bug report.

 -- J.

>>>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" 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 https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.