In other words, this exploit requires: knowing what cryptographic software is being run, the presence of Xen and an apparent security hole therein, and lucky core colocation of the VMs in an environment that could easily have dozens of VMs running against more than a dozen cores "over the course
of a few hours".
In short, all of this is unlikely to be reproducible outside of a lab.
Android is
As an enterprise infrastructure technologist, I can tell you that Java is very much alive. With or without Android, it is not going anywhere anytime soon.
In 2006 or so I went to a conference in Redmond (WinHEC, I believe) where one of Microsoft's security team managers presented and overview of the virus threat to the desktop market. One of the things Microsoft had recently learned is that the majority of exploits were coming from hackers that had reverse engineered Windows patches to identify where Microsoft was correcting buffer overflow issues. Based on that knowledge, hackers knew un-patched versions of Windows could be exploited.
The strategy at MSFT became somewhat simple at that point: minimize the time between a security update's release and its application on 100% of networked computers. The presenter could show that MSFT had brought this average time down from months to weeks back then. Its clear to me that Microsoft has continued to make gains in this space over the years.
Lastly, the presenter showed that the exact same process applied to Linux. Few hackers find vulnerabilities to poring through an entire operating system's code base. They reverse-engineer patches and then hunt for un-patched systems. Microsoft claimed to be ahead of Linux in their ability to mass-apply security patches and he showed results that a Linux honeypot would be compromised slightly quicker that Windows, although not significantly so. I found the author credible in his data but recognize that he had an agenda with his presentation.
Saliva causes cancer, but only if swallowed in small amounts over a long period of time. -- George Carlin