Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
- Status
Even after creating aliases from 1.7 to 1.7.0 to Home, it's not returning anything with 'java -version', which 1.6 didn't do.
I think the Java 6 and 7 contents need to be revised...
Last edited:
I followed the instructions of the OP but unfortunately JDownloader (requires Java 1.6) does not work on my PMG5 running 10.5.8. I don't think the OS is actually understanding that there is supposedly 1.6 and 1.7 on it ... (Sorry the screenshot is in German but I think you can still figure out what it is saying roughly)
Attachments
@netsrot39, all I can tell you is to look here and here. But basically, it is as you say: OpenJDK 7 is not fully integrated with OS X, and it seems Java SE 6 (on Leopard only) isn't, either.
If you can get the newer Java Preferences.app that comes with the Java SE 6 Developer Preview 6 installer to run under Leopard, it, perhaps, may be able to detect that you have installed Java 1.6 at least.
If you can get the newer Java Preferences.app that comes with the Java SE 6 Developer Preview 6 installer to run under Leopard, it, perhaps, may be able to detect that you have installed Java 1.6 at least.
I tried that already, it doesnt work, and the preferences app is older than the one that comes with Apples Java 1.5 so... I am trying to get the Java 1.6 and 1.7 to display properly in the preferences app but without success... @netsrot39 But you can try changing the 1.6 to 1.5 in .pref in that app you’re trying to run.
This in particular I can ensure is not an issue: older or not, at least on Tiger, it's the version that properly lists Java versions 1.4.2, 1.5 and 1.6 (dp6), while the one that comes with Java 1.5 doesn't show 1.6 (dp6), at least not by default.
There should be some way to make 1.6 dp6 work properly on Leopard like it does on Tiger... On Tiger, I have both the .app and .jar versions of JDownloader working properly.
It was on my end.
I abandoned the previous way I was trying to script it, made sure the manual way worked (it did), and basically translated the manual way to a simplistic script version. Lo and behold, all is well.
Now this is interesting...
Minecraft 1.5.1 won't launch with Java 7.
I suspect something in its innards is expecting a specific Java 5, and is being met with something different, thus refusing to start.
Maybe we should reserve Java 6 / 7 for specific applications requiring their usage in Leopard. Given that the rest of the OS / apps just expect and seem to work best on Java 5 anyway, there would seem to be no immediate advantage to these updated versions.
A shame...
Minecraft 1.5.1 won't launch with Java 7.
I suspect something in its innards is expecting a specific Java 5, and is being met with something different, thus refusing to start.
Maybe we should reserve Java 6 / 7 for specific applications requiring their usage in Leopard. Given that the rest of the OS / apps just expect and seem to work best on Java 5 anyway, there would seem to be no immediate advantage to these updated versions.
A shame...
My Minecraft 1.5.1 will launch on 1.5 as well as 1.6 if I remember correctly. Java 1.7 have some minor rework thats why even after the release of the 1.7 minecraft was still using 1.6 instead of 1.7 for a while.
Reworked the installer scripts to do two things:
- One script installs both Java 6 / 7.
- Three other scripts quickly switch the system to use versions 5, 6, or 7 for easy application testing and troubleshooting.
This makes for both an easier workflow for developers, and a simpler process for users.
- One script installs both Java 6 / 7.
- Three other scripts quickly switch the system to use versions 5, 6, or 7 for easy application testing and troubleshooting.
This makes for both an easier workflow for developers, and a simpler process for users.
I've installed the 'java 6 and 7.zip' on my Mac mini G4 PPC OS X Leopard 10.5.8. and it runs fine i.e. javac compiles a sample HelloWorld.java file and java runs it.
However when I try to run Eclipse, it stops with this:
The JVM shared library "/System/Library/Frameworks/JavaVM.framework" does not contain the JNI_CreateJavaVM symbol
AFAIK this problem is caused by unpresence of a file called JavaVM. More accurately, there must be a folder named /System/Library/Frameworks/JavaVM.framework/Versions/A/ and JavaVM must reside in it.
JavaVM was available in Java 1.5 which was the default installation on this Mac but it doesnt seem to be in "java 6 and 7.zip"
Should I find it from the Internet and put it manually inside the s /System/Library/Frameworks/JavaVM.framework/Versions/A or is there any workaround for it?
However when I try to run Eclipse, it stops with this:
The JVM shared library "/System/Library/Frameworks/JavaVM.framework" does not contain the JNI_CreateJavaVM symbol
AFAIK this problem is caused by unpresence of a file called JavaVM. More accurately, there must be a folder named /System/Library/Frameworks/JavaVM.framework/Versions/A/ and JavaVM must reside in it.
JavaVM was available in Java 1.5 which was the default installation on this Mac but it doesnt seem to be in "java 6 and 7.zip"
Should I find it from the Internet and put it manually inside the s /System/Library/Frameworks/JavaVM.framework/Versions/A or is there any workaround for it?
I vaguely remember there being a JavaVM in "Java 6 and 7.zip". Try making an alias for JavaVM in /System/Library/Frameworks/JavaVM.framework/Versions/A linking back to /System/Library/Frameworks/JavaVM.framework. See what happens. If you have any other ideas at all, try those too.
I've just looked at the contents of Java 6 and 7.zi
unzip -l java-6-and-7.zip | grep JavaVMreturned no results.
The file in question, JavaVM, seems to be formed only inside the /A folder, i.e. there's no JavaVM inside the /1.5 folder. I see it on my backup drive (on which no Java 6 is installed, there's just Java 5 installed) There is a JavaVM inside /A.
As I prepared the /A folder for Java 6, I deleted that JavaVM belonging to the Java 5.
Now I will work a bit on the backup drive to see what's missing.
I've fixed the problem.
1- The /A folder and its contents should not be changed. That is, it must keep on having the Java 1.5 files.
2- Java 1.6.0 and the symlink 1.6 folder must be copied into Versions (like the Java Updater.sh does)
3- The -vm at eclipse.ini must be set to /Versions/1.6/Commands/java
Eclipse.app will work perfectly.
1- The /A folder and its contents should not be changed. That is, it must keep on having the Java 1.5 files.
2- Java 1.6.0 and the symlink 1.6 folder must be copied into Versions (like the Java Updater.sh does)
3- The -vm at eclipse.ini must be set to /Versions/1.6/Commands/java
Eclipse.app will work perfectly.
Anyone think there’s a chance of java 8 for ppc? I know that there’s a linux version, so could we ever be seeing that?
Maybe one day. Currently I have a lot of work on renovating my new house so... I am more focused on that. BUT! I am currently planning to get OS X 10.6 running on PPC and also I am getting my iMac G5 fixed and I am buying a PowerMac G4 MDD dual 7455 1,25GHz. So more PCs to test on and thus more PCs to tinker with. I am toying with idea of 7457 swaping the 7455 in the MDD and also 7448 swap my DLSD. Whatcha think of that?
So I figured out how to get the 1.6 java to show up in the Java Preferences in Leopard. While this does let other apps "see" the 1.6 java. There are still other issues that prevent it from being used in the few apps I've tried. (Jdownloader, phpstorm 2.1.5). Maybe someone can do the leg work to try to figure out the remaining parts.
TL;DR Version
Download the plist file I attached. Replace the one in /System/Library/Frameworks/JavaVM.framework/Versions/1.6/Resources/Info.plist (Be sure to save the old plist if you want to revert it)
And as I said, there are still other incompatibilities to getting this running with full native integration. But it's at least one step closer.
Full Version
I wanted to also document my observations and possible routes for maybe getting this working.
So the Java Preferences.app itself isn't responsible for enumerating the available installations. It's actually offloaded to another Framework component /System/Library/PrivateFrameworks/JavaLaunching.framework. This reads each folder in the JavaVM Versions folder and reads the Info.plists.
So open the /System/Library/Frameworks/JavaVM.framework/Versions/1.6/Resources/Info.plist and replace the contents with the one I uploaded. Basically we're copying in a bunch of metadata from the official 1.5 version. This will let it be "seen" by the Java Preferences. But of course this isn't sufficient. If one runs a Java application, it won't launch.
A closer look at Console.app shows the java application is complaining about missing dylib files when trying to run an application. Specifically libserver.dylib. It's expecting a specific path for these files. While those files are present, they're in a different directory in the 1.6 tree. Symlinking these files from their original spot to the expected spot lets the application progress further. But we run into another issue.
If we look again in the Console.app, we see the application is complaining about a missing symbol in one of the java library files. _CTFontGetGraphicsFont. From my (admittedly limited) experience, this means the files have been compiled for a different target than the one its currently running on. It's expecting methods and calls that aren't where it expects them to be or not available at all. If the origins of the 1.6 developer preview is Tiger, this would make sense.
The file where the offending call was happening from is the libawt.jnilib. Looking at the decompilation of this file in the 1.5 and 1.6 versions we see the 1.5 makes no reference to CTFontGetGraphics at all whereas the 1.6 version does. And the 1.5 version tries to call something named CTFontCopyGraphicsFont instead which isn't present in 1.6. They're both trying to find this call in the /System/Library/Frameworks/ApplicationServices.framework. I'm guessing this is due to underlying API changes moving from Tiger to Leopard. Even if this call were to be patched with the Leopard version (and it doesn't appear to be a drop in replacement). There would probably be dozens if not hundreds of other such calls to be patched. In short, a monumental task that's above my pay grade ?. Maybe someone else here has the skills and time to attempt such a task.
What about 1.7?
The uploaded 1.7 installation directory is very different from the 1.6 version. But maybe someone can try to rearrange the folders and create an Info.plist that will satisfy the Java Preferences? I haven't tried it, but it's worth looking into if someone has the time.
Oh and one more thing. -- If you do this and the Java Preferences won't open, it's because its' trying to use the 1.6 JVM which doesn't fully work. Reverting the 1.6 plist to stock will get it to open again.
TL;DR Version
Download the plist file I attached. Replace the one in /System/Library/Frameworks/JavaVM.framework/Versions/1.6/Resources/Info.plist (Be sure to save the old plist if you want to revert it)
And as I said, there are still other incompatibilities to getting this running with full native integration. But it's at least one step closer.
Full Version
I wanted to also document my observations and possible routes for maybe getting this working.
So the Java Preferences.app itself isn't responsible for enumerating the available installations. It's actually offloaded to another Framework component /System/Library/PrivateFrameworks/JavaLaunching.framework. This reads each folder in the JavaVM Versions folder and reads the Info.plists.
So open the /System/Library/Frameworks/JavaVM.framework/Versions/1.6/Resources/Info.plist and replace the contents with the one I uploaded. Basically we're copying in a bunch of metadata from the official 1.5 version. This will let it be "seen" by the Java Preferences. But of course this isn't sufficient. If one runs a Java application, it won't launch.
A closer look at Console.app shows the java application is complaining about missing dylib files when trying to run an application. Specifically libserver.dylib. It's expecting a specific path for these files. While those files are present, they're in a different directory in the 1.6 tree. Symlinking these files from their original spot to the expected spot lets the application progress further. But we run into another issue.
If we look again in the Console.app, we see the application is complaining about a missing symbol in one of the java library files. _CTFontGetGraphicsFont. From my (admittedly limited) experience, this means the files have been compiled for a different target than the one its currently running on. It's expecting methods and calls that aren't where it expects them to be or not available at all. If the origins of the 1.6 developer preview is Tiger, this would make sense.
The file where the offending call was happening from is the libawt.jnilib. Looking at the decompilation of this file in the 1.5 and 1.6 versions we see the 1.5 makes no reference to CTFontGetGraphics at all whereas the 1.6 version does. And the 1.5 version tries to call something named CTFontCopyGraphicsFont instead which isn't present in 1.6. They're both trying to find this call in the /System/Library/Frameworks/ApplicationServices.framework. I'm guessing this is due to underlying API changes moving from Tiger to Leopard. Even if this call were to be patched with the Leopard version (and it doesn't appear to be a drop in replacement). There would probably be dozens if not hundreds of other such calls to be patched. In short, a monumental task that's above my pay grade ?. Maybe someone else here has the skills and time to attempt such a task.
What about 1.7?
The uploaded 1.7 installation directory is very different from the 1.6 version. But maybe someone can try to rearrange the folders and create an Info.plist that will satisfy the Java Preferences? I haven't tried it, but it's worth looking into if someone has the time.
Oh and one more thing. -- If you do this and the Java Preferences won't open, it's because its' trying to use the 1.6 JVM which doesn't fully work. Reverting the 1.6 plist to stock will get it to open again.
With the best will in the world... you've got two hopes. Bob Hope and no hope.
If I had £1 for every time someone has said this in the last few years, I'd be a fair few £'s richer.
We're all here if you need any help with that.
Yanno, it might be possible by emulating an x86 system using QEMU on a Linux/PPC host.