Use Java8 features in APIs now

[jboynes]

There have been a couple of issues recently where more elegant solutions could be provided using features from Java 8. These have included

• use of lambda functions for datastore transaction
• direct use of standard function classes rather than Guava equivalents
• use of new Time classes
• use of Optional rather than JSR-305 annotations

To do this we would need to raise the minimum JDK version from 7 to 8 which cause may problems for users who still use older Java runtimes. However, Oracle have already EOLed their public version of Java 7.

The main advantage of doing this now rather than waiting is that it avoids needing to rev a new version of the API to make use of these idioms and avoids having to support two API versions.

[ludoch]

We want to move asap to Java8, given the constraints we have:
1/ App Engine V1 is still only on Java 7
2/ Managed VM V2 is still on Java 7 with optional customization for Java 8
3/ Android clients?
4/ Customer constraints... I've heard this week that in the GRPC/BigTable/HBase area that Hbase has issues with Java 8 and requires for now a Managed VM Java 7 only. Things are progressing, but we need to be cautious there to not hurt possible customers in Q3/Q4.
5/ Other Google internal constraints.
Once we are clear of these points we will move to Java 8. At that point, we ideally would have an Android story.

Do we know when Guava is moving to Java 8?

[jboynes]

We won't be going GA with this API for a few months, will those internal issues be resolved by then? In the meantime AppEngine users can continue to use the existing appengine APIs so they would still be able to use the underlying services.

The nicer, Java8-dependent version could still be used for development (on desktop), on GCE or other compute environments, and on AppEngine Managed VMs with a custom runtime.

Android seems like a different beast in many ways. We might be better having a separate, optimized for Android library - gcloud-android perhaps.

[ludoch]

We are talking months, not years:-)... But
Existing App Engine customers need/want Storage APIs, or PubSub APIs, etc,...and explore the new world (shared apps/modules between V1 and V2 is a very common scenario for V2 customers).
Meanwhile, I prefer the keep HEAD on Java7 and this is helping as well the Android side.
At some point of time, where we have more APIs support, more stability, more usage and more feedback, we can handle the dual support, Java7: mostly for Android and legacy gcloud-java for hardcore Java7 users, and Java8. We are not setup yet for this mode, but are working toward this..

[jboynes]

If it's months then it does not sound like we have a problem as release of this API would coincide with when the AppEngine issues would be fixed. And everyone not using AppEngine would get the benefits immediately.

By using newer features now is that we will defer having to support multiple versions until Java 9 (or possibly even longer given the Java 9 focus on modularity rather than language features) - IOW, not for several years. We'd be offering the API everyone seems to wish to offer now rather than later.

[lesv]

+1 We should find a way to include J8 idioms and still run on J7 (without those API's.)

[garrettjonesgoogle]

I think there will be less churn if we just stick to Java 7 idioms until we are cleared for Java 8. Closing this issue now because it's stale.