Java8 emulation

[Jens]

Hi,

whats the current situation of adding Java8 emulations to GWT?

I would like to fix the current emulation of @FunctionalInterface (wrong package and missing imports), add java.util.Optional[Int|Long|Double] emulation and like to see java.util.function interfaces in trunk committed. That would allow us to further work on stream API emulation which would be nice to have in GWT 2.8, right? Just having Java8 syntax support seems a little weak to me for a new release.

Currently my patch for java.util.function can not be verified by Jenkins because it runs the presubmit task with sourceLevel 1.7 (and Java7 I think). So I assume that the next GWT release should be compatible to Java7.

Does this mean that any emulation of Java8 APIs should be done using Java7 syntax ( = no lambdas in emulation code) ? What about default methods in emulated code when people use JDK 7 with GWT?

So how should Java8 emulations be contributed?


-- J.

[John A. Tamplin]

On Wed, Mar 25, 2015 at 11:16 AM, Jens <jens.ne...@gmail.com> wrote:

whats the current situation of adding Java8 emulations to GWT?

I would like to fix the current emulation of @FunctionalInterface (wrong package and missing imports), add java.util.Optional[Int|Long|Double] emulation and like to see java.util.function interfaces in trunk committed. That would allow us to further work on stream API emulation which would be nice to have in GWT 2.8, right? Just having Java8 syntax support seems a little weak to me for a new release.

Adding new classes should be pretty straightforward.

 

Currently my patch for java.util.function can not be verified by Jenkins because it runs the presubmit task with sourceLevel 1.7 (and Java7 I think). So I assume that the next GWT release should be compatible to Java7.

Does this mean that any emulation of Java8 APIs should be done using Java7 syntax ( = no lambdas in emulation code) ? What about default methods in emulated code when people use JDK 7 with GWT?

That would be my vote - we don't want to force people to use Java8 just yet.

--

John A. Tamplin

[Colin Alworth]

The trick seems to be that it is not going to be possible to add Java8 emul code without actually using Java8 - while lambdas can be avoided, defender methods cannot. If you need to provide a new interface like Consumer, the supersource *must* have the `default` method(s), or it won't actually be Consumer. 

If it were just those types, it would be possible to move them into their own module so developers would need to inherit's the Java8 module to get access to them, but the Collection interface itself needs to be changed to add `default Stream<E> stream()`, plus the implementation, or else all implementors of Collection (and Set and List) need to have an implementation added. Even then, Stream would need to be emulated, which references Consumer, so we can't have it be a separate module...

...or am I over-complicating matters?

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

[John A. Tamplin]

On Wed, Mar 25, 2015 at 11:33 AM, Colin Alworth <nilo...@gmail.com> wrote:

The trick seems to be that it is not going to be possible to add Java8 emul code without actually using Java8 - while lambdas can be avoided, defender methods cannot. If you need to provide a new interface like Consumer, the supersource *must* have the `default` method(s), or it won't actually be Consumer. 

If it were just those types, it would be possible to move them into their own module so developers would need to inherit's the Java8 module to get access to them, but the Collection interface itself needs to be changed to add `default Stream<E> stream()`, plus the implementation, or else all implementors of Collection (and Set and List) need to have an implementation added. Even then, Stream would need to be emulated, which references Consumer, so we can't have it be a separate module...

...or am I over-complicating matters?

Well, certainly there are things which will require further support in GWT and in the build, but things like adding j.u.Optional can be done without that.

--

John A. Tamplin

[Roberto Lublinerman]

I think we make run presubmits with Java 8. AFAIK presubmit only build the compiler (to see that is buildable) and run checkstyle. We will still run our main continuous build in Java 7 and there is an alternate continuous build with Java 8 (which is now broken).

Can someone look at those failures? Internally apart from the 2 failing tck tests (which we could disable until we upgrade validation) all the others are passing. 

I am not sure why 

--

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/CAM5k6X_k%2BwvoH_a_YquYcxY-uzbL%3DdANNn5eGZZJUombafbKBA%40mail.gmail.com.

[Jens]

I think we make run presubmits with Java 8.

Ok but then it is still with sourceLevel 1.7 by default. Here [1] is a presubmit log from february that complains about lambda, default methods and static interface methods.

But that is just job setup in Jenkins. Its more interesting how to contribute emulation code that requires Java 8. Should GWT provide user/super/com/google/gwt/emul and user/super/com/google/gwt/emul8 and then let ANT produce two gwt-user libs? I am pretty sure you have already talked about that offline and have some ideas...

[1] http://build.gwtproject.org/job/gwt.presubmit/40/console

-- J.

[Goktug Gokdogan]

For Java8 emulation, what is my mind is to have Jens patch and have collection API improvements (Streams) to be available. There are few issues and steering committee is discussing (or will discuss) about it.

See the discussion in https://groups.google.com/d/topic/gwt-maintainers/X6WnH3C-nzg/discussion

For some reason that discussion doesn't seem visible to everyone but in short we are planning to make Java8 only release with an option for community to make it work with java7.

Here is related part rephrased:

----------------------

For supporting java7, the deprecated but not dropped dev-mode is the source of the problem (java8 emulation doesn't compile with java7, so we compile with java8 mode which produces byte code incompatible with java7 VMs).

There are three ways to make it work:

1- The community can extract the java emul from 2.7 release and bundle it with 2.8 (we didn't remove the source-level flag yet to keep this as an option for the community).

2. Somebody can contribute a byte code rewriter that re-writes java8 byte-code as java7 by re-purposing retrolambda.  It doesn't need to be perfect as the user-code will only use java7 features (I thinking this is the cleanest one).

3. I don't remember if I have tried hard enough to force java7 compile with devmode; but if somebody is interested, he/she can a look at this one as well (i.e. set sourceLevel to 7 in dev-mode and try to make that work).

All of these all assumes that user code is kept java7 compatible and trying make GWT 2.8 work in java7 VM environment. If the developers just upgrade VM in developer workstations to a Java8 VM (upgrading to Java8 SDK is NOT required), none of these is needed so I think the community doesn't need to bother with it. However if there is enough demand and interest from the community, they could take one of the options to make the 2.8 a java7 compatible release.

--

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/5dbe5f39-9683-4529-84ca-fe715564755f%40googlegroups.com.

[Jens]

Can someone look at those failures? Internally apart from the 2 failing tck tests (which we could disable until we upgrade validation) all the others are passing. 

Has anyone figured out whats wrong with that Java8 build on jenkins? I can't reproduce it locally (Mac + Oracle JDK and Ubuntu + Oracle JDK) and the code that fails looks totally fine. I can't imagine how this failing assertion could ever be triggered unless the byte code is broken.

Could it be caused by the Java8 version that is used? Seems like it's a custom build as it contains a "-internal" suffix so maybe try an official version instead?

-- J.