compiler errors after upgrade to gwt 2.8.0

[Magnus]

Hello,

after upgrading a project from GWT 2.7.0 to GWT 2.8.0 I and when compiling 
with the GWT compiler using the -strict option, I get a lot of errors like 
this:

   Tracing compile failure path for type 'java.util.stream.Stream'
  [ERROR] Errors in 
'jar:file:/home/magnus/dvl/lib/gwt-2.8.0/gwt-user.jar!/com/google/gwt/emul/java/util/stream/Stream.java'
 [ERROR] Line 1113: The method naturalOrder() is undefined for the 
type Comparator
 [ERROR] Line 101: The method spliterator() is undefined for the 
type List
 [ERROR] Line 1098: The method naturalOrder() is undefined for the 
type Comparator
 [ERROR] Line 1122: The method spliterator() is undefined for the 
type List
 [ERROR] Line 181: The method stream() is undefined for the type 
Set
 [ERROR] Line 85: The method stream(Object[]) is undefined for the 
type Arrays
 [ERROR] Line 185: The method stream(T[]) is undefined for the type 
Arrays

When switching back to GWT 2.7.0, the errors don't appear.

Unfortunately, the messages do not point in my code. So how do I have to 
modify my project in order to solve the problem?

Thanks
Magnus

-- 
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: Experimental release of Elemental2

['Julien Dramaix' via GWT Contributors]

The problem with generating getters and setters is that you can potentially
conflict with an existing method. I had this problem when I've generated
the java classes to interacting with the typescript compiler. Some classes
had a field named foo and a method named getFoo() and that's not
necessarily a simple getter.

On Wed, Feb 15, 2017 at 3:34 PM Colin Alworth  wrote:

>
>
> On Wednesday, February 15, 2017 at 4:01:01 PM UTC-6, Goktug Gokdogan wrote:
>
> Thanks for the feedback.
>
>
>
> On Wed, Feb 15, 2017 at 1:05 PM, Ming-Yee Iu  wrote:
>
> Well, ok. Thanks.
>
> Just in terms of general feedback on Elemental2:
>
> 1. I'm not sure whether the conversion of JavaScript properties to Java
> fields is the best choice. Sure, it "feels" more like the original
> JavaScript, but
>
>
>
> a) it's inconsistent with Java semantics,
>
>
> This could be a stylistic inconsistency not a semantic one. All arguments
> that I have seen in favor for having accessors instead of fields are
> inapplicable to Elemental fields since they all assume changes in the
> implementation of accessors which in our case always a pass through.
>
> However I am aware of the stylistic expectation from some java devs and we
> might end up providing setter/getter as overlays for people who would like
> to stick conventional style.
>
>
> There are also a variety of tools that assume methods rather than fields -
> uibinder, cssresource, editors all made assumptions about turning dot
> notation into getters (and in the case of editors, setters), and did not
> support fields at all as far as I'm aware. This is true of most (though not
> all) codegen tools I've worked with since as well.
>
> Another advantage: You can't turn a field into a method-reference.
>
>
-- 

Julien Dramaix |  Software Engineer |  dram...@google.com |  650-750-6053

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

Re: [gwt-contrib] Re: Experimental release of Elemental2

['Goktug Gokdogan' via GWT Contributors]

Thanks for the feedback.

On Wed, Feb 15, 2017 at 1:05 PM, Ming-Yee Iu  wrote:

> Well, ok. Thanks.
>
> Just in terms of general feedback on Elemental2:
>
> 1. I'm not sure whether the conversion of JavaScript properties to Java
> fields is the best choice. Sure, it "feels" more like the original
> JavaScript, but
>


> a) it's inconsistent with Java semantics,
>

This could be a stylistic inconsistency not a semantic one. All arguments
that I have seen in favor for having accessors instead of fields are
inapplicable to Elemental fields since they all assume changes in the
implementation of accessors which in our case always a pass through.

However I am aware of the stylistic expectation from some java devs and we
might end up providing setter/getter as overlays for people who would like
to stick conventional style.


> b) I'd be afraid that a Java compiler might apply some unexpected
> optimization there as a result,
>

I don't think that's possible.


>  c) it's harder to mock the behavior of the classes for unit tests
>

Actually a field doesn't require mocking; but native accessor as you are
proposing does require mocking.


