You said to describe the product from the perspective of the user, not the developer, but then you preferred the developer description of Java (language, library, VM) over the user description (play games, chat with people, view images in 3D). It does seem like your average person landing on the Java page cares more about the second list. I mean, what the hell is a virtual machine anyway?
I'd say there should be two different pages: one for end-users, and one for developers. In his defense I'd argue the users of Java are developers, in which case they need to know specifically what it is. For end users who need it installed on their machines, the description should be "Java is a necessary plugin to make many of your favorite applications work correctly."
In the case of other tools, a lot of companies focus on useless buzzwords like "it's a cloud-enabled multi-tier architecture et cetera" instead of focusing on what the person using it cares about: "it's a content management system for blogs." OK, got it.
Seems to me that Java's users are developers. No non-developer will ever install Java by itself, they'll only install it because something else they're installing requires it.
As a systems admin, I play mostly in 3, deploying, tuning, configuring, monitoring (to the extent that piss-poor Java tools allow any sort of monitoring -- want a dump of what's in memory? Sure ... let's just pause ALL activity on the VM for the next 25 minutes), troubleshooting, and patching/updating the VM.
I'm also concerned with the security model, within the parameters of my other system security concerns.
For the language and class libraries, it's largely ensuring that what my devs need and use is provisioned on our test, staging, and production hosts. There's also digging through some of the logging / crash / debug output to see if I can sort out what's wrong and fix it myself, or punt it over the wall to Engineering.