I'm not sure, uckelman. The same $PATH should be used when executing from a command line in the terminal as executing the app (which actually executes the little stub in the MacOS folder of the package). Therefore, the java binary would be found the same way and you have already eliminated the issue of extraneous VMs. Usually that's the case, but there are possibilities like scripts that can change what gets executed. I haven't really looked at this. In general, when I see an issue like this I try to eliminate variables - like the vm or extraneous classes - to know what we are really looking at.
It's easy to recreate (from the command line it works and from the app or the stub it does not), so I will look at it over the weekend, but for now I have a workaround, so it's not a high-priority. My machine has never had anything but java 7 installed.
With respect to your earlier comment about Apple's installation of Java... there is actually a reason for the mac/java confusion It's not entirely Apple's fault, but they have been complicit in not keeping the most up to date versions of java supported in mac os.
This article that explains some of Apple's recent trouble with Java (see Lion Macs).
http://blogs.computerworld.com/applicat ... va-updatesNote that today is Feb 19, 2013 and here is the Oracle patch:
http://www.oracle.com/technetwork/topic ... 05892.htmlThe retina screens started shipping in June of 2012 and the fact that Guillaume had vm of java 6 on his machine puts him in the "Lion Macs" part of the article. It means he has both VMs installed. He fixed that by installing VM7 but he still has a flawed version of VM6 on his disc. It needs to be updated or removed.
My Mac only has 7 installed. I still need to do the update.
This is really an important update, Guillaume, because there are major security flaws in the system that can be exploited.