> and d) alternate implementations of Elemental2 aren't possible (for
> example, I couldn't make a DevMode-like JavaFx version of Elemental2 like I
> did with Elemental 1).
>

I can see how accessor can help with this as it gives you more flexibility
on your  re-implementation of the API.


>
> 2. Personally, I would prefer if Elemental 2 used interfaces over classes
> (for similar reason as above), though I understand that being able to use
> "new ...()" syntax on things is nice too.
>

That is more than that:  https://groups.google.com/d/
topic/google-web-toolkit-contributors/L6uh96NcZtE/discussion


>
> 3. The number of callback classes is out-of-control. Can they be
> consolidated somehow?
>
>
Hopefully next release will cleanup plenty of them.


> 4. Also, is it possible to supplement the typing information for some of
> those callbacks from Typescript? Everyone knows that "onclick" handlers
> pass a MouseEvent. I'm not sure if Closure has a rich enough type system or
> is sufficiently well-developed to generate the best API there.
>

The language gap between TypeScript and Java is actually higher than
Closure and Java. That makes it harder to precisely mimic type info that
exists in d.ts via Java abstractions.

Hopefully we could make this work better over time.


>
> 5. Can there be some magic that makes elemental2.Iterable a real Java
> Iterable?
>

We can probably do something here. Will track that issue.


>
> Otherwise, it seems nice. I like that there's a NodeList now!
>
> --
> 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/ms
> gid/google-web-toolkit-contributors/cb2a997b-2d25-43c0-911a-
> ba13a448e14e%40googlegroups.com
> 
> .
>
> 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%3DyUA39_gq7ZyFujZsjq_YkOXP_T%3Dd42H64zpUcgm_BZJaLoA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Experimental release of Elemental2

[John Huss]

I agree about preferring "bean" style properties.  It's not a clear choice, 
but using bean style properties is more familiar to java programmers and 
makes the library fit in much better with the wider java ecosystem.  Also 
it would make conversions from elemental 1 much easier (though that is 
probably a very small group of users).

On Wednesday, February 15, 2017 at 3:05:01 PM UTC-6, Ming-Yee Iu wrote:
>
> Well, ok. Thanks.
>
> Just in terms of general feedback on Elemental2:
>
> 1. I'm not sure whether the conversion of JavaScript properties to Java 
> fields is the best choice. Sure, it "feels" more like the original 
> JavaScript, but a) it's inconsistent with Java semantics, b) I'd be afraid 
> that a Java compiler might apply some unexpected optimization there as a 
> result, c) it's harder to mock the behavior of the classes for unit tests 
> and d) alternate implementations of Elemental2 aren't possible (for 
> example, I couldn't make a DevMode-like JavaFx version of Elemental2 like I 
> did with Elemental 1).
>
> 2. Personally, I would prefer if Elemental 2 used interfaces over classes 
> (for similar reason as above), though I understand that being able to use 
> "new ...()" syntax on things is nice too.
>
> 3. The number of callback classes is out-of-control. Can they be 
> consolidated somehow? 
>
> 4. Also, is it possible to supplement the typing information for some of 
> those callbacks from Typescript? Everyone knows that "onclick" handlers 
> pass a MouseEvent. I'm not sure if Closure has a rich enough type system or 
> is sufficiently well-developed to generate the best API there.
>
> 5. Can there be some magic that makes elemental2.Iterable a real Java 
> Iterable?
>
> Otherwise, it seems nice. I like that there's a NodeList now!
>

-- 
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/10a89130-7d9a-4f48-8ab8-3387eefcab49%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Experimental release of Elemental2

[Ming-Yee Iu]

Well, ok. Thanks.

Just in terms of general feedback on Elemental2:

1. I'm not sure whether the conversion of JavaScript properties to Java 
fields is the best choice. Sure, it "feels" more like the original 
JavaScript, but a) it's inconsistent with Java semantics, b) I'd be afraid 
that a Java compiler might apply some unexpected optimization there as a 
result, c) it's harder to mock the behavior of the classes for unit tests 
and d) alternate implementations of Elemental2 aren't possible (for 
example, I couldn't make a DevMode-like JavaFx version of Elemental2 like I 
did with Elemental 1).

2. Personally, I would prefer if Elemental 2 used interfaces over classes 
(for similar reason as above), though I understand that being able to use 
"new ...()" syntax on things is nice too.

