- Java 8 is already generally available on GAE standard and, on top of that, previous limitations wr/t class whitelisting, threading capabilities and others have been lifted
- appcfg is pretty much outdated these days; all GAE management operations have been progressively integrated into gcloud app subcommand, which also fully supports newer GAE features like Flex, firewall rules, etc.
- GAE standard instances are indeed limited in computing power, but it should be enough for most web-based applications. Again, GAE Flex fills in the gap here in case more muscle is needed, since it leverages GCE-class instances
- Besides the already mentioned background work options (background threads, task queues, cron jobs), there's also Pub/Sub which can be used to inter-communicate GAE services or even other GCP services like GCE or GKE
Slow adoption of new Java versions is a pretty big downside. Even if you are satisfied using Java 8 on GAE today, you may want to use Java 9 in the near future, and you won't be able to. By choosing GAE you are committing yourself to being stuck with Java 8 for a long time.
Also, not having access to Java 8 was painful. Not being able to use lambdas or streams for that long really sucked. There's no similar pain from not having access to Java 9 yet; it's not nearly as big of a change in the language.
> it's not nearly as big of a change in the language
True, but there were quite dramatic changes to the JDK.
Disclaimer I work on GAE.
We do monitor the public issue tracker (https://issuetracker.google.com/savedsearches/559750) and will prioritize appropriately according to vote number.
Tack this on as one of the reasons people don't trust google cloud...
No more information from users is needed to implement it, so the only useful comments can come from Google employees who can still comment.
This is standard procedure on Google bugtrackers.
for me that is a big blocker.
Is it that volatile that they don't want to go public with their intentions? That's not really a good sign, IMO.
*(Just one of many reasons not to use Java on the JVM in general)