John Carmack considered using Java in id's games for quite some time, ever since he announced that the company was leaning towards client-downloadable code for the Trinity project. "The QA game architecture so far has two separate binary .DLLs: one for the server-side game logic, and one for the client side presentation logic." (..) However, with the hacking attacks on Quake 2 servers in mind, Carmack states that, "While it was easiest to begin development like that, there are two crucial problems with shipping the game that way: security and portability. If we were willing to wed ourselves completely to the Windows platform, we might have pushed ahead, but I want Quake 3: Arena running on every platform that has hardware-accelerated OpenGL and an Internet connection."
(..)
His solution: "I had been working under the assumption that Java was the right way to go, but recently I reached a better conclusion. The programming language is interpreted ANSI C. The game will have an interpreter for a virtual RISC-like CPU."
(..)
The advantages of using a C or C++ subset for your VM are obvious when it comes to handling legacy code. Ironically, it was Java portability problems that led id to develop the Quake 3 custom VM. Sun's promise of "write once, run anywhere" did not hold for the Invocation API on important server platforms, so Carmack decided to abandon the embedded JVM he had planned to use. (..) "Having made the decision to do my own interpreter, I feel much more at ease not having to rely on anyone else's external code. When it comes around to the next development cycle, I will make the Java decision again." As for embedding: "We are still working with significant chunks of an existing code base. If I did want to go off and start fresh, I would likely try doing almost everything in Java."

So currently the list reads (I'll try to update it):

Wow, what an old thread to necro

Theres a lot more commercial java games these days

but yeh Minecraft is probably the most successful indie game ever.

Runescape

didn't knew that Vampire: The Masquerade used a JVM for scripting. Was an awesome game back than.
http://www.gamecareerguide.biz/features/19990611/java_13.htm#vampire

3. Using Java as a scripting engine.
We knew from the start that allowing the user community to edit the game was an important part of the design. After working in the first-person action-game market, we saw the benefits of supporting the user community and wanted to carry this idea over into role-playing games, where it is not the norm. A built-in scripting system makes a game engine much more extendable by fans. In Jedi Knight, we created our own customized game language called COG. Creating COG took a lot of effort from the development team; several months of work went into creating the compiler, testing the generated code, and implementing the run-time kernel used to execute the scripts. The end result was worth it, but it cost a lot in terms of time and resources to pull it off (for more about COG, see my article, "Adding Languages to Game Engines," September 1997).  wrote for GDC on why he used Java instead of C:

When starting Vampire, we looked for ways to incorporate a scripting engine more easily than creating our own from scratch yet again. There were several scripting systems we examined and tested. At about that time, another game development company, Rebel Boat Rocker software, was getting a lot of attention for its use of Java technology. After exchanging a few e-mails with lead programmer Billy Zelsnak, we decided to give Java a try. Up to this point I knew very little of Java, and had largely dismissed it as a language suitable only for making icons dance on a web page and the like.

After a crash course in Java, we did a few simple tests incorporating it into our game engine. It passed each one with flying colors. In a matter of a few weeks, we had solved the major challenges involved in interfacing a standard, freely distributable Java virtual machine to our 3D RPG engine. From that point on, the only maintenance required was to add new native functions to the scripting language, which we did whenever we added new engine functionality that we wanted exposed to the script writers. We also trained several designers in the use of the scripting language, and they started creating the hundreds of small scripts that would eventually drive the storyline of the game.

Ever since those initial tests, I kept waiting for the other shoe to drop, so to speak. I expected to come to work one day and find out that the Java thread was chewing up 100MB of RAM or eating 50 percent of the CPU time, but amazingly, the system was trouble-free throughout development and never became a significant resource drain. If for some reason we had hit a dead end with the Java system late in the project, it would have easily taken three to four months to get back on track using a different scripting technology. In the end, the gamble paid off. We saved months of programmer time that would have otherwise been devoted to creating a scripting environment, and the result was a system significantly more efficient and robust than any we could have created ourselves.