the waiting game

No matter what apple says about Java development on the Mac, I always hated the waiting game before I could use some new Java API. First, it was Java 5 Tiger, which because apple ports it themselves to the platform, lagged considerably behind the Sun release. Then, it was Java3D and the JAI API. Even now, the Java3D API on OSX is at 1.3. I'm just glad that the JOGL and Java3d folks found a way to bypass Apple's porting process this time with Java3D 1.5.

Java3D is currently at 1.4.0 stable and has a 1.5 dev version out. The key to all of this is that the 1.5 branch includes the ability to use JOGL to bind the Java3D API to the native OpenGL implementation. What does this provide? Well, since JOGL is already ported to OSX, we can install Java3D 1.5 and JOGL and upgrade our outdated Java3D!

how to do it

Prerequisites

• Java 1.5
• Mac OS 10.4

Procedure

1. Download the windows binary of Java3D 1.5 from the Java 3D site
2. Replace the three jars (j3dcore.jar, j3dutils.jar, vecmath.jar) located in /System/Library/Java/Extensions with the ones in the java3d download. You can back up your old jars to easily revert.
3. Download JOGL (now called Java Bindings for the OpenGL API). They have a PPC and universal download, as it's a JNI library
4. Extract the jogl-natives-macosx-[ppc|universal].jar and copy libjogl.jnilib, libjogl_awt.jnilib, and libjogl_cg.jnilib to /System/Library/Java/Extensions. Make sure to copy jogl.jar here also.
5. Optional: Test out your install by downloading the j3d-examples

Have fun with all the new features!

Posted by jharwig Jun 28 2006, 08:19:45 PM EDT
Permalink Comments [5]

The problem..

If I had been allocated one Firefox extension to use, without hesitation it would be Joe Hewitt's Firebug. But, eventually, I have to test my code in IE (and Safari¹), and need to debug some DOM or css scripting. Many times I would use the url field to execute Javascript in the page using this method...

javascript:function(){ /* some code */ }()

Wrapping the code in a function will prevent variable name collisions. The problem is that this method can get messy and time consuming when trying to inspect elements nested deep within the DOM.

An answer?

I created a bookmarklet that allows you to inspect DOM elements, just like Firebug². Using a bookmarklet allows it to run in any javascript browser, including Firefox. After inspection, a console can be used to modify and query the object. How does it work? The bookmarklet is just a stub that loads the external javascript file³. It adds a click and mouseover handler to the document body object. The mouseover handler adds a window status message with the highlighted DOM tree, and the click attribute opens the inspector.

The inspector has a console with the variable clicked_element pointing to the element. Common attributes like id, class and innerHTML can be edited live. All other attributes can be viewed (or changed using the console) and the computed style is also available.

Download

Save the bookmarklet archive, or try it out on this page. (You can also bookmark this link directly)

Screenshots

• DOM tree
• Editing Attributes
• Console

Todo

• Allow inspecting of active elements - buttons, links
• Improve inspector look
• Editing innerHTML containing ' breaks

³IE 6 has huge limitation in that the url is only parsed to 512 characters. The external javascript is also much easier to maintain.