This page is a wiki. Please login or create an account to begin editing.


9 posts / 0 new
Last post
Jatoba's picture
Offline
Joined: 2018 Apr 16
Advancing Java on Tiger & Leopard

As some may already know, the latest official Java version installable on Mac OS X 10.4 Tiger and 10.5 Leopard is 1.5. However, there's a developer preview version of Java SE 6 (AKA 1.6), called dp6, which is very easily installable on Tiger with these steps, and works very well, allowing you to run many apps that require it just fine, such as JDownloader 2 (both .app and .jar files), after following one extra step (only needed for installing the .app version).

Thing is, although steps to get Java SE 6 working on Leopard exist here, and the Terminal does report the correct version with the command "java -version", most programs will only detect Java 1.5 instead, which is probably related to the fact "Java Preferences.app" does not list Java SE 6 with this Leopard method. So getting around that is our first challenge.

Our second challenge relates to going even further, and install Java SE 7, or rather, the libre/open-source version of it, OpenJDK 7, both on Tiger and Leopard. The procedure to getting OpenJDK 7 on Tiger and Leopard is very similar to getting Java SE 6 dp6 on Leopard, and the problems are pretty much the same: most apps will think you are stuck with Java 1.5, and won't work, despite "java -version" on Terminal reporting OpenJDK 7 is installed and active.

Now, onto the solutions. Both Duality and people at MacRumors correctly pointed out you can try running .jar apps with the following command in Terminal:
"java -Djava.awt.headless=false -jar full_program_path_here.jar"
This will be sufficient for some apps, but won't suffice for some others. Duality reported the following experience and procedure in the OpenJDK 7 page:

As long as I open Java apps as multiplatform .jar files from the command line with this:

java -Djava.awt.headless=false -jar /path/to/a/file.jar

That almost worked. Up to that point, I was getting no GUI and a number of Java stack traces and linker errors indicating the version of Freetype at /usr/X11/lib/libfreetype.6.dylib was too old.

I replaced the libfreetype.6.dylib in /usr/X11/lib/ with the version that Tigerbrew installs with `brew install freetype` at /usr/local/Cellar/freetype/2.6_1/lib/, gave it root permissions with `sudo chown -R root:wheel /usr/X11/lib/libfreetype.6.dylib`, and all was well.

It would be nice to have a Jar Launcher that didn't constantly try to open Jar files with Apple Java when you open them in Finder. That can be an exercise for a future reader. Smile

This is also with the last version of XQuartz made for Leopard handling the X11 duties. I don't know if that is what was causing the Freetype issues.

As X11 on Mac OS X isn't used for anything critical to the OS, and it can be reinstalled through XQuartz.org anytime, replacing this one dylib doesn't seem to have many harmful consequences.

And that's where we stand today. I have yet to attempt Duality's approach with JDownloader's .jar version to see if it also applies to my case (I'll check the stack trace on Console.app to see what is reported there, too). In any case, this forum thread was created to keep discussions of advancing Java on Tiger and Leopard centralized, since it's easier to discuss, follow and more likely to help others in the future. Of course, everyone is more than welcome, and even encouraged, to participate.

Comments

Duality's picture
Offline
Joined: 2014 Mar 1

Thank you!

I haven't ever tried that pre-release version of Apple Java 6, so I can't quite tell you what's right there and what's not.

JDK 7 was an interesting release. That was when Apple stopped providing their own Java and Oracle handled distributing (Intel) Mac versions with limited staff. From that point on, "Java Preferences.app" in Leopard and Snow Leopard no longer applied to new releases of Java, starting with Java 7. Part of the Oracle release had a whole new preferences pane that was made to look like the old Apple Java Preferences, but wasn't Java Preferences. It was a strange compromise!

OpenJDK 7 for Intel and PowerPC is based on some parts of the Oracle release, specifically the bits that fell into GPL. There is no odd looking Oracle variant of the Apple Java Preferences in OpenJDK, but that also means that OpenJDK 7 for PowerPC doesn't seem to have a Java Preferences GUI.

That part checks out to me, knowing what was going on around Java 7.

Apple Java was essentially a fork of Sun's Java with some extra objects to better bridge the Java and Objective-C world, and make Java apps look more like Cocoa apps. With Oracle Java 7 and OpenJDK 7, those bits were lost.

What I tested was the last old stable Jar version of DrJava. This runs slowly in OpenJDK 7 for PowerPC, but it works, and I couldn't see any problems with it.

I tried the Jar version of JDownloader 2 next, and that feels incomplete.

There's definitely some Apple Java-exclusive objects that it's trying to look for, but which aren't there in OpenJDK 7. I can see that in the Java exceptions that it litters the logs with, as they have failed references to objects with signatures like "com.apple.[...]". It does get far enough to attempt to update itself, so it's not a lost cause.

I suspect that the problem is that Jars that are not truly written to be cross-platform, and which make assumptions about running code on the Mac, are going to have some trouble with OpenJDK 7.

DrJava is a case where the developers did go out of their way to support OpenJDK and SoyLatte, and it shows. Some apps may be written expecting Oracle Java and maybe the official OpenJDK releases, but not much else.

