Request for Java 8 support on Google App Engine
code.google.com
code.google.com
The past model for AppEngine involved some pretty heavy development work modifying the JVM and Python VM to implement multi-tenant sandboxing. This obviously doesn't scale very well from a development perspective, and shows why new platform versions have always lagged far behind release.
If I were to infer what they are doing internally now, it would be replacing "legacy AppEngine" with "container AppEngine". In a few years you'll see them migrate everyone to containers that will scale in unsurprising ways to users of AppEngine today.
The reason they haven't moved everyone over to containers is that the dev experience for containers on AppEngine sucks horribly right now and they want it to be at least as seamless as it is for Python and Java right now. They also need to migrate 100% of the legacy AppEngine console functionality over to the new cloud dashboard before they could consider this complete.
So my guess is that AppEngine as we know it is "dead", but being replaced by a product that is a pure superset of what we have today.
It's deeply frustrating at times. They are often unresponsive on many fronts. I certainly hope they are fixing the platform... or fixing something, at least. That'd be refreshing.
The fact that in addition to support for custom runtimes, App Engine Managed VMs has Google-provided VMs corresponding to all of the existing supported sandboxed runtimes except PHP is, I think, a pretty good indication that Google's plan for official runtimes going forward is to move them to official Managed VMs rather than what you seem to be calling (accurately, I think) "legacy App Engine" -- the sandboxed platforms.
But all the signs are, IMO, there that this, while it may take a while, the same kind of transition that the move off the old legacy datastore was, something that's optional while it the new platform matures, but eventually will be the only way.
http://www.ibm.com/developerworks/library/j-multitenant-java...
I work in Product Management on App Engine, and I'd like to assure you that we're continuing to invest in the product. We already support Java 8 in beta on Managed VMs (https://cloud.google.com/appengine/docs/managed-vms/), and the same is true for Python 3. Once Managed VMs goes GA, we expect that most of our customers will find that it provides all the benefits of App Engine with increased flexibility around the programming language, native code, etc.
Thanks,
- Navneet
I'm in the process of building my second business on top of App Engine. The autoscaling, datastore and lack of devops are killer features.
I'm looking forward to migrating to managed vm's when they are closer to GA. Right now, they are just too alpha quality for me.
Keep up the good work.
As much as you may hate supporting them, they will cause a PR headache if you stop.
The more I use it (and see minimial improvements), the more I'm sure AppEngine is a stale project, kept alive by the potential wrath of the internet if they canned it.
[edit] I'll give them credit, They've redone the console. But it's terrible. And you still need the old one to do things such as turn on cloud-storage.
App Engine is very far from dead, either in the "time to turn off the service" or the "it's destaffed but the servers still run" use of the term. App Engine is well-staffed and, AFAICT, is actually growing. They're working extremely hard on getting system reliability to a place where they want it to be. [1] seems to indicate the fruits of that labor, paying off in the last month or so. Now, reliability means reliable for _all_ their customers, from the one person bedroom coder to SnapChat. They have had a big task meeting the requirements of everyone.
I can't talk to the bug triaging system of App Engine nor their future plans. That said, work continues apace to get Managed VMs [2] out of beta, and it seems like a pretty exciting new road which may be a custom better fit for larger companies.
[1] https://status.cloud.google.com/summary [2] https://cloud.google.com/appengine/docs/managed-vms/
They update the SDK quite regularly: https://code.google.com/p/googleappengine/wiki/SdkReleaseNot...
They rarely handle bugs well. The linked issue is typical. They don't even need to do any work to do a whole lot better; they just need to give developers an indication about what to expect. That does mean that they need to make decisions internally, which might be the problem. Potentially, management is umm'ing & arr'ing about whether to kill App Engine.
They recently threw a bit of a contribution in the direction of AppScale, but it's difficult to read that. It could be to soften the blow in the event of discontinuation, or it could be to remove the perception of App Engine as a service with no alternative.
There have also been new features recently introduced, albeit projects that seem like they should have lower prioritization than ensuring folk can use SSL with App Engine, or use modern versions of their programming language. For example, this recent addition: http://googlecloudplatform.blogspot.com.au/2015/02/using-goo...
My reading of the situation is that Google Cloud folk have resources (headcount) to do routine maintenance on App Engine, but not embark on any infrastructural advancements, like new versions of Python & Java, or significant new functionality.
Sounds like their answer for Java8 is probably the same for Python3:
"To echo comment #66, App Engine in fact is not going away. To the contrary, we're investing heavily, and the new hosting environment that is based on containerized virtual machines (what we're currently calling "App Engine Managed VMs") allows you to utilize Java 8 as well as Servlet 3.x."
This is no longer correct. As a long-time GAE user, I was one of the last holdouts on the old console. Recently, however, I spun up a large new project - and discovered that I haven't needed (or wanted to use) the old console at all. Including for GCS.
The new console is vastly more usable than the AWS console, and significantly more useful than Heroku's. Just the logging system alone is priceless.
webapp2 was started outside of Google by Rodrigo Moraes, who has since moved on to other projects. Googlers have contributed to the webapp2 but have never taken the lead.
There are probably dozens of WSGI-compatible web frameworks that are under active development and you can choose any one that you like.
The only niggle is that when you set your IDE to Java 8 (be it Eclipse or IntelliJ) it exposes Java 8's new methods - and allows those on our desktop machine builds. We've been caught out a few times as it compiles just fine for Android, then explodes at runtime on device - but never anything that didn't get caught in QA. If you just want the lambdas and method referencing, it's wonderful.
Curiously, we do get crash reports coming in from select Android devices that still don't have some of the standard library from Java 7 implemented. That catches us out in production more often but, fortunately, it looks like >99% have no issue with 7.
I'm going to try this out.
We use Gradle to do our real builds; CI and to devices at our desks. And we just use Eclipse set up to run with Java 8 for everything else. Once it's setup, it's pretty seamless, we haven't had to think about it for a long time.
Always a catch.
plugins {
id "me.tatarka.retrolambda" version "3.1.0"
}
Probably more complex using an IDE (rather than pure gradle).
It's not so bad, I was just trying to come up with negatives -- we've made the mistake of pushing something to a device with the bad APIs perhaps 4-5 times in a year.
* Cassandra - supports JDK8, docs only referenced 7 (I contacted DataStax)
* Elasticsearch - explicitly mentions exactly what JDK 7 & 8 versions are supported. Yay!
* Kafka - Docs only mention 7. Scala incompatibilities prevent all but the latest version from ever using JDK8 (without manual patching): https://issues.apache.org/jira/browse/KAFKA-1624
* Zookeeper - Only mentions "JDK 6 or up" so... yay? Seems to work as promised.
Point being: Only 1 out of 4 major Java services even bothered explicitly mentioning Java 8 support (ES) -- and it doesn't even discourage use of the EOL'd 7.
Java is a complex ecosystem. I think a JDK being EOL'd means something different in the Java ecosystem then it does to the rest of us.
The problem is that bugs in the JDK itself will no longer be fixed in v7; Oracle's line is (reasonably) "you should update to JDK8, all your code will work fine".
I would definitely NOT say that the Java community isn't too concerned with JDK7 EOL. No responsible developer is going to run a network-facing application on an EOL unpatched JVM as it's a security risk (unless you fork out for a support contract for older versions).
JDK Forward compatibility makes this mostly a moot point for the lib developers. Upgrading your JDK is your own responsibility, the rest is expected to just work.
https://code.google.com/p/googleappengine/wiki/SdkReleaseNot...
Given the focus on other cloud products (like being able to run Docker images) I would be surprised if Google continued to add new features to GAE. It seems like it's growing cobwebs...
I actually like GAE as a concept, but I had a very bad experience with their Google Cloud endpoints: bad documentation, bad tooling and bad bugs. Even when I got it up and running to implement a custom authenticator was a mess and the performance wasn't what I'd expect. This got much better, especially with the official Maven plugin: but I'm really concerned that Google aren't 100% behind GAE and development could cease at any moment.
An official statement would be good. But like so much at Google it's not forthcoming.
GAE for me is a nice lesson to not rely on closed source solutions, where I can't go and fix mission critical stuff myself. I've got confirmed bug reports over 4 years old that still aren't fixed [1], and I got serious deadlock bugs on Windows over a year old, that got applied low priority with the recommendation to use another OS. [2]
In general I really like GAE, but the complete lack of support & dedication from Google and the shifting of resoures to other products makes me sad.
[1] https://code.google.com/p/googleappengine/issues/detail?id=4...
[2] https://code.google.com/p/googleappengine/issues/detail?id=1...
Yes. I'm one of them, and I keep coming back to it. The short answer for why is that no matter what you think of it, GAE delivers on one basic promise: No ops/devops. I've scaled applications to thousands of QPS with teams of one or two people, and I never even had to adjust the # of instances (scaling is automatic). I've never had to worry about the database getting overloaded. It's just "write code and deploy".
Out of curiosity, what cloud provider interface do you think is better? Certainly not AWS. And which limitations do you consider so drastic?
That said, even "as-is" without any major changes on the horizon, GAE is pretty solid. My only major complaint right now is Java8, but given the choice between suffering with Java7 for another year and hiring an ops staff, I'll pick the former. I had to make "the platform" choice again just a couple weeks ago for a new startup, and still picked old-style GAE - not even the new Managed VMs, which I don't think are reliable enough yet.
Naked domains aren't an itch of mine, apparently.
The big unknown for me is how usable any of those implementations are, and whether there is such a thing as a decent migration path (for data) from Google to them, and vice-versa.
The overhead required to fit what you are serving to fit within App Engine isn't major. With a lot of other systems you have a lot of infrastructure type issues that you have to deal with. What it costs on setting up App Engine, you save on configuring a different system.
You are not going to get App Engine to do what you would normally use for a server and yes it is limited.
App Engine appears to have ceased new development and is now moving toward managed VMs. https://cloud.google.com/appengine/docs/managed-vms/
There are a lot of good and bad tools and technologies. App Engine is a great tool for some things but useless for others.
Google has also broken backwards compatibility multiple times, forcing me to spend time just to keep the apps running.
For your really small hobby app.. its a pain sometimes to deal with all the config.
For a real app with real traffic, you want to scale in different ways. What you can do with dockr and a bunch of VMs gives you a TON of flexibility.
I know a few people with apps on App Engine.. I used it myself for a toy project. It's "ok".. but compared to buying a $5 digital ocean VM and getting a real server for less money? Makes no sense if you know linux at all.
Even if you can match Google's efforts in doing all that, why would you want to waste your time doing that maintenance work rather than working on your application itself?
Docker VMs are an appealing concept to me, but it occurs to me that I would be dependent upon some third-party that I know very little about to release an updated image whenever something in the stack needs to be updated. Additionally, I need to be involved in that deployment. With App Engine, Google have my code, so they update the image and my code is always running in a VM that ought to be far more bullet-proof than I could manage. (even with some Linux knowledge)
but given that java 7 is getting EOL'ed, there will be no more security patches for it. So how do you expect their jvm is secure? The basis for google's ability to patch better than yourself is pure faith.
That said, I'm assuming their JVM is still secure despite being old. Oracle are EOLing their Java 7 JVM, but that doesn't directly affect App Engine unless that's the JVM Google are using. The indirect effects are inexcusable, though. That developers need to stick to an old language to use App Engine while the rest of the world has moved on is ridiculous.
2. Google's given what seems to me to be a pretty clear signal that managed VMs are the future of app engine; if expect new official runtimes to be delivered that way once managed VMs are out of beta.
My later appengine projects wlll be all golang based.
Software development in a nutshell, these kind of stories just keep repeating, python 2vs3, C99 in MSVC, etc etc. I guess i should just stop pretending that a new version has been released until 5 years after the actual announcement.
Either make new versions of Java 100% backwards compatible, or support them for a long time. The end.
-John
Code written for Java 7 runs perfectly on Java 8. Code that uses new Java 8 features doesn't run on Java 7 though, because those features didn't exist then. You upgrade the Java runtime to Java 8 and then it supports the new features. Simple, no?
We have a project three months on so far making our Java7 code work with Java8.
We have several products that use the JVM from various vendors stuck on Java6 because it won't run on Java7 or Java8.
What crazy thing were you doing that required a 3+ month rewrite?
e.g.
for(Object a:list){
a.doSomething();
}
for (int i:i<list.length();i++){
list.get(i).soSomething();
}
Iterator iter = list.iterator();
while(iter.hasNext() {
iter.next().doSomething();
}
Oracle did nothing wrong, the programmer only partly overriding the list implementation was broken. This kind of programmer error is too common and is normally the reasons that upgrades become an issue, i.e. its the equivalent of using undefined behaviour in C and then scream when your compiler upgrade burns down your house.
At any rate, all of the java 6/7 code I've ever had has ported to java 8 without any changes. Assumed it was the normal experience.
Ummmmmmmm...no. Why do you think (paid) maintenance options exist?
Is it really Oracle's fault?
I don't know if they care. At some point, people will rebel, but I can't predict where that tipping point is.
JVM however is a different matter.
Declaring a product "end of life" is utterly meaningless to every entity that does not pay you to support the product. You can declare whatever you'd like; people will stop using it when they're done using it.
That's about as far from "meaningless" as it gets on the modern Web.
So, yes, it is important to the vast majority of using Java except maybe you and that's great but you're being That Guy.
No, they're going to just sit on an unsupported VM, which was my original point. All the theater about pretending that Oracle have any effect on these decisions is ludicrous, no matter how huge a majority you pretend to speak for, nor no matter how much ad hominem you ladle onto your replies.