3. The number of callback classes is out-of-control. Can they be 
consolidated somehow? 

4. Also, is it possible to supplement the typing information for some of 
those callbacks from Typescript? Everyone knows that "onclick" handlers 
pass a MouseEvent. I'm not sure if Closure has a rich enough type system or 
is sufficiently well-developed to generate the best API there.

5. Can there be some magic that makes elemental2.Iterable a real Java 
Iterable?

Otherwise, it seems nice. I like that there's a NodeList now!

-- 
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/cb2a997b-2d25-43c0-911a-ba13a448e14e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Animating images in GWT

[Thomas Broyer]

To preload images:
img = Document.get().createImageElement()
img.setSrc(url)

(you could then keep all those ImageElement⋅s in a list and use them 
directly instead of setHTML)
You can use Image widgets too, which have load event handlers.

On Wednesday, February 15, 2017 at 1:33:37 PM UTC+1, Jonathan Cook wrote:
>
> I tried with a timer but the transition is a little slow the first time as 
> the images download. Is there some way to cache or download them into 
> memory before iterating them?
> // Create a new timer that iterates the images
>Timer t = new Timer() {
>   int counter = 0;
>
>   @Override
>   public void run() {
>  if (counter < imageUrls.size()) {
> iconPreviewHTML.setHTML(" get(counter) + "\"/>");
>  }
>  counter++;
>   }
>};
>// Schedule the timer to run once in x seconds.
>t.scheduleRepeating(500);
>
>
>
>

-- 
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: Animating images in GWT

[Kirill Prazdnikov]