That's my assessment. There might be some crazy way of getting the proprietary Apple Java bits wielded into an OpenJDK build. I haven't heard of anybody succeeding at that before. I imagine it will be difficult to bridge the differences between Java 6 and 7, along with the differences between the proprietary Apple and Oracle Javas versus the GPLed OpenJDK.

On the other hand, if you have the source for these Jars you'd like to run, you could avoid that mess entirely by properly stubbing out calls to Apple Java objects and reference X11 instead. If there's any hint of *nix support, they should already be doing that in some other code paths.

You might also want to consider that the speed of OpenJDK 7 PowerPC is not that great even on a 2005 PowerBook G4, if you're trying to run complex Java apps. A native Cocoa app will run circles around any of these.

Jatoba's picture
Offline
Joined: 2018 Apr 16

That's an insightful write-up, it explains a lot, and makes a lot about the whole situation much clearer, and serves to adjust my expectations into a more realistic frame. Very informative and helpful post.

For now, I'll see if following the OpenJDK 7 procedure on Tiger will at least not cause problems with Apple Java 1.5 and SE 6 dp6, because this way Tiger gets the best of all worlds (Java 1.5, SE 6 dp6 and, from the command line, OpenJDK 7). As for Leopard, I'd at least like to be able to bring it up to Tiger's Java SE 6 situation, if at all possible. Meaning being able to easily enable and disable Java 1.5/SE 6 from Java Preferences.app. My fear is that the newer Java Preferences app shipped with Java SE 6 dp6 may be incompatible with Leopard altogether, but I won't conclude that before investigating first.

If this much can be achieved, I'd be completely satisfied, now that I understand the situation better.
Regarding OpenJDK 7 performance, in my case, it's more about the novelty of getting as many things working under Tiger and Leo as possible. But indeed, native apps will always be preferred whenever given the option.

Jatoba's picture
Offline
Joined: 2018 Apr 16

Assuming I made no mistake, it turns out OpenJDK 7 is not compatible with Tiger at all, at least by default. I tested all 12 versions listed on OpenJDK 7's page, and when running "java -version" on Terminal with each, 11 out of 12 of the versions returned the following to me:
dyld: unknown required load command 0x8000001C
Trace/BPT trap

The remaining version, "openjdk7-macppc-2009-12-16-b4", which gave me a different error, showed this instead:
Bus error

I don't know what these errors are supposed to mean. Console.app just tells me to look at a crash log file, and that file just shows the same error I got shown by the Terminal.

I'm not sure if there's some missing dependency here, or if the way it was compiled makes it Leopard-exclusive and that to address this the source would have to be recompiled for Tiger (and perhaps even modified), or if I simply am doing something wrong (which is entirely possible). But that's the result I got.

Duality's picture
Offline
Joined: 2014 Mar 1

Sounds like Mac OS X's dynamic linker (dyld) is looking for some symbols that don't exist in Tiger. Might be that OpenJDK 7 for PPC was compiled with a base target OS of Mac OS X Leopard, and/or OpenJDK 7 depends on some Leopard features that didn't exist in Tiger.

Looking at our entry for Oni, under the compatibility section, it seems at least understood by some that as far as Java support goes, SoyLatte is best for 32 bit Intel Leopard, OpenJDK for PPC for PowerPC Leopard, and the Java 6 developer preview for Tiger.

The Garden entries for OpenJDK 7 for PPC and SoyLatte have room for a little fixing up. Certainly to clarify that OpenJDK 7 for PPC won't work in Tiger. Perhaps to also adjust expectations as far as what's likely to work, compared to an Apple Java release.

MikeTomTom's picture
Offline
Joined: 2009 Dec 7

Guys; https for the Mac Garden is a relatively new thing and using local to the MG, full https links in posts, cannot be parsed by those of us accessing this site using older software (basically anyone using a Classic Mac OS to access the site).

It's preferable for now, if we use the abbreviated form, which will work for both http and https internal links.

That is, omit "http://macintosh.org" and "https://macintosh.org" from all href links local to the MG.

Use instead, for example: <a href="/apps/openjdk7-ppc">OpenJDK 7</a> <-- this works locally for both http & https access within the Garden.

Thanks, this may not be necessary in the future, but until then... If you can keep this in mind that would be great.

Duality's picture
Offline
Joined: 2014 Mar 1

Noted, and done. Goes to show how invisible that change was. Smile

Jatoba's picture
Offline
Joined: 2018 Apr 16

I was so focused on the matter at hand, and pasting links left and right, that it didn't even occur to me to use http links as much as possible. Just in case, I now edited my post for non-Garden links, as well, and will always keep this in mind from now on.

MikeTomTom's picture
Offline
Joined: 2009 Dec 7

Thanks it's much appreciated, Duality & Jatoba. It's only the local to the Garden internal links to mind out for. External https links will likely be broken for all older browsers. But in the MG both http & https access will be catered for. Omitting either "http://macintosh.org" or "https://macintosh.org" from href links local to the MG in posts or pages, allows the links to work locally for both http & https access within the Garden.