@Machiel van Dorst: The issue with OS X is not whether the launcher "detects" any particular version of Java, but simply how the application was packaged. You see, for the longest time Apple had leave to create their own customized builds of Java HotSpot, later grandfathered in when Sun was bought out by Oracle. However, they could not get a renewal of whatever license they had after Oracle took over. So when Java 7 came out, Apple handed over the reins of all their tweaks and system-specific calls to Oracle for Java 7.
However, since Oracle is a third-party software developer (as far as Apple is concerned), Oracle couldn't install their version of Java in the same place that Apple had (in the OS core directory, "/System"), and had to make due with where all third-party software installs by default (the system "/Library" folder). The problem with that is, Apple's Java bundler only looks in the OS directory for the Java VM, and so resulting apps cannot detect Java VMs in the system Library. Conversely, when Oracle made their Java bundler for Mac, their version only looks in Oracle's default install location in the system Library.
Which is where people start griping. If the app is bundled using Apple's solution, it'll only be able to run using Apple's VM, but it will retain compatibility with Snow Leopard. If the app is bundled using Oracle's solution, it'll be able to run any up-to-date Oracle VM, but it would not be able to run on Snow Leopard at all. I found a solution that would retain compatibility with both versions (using a shell script in place of the native binary), but it took me some time to find it. You can see the fruits of my labor detailed above.
Thank you for reading,
~Nyriox
@ Grum: What kind of something, if you don't mind me asking. Minecraft written in Java 7? Java 8?
~Nyriox
Follow-up note: I may be able to test on a 32-bit system at school (there are about a half-dozen in one of the labs), and already have the green light to do some system reconfiguration, so I might manage it on down time. I'll post my success (or failure) if and when it happens.
UPDATE: Tested, and found to be working on a 32-bit only system at school.
[10:53:41 INFO]: Refreshing local version list...
[10:53:41 INFO]: Refreshing remote version list...
[10:53:41 INFO]: Minecraft Launcher 1.3.11 (through bootstrap 5) started on osx...
[10:53:41 INFO]: Current time is Mar 18, 2014 10:53:41 AM
[10:53:41 INFO]: System.getProperty('os.name') == 'Mac OS X'
[10:53:41 INFO]: System.getProperty('os.version') == '10.6.8'
[10:53:41 INFO]: System.getProperty('os.arch') == 'i386'
[10:53:41 INFO]: System.getProperty('java.version') == '1.6.0_51'
[10:53:41 INFO]: System.getProperty('java.vendor') == 'Apple Inc.'
[10:53:41 INFO]: System.getProperty('sun.arch.data.model') == '32'
[10:53:41 INFO]: Refresh complete.
[10:53:41 INFO]: Loaded 0 profile(s); selected '(Default)'
[10:54:04 INFO]: Logging in with username & passwordhttps://dl.dropboxusercontent.com/u/53935943/MC32.jpg
https://dl.dropboxusercontent.com/u/53935943/MC32-1.jpg
I've also tested it on the newly released Java SE 8, and found it working with that as well.
[14:42:28 INFO]: JFX is already initialized
[14:42:31 INFO]: Refreshing local version list...
[14:42:31 INFO]: Minecraft Launcher 1.3.11 (through bootstrap 5) started on osx...
[14:42:31 INFO]: Current time is Mar 19, 2014 2:42:31 PM
[14:42:31 INFO]: System.getProperty('os.name') == 'Mac OS X'
[14:42:31 INFO]: System.getProperty('os.version') == '10.9.2'
[14:42:31 INFO]: System.getProperty('os.arch') == 'x86_64'
[14:42:31 INFO]: System.getProperty('java.version') == '1.8.0'
[14:42:31 INFO]: System.getProperty('java.vendor') == 'Oracle Corporation'
[14:42:31 INFO]: System.getProperty('sun.arch.data.model') == '64'
[14:42:32 INFO]: Refreshing remote version list...
[14:42:32 INFO]: Refresh complete.
[14:42:32 INFO]: Loaded 2 profile(s); selected 'MCPatcher'
[14:42:32 INFO]: Refreshing auth...
[14:42:32 INFO]: Logging in with access tokenhttps://dl.dropboxusercontent.com/u/53935943/MC8J.jpg
I've therefore found that so far all OS X systems with any Java installed can run the modified app presented.
@Ezekiel: Let me put it to you this way, Ezekiel.
In 2006 I received a Mac Mini from the first generation of Intel-hardware Mac minis (macmini 1,1), with a 1.66 GHz Intel Core duo (T2300). See here: http://en.wikipedia.org/wiki/Mac_Mini#Specifications_2
http://ark.intel.com/products/27233/intel-core-duo-processor-t2300-2m-cache-1_66-ghz-667-mhz-fsb
The difference between a Core duo and Core 2 duo is that one is 32-bit only, while the other supports 64-bit, respectively. The last version of OS X I ran on that computer was 10.6--I upgraded for the exclusive sake of playing Minecraft after the game stopped supporting Tiger (10.4), which came with the system.
Snow Leopard most definitely DID support 32-bit, or I wouldn't have been able to upgrade. 10.6 was a transitioning point from 32-bit to 64-bit kernel, but it was far from complete. It wasn't till Lion (10.7) that they made the kernel truly 64-bit (thus making older hardware like what I had been using not OS upgradeable after that point).
So, after about two more years, I decided to upgrade to the computer I use now (Mac Mini 5,2), and subsequently sold my old 32-bit mac mini. Which is why I'm whining about not having access to a 32-bit machine.
Thank you for your consideration.
~Nyriox
@Jonathan Hynes: And, as I just commented, the edited version I posted will work with both 10.6 and 10.7+, so avoiding the issue with the solution I posted is fairly ridiculous (though admittedly I am having trouble figuring out where the "About" data went).
NOTE: I do not have access to a 32-bit mac anymore, so I can't verify on that issue, but considering that no mention of 32- or 64-bit is made at all in the edited files, I presume that it will work in 32-bit. Can someone test this for me?
Also, if anyone knows who at Mojang signs the Mac version of the app, could you request they sign the version I made as an "alternate" or something?
Thanks,
~Nyriox
@Jonathan Hynes: Actually, you're not quite correct on the issue. What a lot of OS X native (and open source) developers tend to do is simply create multiple different versions of an app, especially for maintenance/configuration utilities (like OnyX): one for each major OS upgrade. In this case, the simple solution is to have a "10.6" and "10.7+" version, one using Java 6 and the other Java 7, respectively.
And though I'll need to check, I think the solution I'm using right now will be compatible with both Java 6 and 7, considering that it just calls the same Terminal functions mentioned above as an executable.
EDIT: Just verified. Console output:
[17:32:04 INFO]: Refreshing local version list...
[17:32:04 INFO]: Minecraft Launcher 1.3.10 (through bootstrap 5) started on osx...
[17:32:04 INFO]: Current time is Mar 9, 2014 5:32:04 PM
[17:32:04 INFO]: System.getProperty('os.name') == 'Mac OS X'
[17:32:04 INFO]: System.getProperty('os.version') == '10.9.2'
[17:32:04 INFO]: System.getProperty('os.arch') == 'x86_64'
[17:32:04 INFO]: System.getProperty('java.version') == '1.6.0_65'
[17:32:04 INFO]: System.getProperty('java.vendor') == 'Apple Inc.'
[17:32:04 INFO]: System.getProperty('sun.arch.data.model') == '64'
[17:32:05 INFO]: Refreshing remote version list...
[17:32:05 INFO]: Refresh complete.
[17:32:05 INFO]: Loaded 2 profile(s); selected 'MCPatcher'
[17:32:05 INFO]: Refreshing auth...
[17:32:05 INFO]: Logging in with access token
And therefore the edited version I posted a DL link of above can be used by both Snow Leopard and Lion+ users, making it the de facto perfect version for all Mac users.
Ciao!
~Nyriox
@ Jonathan Hynes: I tried the AppBundler solution, but it just wouldn't compile for me. So instead I used the solution I linked to in my previous post (being very careful to delete the "_CodeSignature" and hidden ".Info.plist.swp" files), and then found the app launched perfectly afterward.
Screenshot of files to delete (the highlighted one is hidden by default):
https://dl.dropboxusercontent.com/u/53935943/mc-swp.jpg
And yes, I'd forgotten to mention that ".Info.plist.swp" file before, but I'd simply forgotten about it. For most users,
"rm -rf /Applications/Minecraft.app/Contents/.Info.plist.swp"
under Terminal should work to remove that issue (assuming, as with the rest of the instructions, that "Minecraft.app" is in "/Applications/").
In case anyone is wondering how the edit works, it simply uses a command-line script (instead of Apple's usual mixed binary), which directs to /usr/bin/java (alias of /System/Library/Frameworks/JavaVM.framework/Versions/A/Commands/java) for execution of the .jar, thereby using the system default version of java, instead of any specific version.
Thanks for replying,
~Nyriox
Actually, I found a solution to the problem here presented that does not involve re-authoring the app. The description of how to do so is here:
https://gist.github.com/pudquick/7518753
And here is the resulting app:
https://mega.co.nz/#!mFMmkaxS!irH3Hrb3UanxehSAD7_tFKyRPgJ9cLraI1arnBZKexY
This is just a modified version of the original launcher, but I had to strip out the CodeSignature to do it (and I don't have any means of signing the app myself). So, as of this current moment, you'll have to bypass Gatekeeper to use the modified app.
I would sincerely appreciate it if some Mojangsta were to create an officially signed version of this.
A screenshot of proof made using my modified app is here:
https://dl.dropboxusercontent.com/u/53935943/MC_demo.jpg
Console output as additional proof:
[10:15:48 INFO]: Minecraft Launcher 1.3.10 (through bootstrap 5) started on osx...
[10:15:48 INFO]: Refreshing local version list...
[10:15:48 INFO]: Current time is Mar 7, 2014 10:15:48 AM
[10:15:48 INFO]: System.getProperty('os.name') == 'Mac OS X'
[10:15:48 INFO]: System.getProperty('os.version') == '10.9.2'
[10:15:48 INFO]: System.getProperty('os.arch') == 'x86_64'
[10:15:48 INFO]: System.getProperty('java.version') == '1.7.0_51'
[10:15:48 INFO]: System.getProperty('java.vendor') == 'Oracle Corporation'
[10:15:48 INFO]: System.getProperty('sun.arch.data.model') == '64'
[10:15:48 INFO]: Refreshing remote version list...
[10:15:49 INFO]: Refresh complete.
[10:15:49 INFO]: Loaded 2 profile(s); selected 'MCPatcher'
[10:15:49 INFO]: Refreshing auth...
[10:15:49 INFO]: Logging in with access token
EDIT: Updated DL link. The version in the previous zip still had the "JavaApplicationStub" in the MacOS folder, even though in the edited version it is unused. I deleted "JavaApplicationStub" to save precious disk space. The new app uses significantly less space than the official version, due to the significantly less data in the "LaunchGame" executable (less than a Kilobyte!).
Thanks,
~Nyriox
@Jonathan Hynes: Actually, interestingly enough, Java 7 has better built-in support for 3D modeling and rendering (through JavaFX) than Java 6 does, which would hugely reduce the need to use third-party tools to make the game work. In fact, @Dinnerbone commented on that very thing. See here:
https://twitter.com/Dinnerbone/status/446900015663837184
~Nyriox