Of course, now that Apple’s deprecating Java, that’s probably going to annoy the folks
Having thought about what I actually use Java for on Mac OS X (now that Apple’s indicated it’s deprecated). Probably the main ones are
- Eclipse (Free development environment for many languages, not just Java)
- NeoOffice/OpenOffice (Free alternatives to Microsoft Office)
- GanttProject, a free Gantt charting and project management app
- FreeMind, a free mind mapping application
I guess I’ll just have to fire up Java under Windows in Parallels? I guess if I’m happy to give Google all my information I could replace my use of NeoOffice with Google Docs.
Apple’s recently released Java for Mac OS X Update 3 includes the following information in the developer release notes:
As of the release of Java for Mac OS X 10.6 Update 3, the version of Java that is ported by Apple, and that ships with Mac OS X, is deprecated.
This means that the Apple-produced runtime will not be maintained at the same level, and may be removed from future versions of Mac OS X. The Java runtime shipping in Mac OS X 10.6 Snow Leopard, and Mac OS X 10.5 Leopard, will continue to be supported and maintained through the standard support cycles of those products.
Apple has released (via Software Update) “Java for Mac OS X 10.5 Update 1”, which installs Java 1.6.0_05 (although it does not make it the default version of Java for the machine.
bash-3.2$ /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Commands/java -version
java version "1.6.0_05"
Java(TM) SE Runtime Environment (build 1.6.0_05-b13-120)
Java HotSpot(TM) 64-Bit Server VM (build 1.6.0_05-b13-52, mixed mode)
The software update is installed only on 64-bit capable Macs. To switch it to the default Java install you need to use the /Applications/Utilities/Java Preferences application (which states when you select it that “Java SE 6 is only available for Java applets in 64-bit capable browsers. J2SE 5.0 will be used in 32-bit-only browsers, including Safari”)
Discussions indicate that compiled JNI libraries don’t look like they currently work, and neither do QuickTime for Java applications:
Caused by: java.lang.UnsatisfiedLinkError: /System/Library/Java/Extensions/libQTJNative.jnilib:
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
Exception in thread "main" java.lang.NoSuchMethodError: main
This is not surprising given that QuickTime for Java is based on 32-bit Carbon libraries, and has been effectively in “maintenance mode” for a while. Unfortunately someone manages to get the JNI (or JNA?) code working it’s going to be difficult to work around the problem using QTKit.
In the meantime, QuickTime for Java still muddles along in Java 5. Eclipse Ganymede also seems to launch ok, but I haven’t done anything extensive with it.
From Apple’s java mailing list:Â
We are looking for a talented, passionate and motivated engineer to join the Java team.Â Java expertise, of course, is important, but C and Objective-C (Cocoa) are also essential since you will be working on the frameworks underneath AWT and Swing.Â If you or anyone you know is interested, please do apply.Â This is an opportunity to have a serious impact on the Mac OS X Java implementation, and start a career at Apple.You can find out more by clicking this link, or by searching apple.com/jobs for Requisition ID 3489430.Â
It turns out that if your Java app is getting IPv6 addresses back from InetAddress.getLocalHost().getHostAddress() you can use flags to the Java VM to control this behaviour
if you only want IPv4 addresses returned, or
if you need to test your code against IPv6 addresses. These flags are only valid when passed to the JVM when it’s started up (ie they can’t be changed once the App’s running).
- QT-Java is now using JNI instead of jdirect. Thus QTJSupport.jar is no longer installed on Windows
- Picts now no longer have negative dimensions on Macs (an endian fix)
- Colour problems related to endianness have been fixed
- Installation can break prebinding and thus all PowerPC only apps that run on Intel Macs (ie it breaks Rosetta). Instructions on fixing this are on Apple’s site.
mostly via the quicktime-java list.
From a a post to the QuickTime-Java mailing list, Apple’s response regarding QuickTime exception -1409=Unknown:
QuickTime for Java currently provides no B-Frame sample-level support. The movie FigtreeChurch.mov, as provided by you, is encoded using H.264 (Main Profile) which utilises B-Frames. As verification, replacing FigtreeChurch.mov with a movie of another codec type functions with the your application as expected.
Chris Adamson (author of QuickTime for Java: A Developer’s Notebook) says:
QuickTime 7 adds new image compression API’s, which were necessitated by the addition of the frame-reordering H.264. These API’s, like ICMCompressionSessionEncodeFrame, were never wrapped by equivalent QTJ calls, and sending the new codec to the old image compression API produces an error.
If you’re looking to update your Java source for EasyX509TrustManager.java or EasySSLProtocolSocketFactory.java to Java 1.5.x then you can find the updated versions in Apache’s Jakarta SVN repository (Because they weren’t immediately obvious to me when I was googling).