Use can use requestAnimaionFrame, as we do. (https://studio.cospaces.io)  It 
has exact and precise timing information in the argument

-- 
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: Animating images in GWT

[Jonathan Cook]

I tried with a timer but the transition is a little slow the first time as 
the images download. Is there some way to cache or download them into 
memory before iterating them?
// Create a new timer that iterates the images
   Timer t = new Timer() {
  int counter = 0;

  @Override
  public void run() {
 if (counter < imageUrls.size()) {
iconPreviewHTML.setHTML("");
 }
 counter++;
  }
   };
   // Schedule the timer to run once in x seconds.
   t.scheduleRepeating(500);



-- 
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: Problem compiling GWT code with Java9

[Thomas Broyer]

On Wednesday, February 15, 2017 at 10:17:30 AM UTC+1, Dave Bradlee wrote:
>
> Anyway, has anyone else tried to compile GWT code with Java9? Or any ideas 
> how we might make the compiler happy?
>
>
I hadn't tried until now, but have the exact same error with 9-ea+152 
(using package oracle-java9-installer from webupd8 on Ubuntu 16.10) on a 
simple hello-world project (that compiles OK with Java 8).

Trying to run GWT's own test suite with Java 9 might possibly help 
understand where the problem comes from.

-- 
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: Problem compiling GWT code with Java9

[Jens]

I think it is more a class path / module path issue than a unitCache issue 
(you can always delete the unit cache or don't use it at all by disabling 
it on the command line). I guess GWT Compiler simply does not see 
Core.gwt.xml even though you have inherited it.

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

Problem compiling GWT code with Java9

[Dave Bradlee]

At Labkey.com we're trying to compile all of our code, which includes GWT 
code, with Java9 (due for release in the summer)getting a head start. 
We have not been able to compile GWT code, which doesn't use any new Java 
features. We're getting the error
 [java] Compiling module org.labkey.experiment.property.Designer
 [java][ERROR] Unable to find type 'java.lang.Object'
 [java]   [ERROR] Hint: Check that your module inherits 
'com.google.gwt.core.Core' either directly or indirectly (most often by 
inheriting module 'com.google.gwt.user.User')

We've had an older version of GWT but have tried with the latest 2.8 as 
well and get the same thing. I've added -logLevel=DEBUG to get more info 
and the log says we're inheriting all of the appropriate packages, 
including com.google.gwt.core.Core and com.google.gwt.emul.Emulation, which 
of course is where java.lang.Object lives. It seems like something is going 
wrong with gwt-unitCache because the log looks like this:
..lots of inherits before this..
 [java]   Module location: 
file:/Users/davebradlee/trunk/server/internal/gwtsrc/org/labkey/api/gwt/Internal.gwt.xml
 [java]   Loading inherited module 'com.extjs.gxt.ui.GXT'
 [java]  Module location: 
jar:file:/Users/davebradlee/trunk/external/lib/build/gxt.jar!/com/extjs/gxt/ui/GXT.gwt.xml
 [java]  Loading inherited module 'com.google.gwt.json.JSON'
 [java] Module location: 
jar:file:/Users/davebradlee/trunk/external/lib/build/gwt-user.jar!/com/google/gwt/json/JSON.gwt.xml
 [java]   Loading inherited module 'com.allen_sauer.gwt.dnd.gwt-dnd'
 [java]  Module location: 
jar:file:/Users/davebradlee/trunk/external/lib/server/gwt-dnd-3.2.0.jar!/com/allen_sauer/gwt/dnd/gwt-dnd.gwt.xml
 [java] Public resources found in...
 [java] Translatable source found in...
 [java] Persistent unit cache dir set to: 
/Users/davebradlee/trunk/build/modules/experiment/explodedModule/gwt-unitCache
 [java] Opening cache file: 
/Users/davebradlee/trunk/build/modules/experiment/explodedModule/gwt-unitCache/gwt-unitCache-6a094daf5d20bb65adf2d207cc48308bde849f64-015A3E41072B
 [java] Looking for previously cached Compilation Units in 
/Users/davebradlee/trunk/build/modules/experiment/explodedModule/gwt-unitCache
 [java] Compiling module org.labkey.experiment.property.Designer
 [java]Found 0 cached/archived units.  Used 0 / 0 units from cache.
 [java]Compiling...
 [java]   Compilation completed in 0.00 seconds
 [java]PersistentUnitCache cleanup requested
 [java]Added 0 units to PersistentUnitCache since last cleanup
 [java]Skipped PersistentUnitCache because no units were added
 [java]Removing invalidated units
 [java]Resolving enclosing classes
 [java]Tracing compile failure path for type 'java.lang.Object'
 [java]   Checked 0 dependencies for errors.
 [java][ERROR] Hint: Check that your module inherits 
'com.google.gwt.core.Core' either directly or indirectly (most often by 
inheriting module 'com.google.gwt.user.User')
 [java] Closing cache file: 
/Users/davebradlee/trunk/build/modules/experiment/explodedModule/gwt-unitCache/gwt-unitCache-6a094daf5d20bb65adf2d207cc48308bde849f64-015A3E41072B
 
(0 units written)
 [java] Deleting empty file: 
/Users/davebradlee/trunk/build/modules/experiment/explodedModule/gwt-unitCache/gwt-unitCache-6a094daf5d20bb65adf2d207cc48308bde849f64-015A3E41072B
 [java] Shutting down PersistentUnitCache thread

Using Java8 the log looks like this
...
 [java] Persistent unit cache dir set to: 
/Users/davebradlee/trunk/build/modules/experiment/explodedModule/gwt-unitCache
 [java] Opening cache file: 
/Users/davebradlee/trunk/build/modules/experiment/explodedModule/gwt-unitCache/gwt-unitCache-6a094daf5d20bb65adf2d207cc48308bde849f64-015A3E53CB49
 [java] Looking for previously cached Compilation Units in 
/Users/davebradlee/trunk/build/modules/experiment/explodedModule/gwt-unitCache
 [java] Compiling module org.labkey.experiment.property.Designer
 [java]Found 0 cached/archived units.  Used 0 / 3794 units from 
cache.
 [java]Compiling...
 [java]   60% complete (ETR: 3 seconds)
 [java]   60% complete (ETR: 3 seconds)
 [java]   60% complete (ETR: 3 seconds)
 [java]   60% complete (ETR: 3 seconds)
 [java]   60% complete (ETR: 3 seconds)
 [java]   60% complete (ETR: 3 seconds)
 [java]   60% complete (ETR: 3 seconds)
 [java]   70% complete (ETR: 2 seconds)
 [java]   80% complete (ETR: 2 seconds)
 [java]   90% complete (ETR: 1 seconds)
 [java]   100% complete (ETR: 0 seconds)
 [java]   Compilation completed in 10.80 seconds
 [java]PersistentUnitCache cleanup requested
 [java]Added 3794 units to PersistentUnitCache since last cleanup