Wow, Landon, it somewhat works (Mac OS X, opensource Java 6, NetBeans 6)
Well, one of the most recent scoops is SoyLatte, Landon Fuller's port of the FreeBSD version of Java 6 to Mac OS X. He has just released a binary distribution, so I just gave it a try after lunch (too bad I don't have other time at the moment...).
First, the thing installs by just untarring an archive in the appropriate place (Landon suggests
/usr/local/soylatte16-i386-r2) - and remember to fix the permissions and flags.
Then I tried running NetBeans 6.0RC2. First, you need to start X11 (from Applications/Utilities) and then execute
setenv DISPLAY :0.0. Then you need to apply some patches:
$NETBEANS/bin/netbeans (the launcher), you need to remove a couple of lines:
-J-Xdock:name=NetBeans \They are used on Mac OS X to set the main menu name and the application icon; but SoyLatte Java executable doesn't know about them, complains and stops.
$NETBEANS/etc/netbeans.conf (the configuration file), you need to specify the SoyLatte path:
netbeans_jdkhome=/usr/local/soylatte16-i386-r2and you need to fix the L&F settings appending this:
netbeans_default_options=".... existing options.... --laf com.sun.java.swing.plaf.gtk.GTKLookAndFeel -J-Dswing.aatext=true"otherwise NetBeans will die soon after showing the splash screen. With these settings NetBeans 6.0 starts fine and - apart from an issue about menus being difficult to select - I could somewhat work and compile a project.
At this point... I gave a quick try to blueMarine! I needed to apply the same fixes as above (removing the
-Xdock:*** stuff and using the GTK L&F instead of Quaqua - which maybe can also work, but I didn't have time to try).
I had a blocking issue (NPE) with Derby when it tried to initialize the workspace with some default catalog data. Honestly I'm not sure this is a fault of SoyLatte - I've just upgraded Derby to the latest version and there could be some issue. So I initialized it by running blueMarine with the Apple VM and then restarted it with SoyLatte (it was not immediate for me to realize that now the application preferences are in
.java/.userPrefs/it/tidalwave/bluemarine/prefs.xml rather than in
The most evident issue is the extreme slowness of the imaging engine. It's no big surprise: my imaging engine uses different approaches for image processing according to the operating system, choosing the faster one. I've blogged multiple times about how dramatic can be these performance differences - now the point is that the selection should be probably made according to the configure graphic pipeline, rather than the operating system. For the same reason, the full screen photo viewer doesn't work:
Caused by: java.awt.image.ImagingOpException: Unable to transform src imageAgain, I think this should go away with the same fix about the graphic pipeline.
The drawing performance is not the best, as scrolling the thumbnail grid you see some artifacts during the repaint. The JOGL stuff doesn't work at all, failing with:
java.lang.NoClassDefFoundError: Could not initialize class com.sun.opengl.impl.x11.X11GLDrawableFactoryI think it's a matter of dynamic libraries, probably the system is try to load the wrong one.
at java.lang.Class.forName0(Native Method)
So, there are problems, but after all blueMarine is a complex application and SoyLatte is still a preview. In any case, I think they could go away with just some work. The menu stuff probably is something that should be addressed by SoyLatte.
Now, does this make any sense? After all the wrong fonts, the menu bar not in the good position, the keyboard accelerator with CTRL instead of the CMD key would cause a stroke to most of the normal Apple users. Well, there's a discussion about this at JavaLobby and I already expressed there my opinion.