Fabrizio Giudici's Blog: Wow, Landon, it somewhat works (Mac OS X, opensource Java 6, NetBeans 6)

My pages	Projects	Communities	java.net

Get Involved

java-net Project

Request a Project

Project Help Wanted Ads

Publicize your Project

Get Informed

java.net Online Books

java.net Archives

Get Connected

java.net Forums

Wiki and Javapedia

People, Partners, and Jobs

Java User Groups

RSS Feeds

Search

Online Books:

Advanced Search

Fabrizio Giudici's Blog

«New improvements for building NetBeans RCP apps - and OpenBlueSky available | Main | My JavaPolis Agenda »

Wow, Landon, it somewhat works (Mac OS X, opensource Java 6, NetBeans 6)

Posted by fabriziogiudici on November 26, 2007 at 01:50 PM | Comments (4)

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:

1. in $NETBEANS/bin/netbeans (the launcher), you need to remove a couple of lines:

            -J-Xdock:name=NetBeans \
            '"-J-Xdock:icon=$progdir/../nb6.0/netbeans.icns"' \

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.

2. In $NETBEANS/etc/netbeans.conf (the configuration file), you need to specify the SoyLatte path:

netbeans_jdkhome=/usr/local/soylatte16-i386-r2

and 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 Library/Preferences/it.tidalwave.bluemarine.plist).

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 image
        at java.awt.image.AffineTransformOp.filter(AffineTransformOp.java:267)
        at it.tidalwave.image.java2d.Java2DUtils.scaleWithAffineTransform(Java2DUtils.java:290)
        at it.tidalwave.image.java2d.ScaleJ2DOp.execute(ScaleJ2DOp.java:95)
        at it.tidalwave.image.java2d.ScaleJ2DOp.execute(ScaleJ2DOp.java:51)
        at it.tidalwave.image.op.OperationImplementation.execute(OperationImplementation.java:80)
        at it.tidalwave.image.EditableImage.internalExecute(EditableImage.java:824)
        at it.tidalwave.image.EditableImage.execute2(EditableImage.java:450)

Again, 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.X11GLDrawableFactory
        at java.lang.Class.forName0(Native Method)
        at java.lang.Class.forName(Class.java:169)
        at javax.media.opengl.GLDrawableFactory.getFactory(GLDrawableFactory.java:111)
        at javax.media.opengl.GLJPanel.initialize(GLJPanel.java:900)
        at javax.media.opengl.GLJPanel.paintComponent(GLJPanel.java:488)

I think it's a matter of dynamic libraries, probably the system is try to load the wrong one.

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.

Technorati Tags: SoyLatte, Mac OS X, Java 6, NetBeans, blueMarine

Bookmark blog post:

del.icio.us

Digg

DZone

Furl

Comments

Comments are listed in date ascending order (oldest first) | Post Comment

Forgot to say: NetBeans compiles the project fine, but it can't run it. I suspect that the problem is again those -Xdock:*** options - I was able to launch it with a script.

Posted by: fabriziogiudici on November 26, 2007 at 01:59 PM

That's. Amazing! Good work from both of you.

Posted by: mpetersen on November 26, 2007 at 02:13 PM

This is indeed impressive that the port is already this far along.

However, will this ever be a viable option for anyone other than developers? IMHO, I can't count on an end user on OS X (or any other) OS unless the JDK comes down via Software Update.

Since I can't count on this on Windows I still bundle a private JRE, which is ridiculous but necessary if you want people to use your software. Luckily bandwidth and disk space are both cheaper than they used to be. So I guess I'd be left bundling SoyLatte with my app, but I'm not sure that will work on OS X.

Secondly, the lack of native Swing bindings is major. This is real, hard core work that would have to be done. There isn't any code that I know of that can be ported, massaged, re-compiled, etc. to get a head start.

I'm pretty much giving up on OS X as a deployment platform. If Apple ever decided to release Java 6, or the community produces something that end users can take advantage of, that will be great. But otherwise I'm not going to lose sleep over this. I can't give my OS X customers adequate support if Apple is going to be so secretive about things. What on earth do I say when a customer asks when a new version of my software will be available for OS X when the Win32 and Linux versions are already out? One hates to play the blame game but I'm inclined to pass the blame on to Apple in this case. Why should I take the blame? Because I decided to build a Java application on a supposed "world class Java platform"?

Posted by: bwy on November 28, 2007 at 02:22 PM

Bundling SoyLatte should work, since the installation is just a tar xvzf and you can freely choose the target directory.

If you have tight timeframes and the tradeoff are too much for you, I perfectly understand your points. The relevance of SoyLatte for the desktop is I think is in the six months horizon. Now that there's a working base, I bet people will start addressing the missing points and we will have a decent desktop edition for the Summer.

Posted by: fabriziogiudici on November 28, 2007 at 02:38 PM

Powered by
Movable Type 3.01D

java.net RSS Feeds