GWT 2.8.0 forEach, Consumer, Function, Streams and other Java 8 stuff

[Ivan Hetman]

Hi. I used GWT 2.8.0-SNAPSHOT to try it on my projects to reduce boilerplate code. But I was confused when I tried listeners.forEach() and compiler said that there is no such method in Set (i. e. Iterable). Also as i noticed, default methods or class::method work. But there are no streams, consumer/producer interfaces. I dived into sources and noticed that there is no implementation for this methods/classes.

What is status of Java 8 collection interfaces/methods for GWT 2.8? Or there are no plans to include them into GWT 2.8.0?

[Thomas Broyer]

On Thursday, June 11, 2015 at 2:58:09 PM UTC+2, Ivan Hetman wrote:

Hi. I used GWT 2.8.0-SNAPSHOT to try it on my projects to reduce boilerplate code. But I was confused when I tried listeners.forEach() and compiler said that there is no such method in Set (i. e. Iterable). Also as i noticed, default methods or class::method work. But there are no streams, consumer/producer interfaces. I dived into sources and noticed that there is no implementation for this methods/classes.

What is status of Java 8 collection interfaces/methods for GWT 2.8? Or there are no plans to include them into GWT 2.8.0?

The problem is that we cannot add Java 8 features to the Java runtime emulation while still supporting -sourceLevel 7.

So for now you can use the Java 8 language, but not the Java 8 APIs.

[Ivan Hetman]

Hi Thomas, thanks for the answer.

You can compile java even 1.2 source code with JDK 1.8, so what is the problem with compiling Java 7 source with GWT for Java 8 emulation? Interfaces also should not be broken because of default methods in interfaces (that can just be ignored in sourceLevel < 8). Can you give example that describes the problem, please?

четвер, 11 червня 2015 р. 16:10:23 UTC+3 користувач Thomas Broyer написав:

[Jens]

You can compile java even 1.2 source code with JDK 1.8, so what is the problem with compiling Java 7 source with GWT for Java 8 emulation? Interfaces also should not be broken because of default methods in interfaces (that can just be ignored in sourceLevel < 8). Can you give example that describes the problem, please?

It is impossible to emulate certain Java 8 APIs without using Java 8 syntax (e.g. default methods on Collection interface). But if you launch GWT with -sourceLevel 1.7 then all Java 8 syntax is invalid and the emulated code that require Java 8 syntax will not compile.

That means we either 

- do not support Java 8 APIs in GWT 2.8 because we still want to support -sourceLevel 1.7, or

- GWT 2.8 will be Java 8 only and if you want to use it with -sourceLevel 1.7 you have to replace all emulated JRE code with the one of GWT 2.7 yourself

-- J.

[Thomas Broyer]

You cannot use "classic" DevMode with a Java 7 JVM and -sourceLevel 8, and that includes GWTTestCases (unless run in prod mode); so forcing sourceLevel 8 would mean requiring Java 8, and because of issues with using a Java 8 JDK while targeting a Java 7 runtime JVM, this is not something we can do today (most build tools, moreover, have rather bad support for multiple "toolchains" in the same build, which would require builds to be split in several "steps" each invoked with its own JVM)

[Ivan Hetman]

Thanks, got it. But why don't release special GWT 2.8 version with source level 1.8 only? Without improved collection API Java 8 benefits in GWT are low.

четвер, 11 червня 2015 р. 23:59:09 UTC+3 користувач Thomas Broyer написав:

[Thomas Broyer]

On Monday, June 15, 2015 at 3:49:10 PM UTC+2, Ivan Hetman wrote:

Thanks, got it. But why don't release special GWT 2.8 version with source level 1.8 only? Without improved collection API Java 8 benefits in GWT are low.

You can write lambdas and use defender methods in your own interfaces, that's not nothing.

Re. a special Java-8-only version of gwt-user, one of the main issues which has still not been solved is that of dependency managers relying on Maven metadata (most dependency managers). Gradle is apparently working on it https://discuss.gradle.org/t/variant-aware-dependency-management/115, and I think Ivy has it for years, but it's not there yet (particularly for Maven users).

[Pablo Nussembaum]

Thomas is rigth, using lambdas is are really game changer for subscribing (you have 6 lines less on each one) to handlers and also you can use guava Optional class and functional idioms until idioms until we have fully java8 streams.

Be aware that current GWT-2.8.0-SNAPSHOT compiler doesn't support mixing inner-classes and lambdas.

--
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-tool...@googlegroups.com.
To post to this group, send email to google-we...@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

[Ignacio Baca Moreno-Torres]

IMO, stream API is totally replaceable (almost unnecessary), 80% of your uses cases can be solved with lamdas + Guava FluentIterables, and for advanced use cases libraries like RxJava (or whatever implements reactive streams interfaces) or IxJava are much more advanced and easy to extends. Not sure, but looks like stream API has an over complexity to improve performance on parallel computing which is not very useful in javascript.