Thanks!

Thanks to everyone who's been sending in bug reports and ideas or otherwise supporting JarInspector! Your feedback is greatly appreciated. I just uploaded release candidate 5 which I planned to be the last before the final version. Go get it at codeland.org

Converting NSString to OSType

OSTypes, formerly known as ResTypes, are four byte sequences to identify data formats and creator applications under MacOS X. To convert from NSString to OSType the straight forward solution might be:

OSType convertNSStringToOSType(NSString* str) {
OSType app = 0;
memcpy(&app, [str cstring],sizeof(app));
return app;
}

which works but of course ignores the encoding completely. So:

OSType convertNSStringToOSType(NSString* str) {
OSType app = 0;
NSData* data = [str dataUsingEncoding: NSUTF8StringEncoding];
[data getBytes:&app length:sizeof(app)];
return app;
}

This works great until moving the whole thing to Intel! For a java hacker puzzling at first but then, recalling computer architecture class, the endians! So a look in the Universal Binary Programming Guide yields

OSType convertNSStringToOSType(NSString* str) {
OSType app = UTGetOSTypeFromString((CFStringRef)str);
return app;
}

The CFString cast is okay http://www.cocoadev.com/index.pl?CFStringRef

Building Universal Binaries for Cocoa-Java based Apps

With the introduction of Intel based Macs, Apple also introduced a new binary format that is capable to run natively on both architectures x86 and PowerPC. The Apple developer tools feature support for all project types to compile universal binary versions. For all projects types? All but Cocoa-Java based ones.
Apple silently dropped support for Cocoa-Java which might explain the lack of information on how to build universal binaries for Cocoa-Java based apps. In general it is quite simple but there are a few non obvious obstacles. In order to create universal binaries the respective target in XCode must be upgraded to native. XCode, however, prohibits targets with java source code to be upgraded. The solution is to split the target in pure Obj-C part and a pure Java part. See this post on the XCode mailing list. Since the release J2SE 5.0 Release 4 the above approached fails with "Unable to find class:" exceptions or similar unless you make sure both targets specify the same target VM (1.3*, 1.4* ..). See also Technical Q&A QA1474.

JarInspector 1.0b5

The JarInspector version 1.0 beta 5 has just been released. The beta 5 is a landmark release with a newly designed document based architecture. The new architecture is an important step towards the first release candidate (1.0RC1) as well as future versions. But it is already visible in the current beta which includes a feature for multiple jar file edit. Additionally the manifest editor has advanced to a general purpose editor for jar file contents. This means you can edit web.xml, jboss.xml and suchlike on the fly without the need to extract and rebuild the whole jar.

In summary the features are:

- jar file viewer
- integrated editor
- syntax highlighting
- java class decompiler
- file extraction
- full integration into Mac OS X

You can download the JarInspector here

A jar file viewer for Mac OS X

The Jar Inspector is a cocoa based application for Mac OS X. It is a utility to view and edit jar files on the mac. Currently it features:

• a file manager for jar entries
• manifest viewer and editor
• file extraction
• java decompiler

Go check it out at codeland.org

qmail and Mac OS X

I still get a lot of hits on my site from people searching for qmail+macosx. Back in 2001 I wrote a tutorial on howto setup qmail on macosx but lost it during a server crash in 2003, sorry. Anyway, qmail needed a patch to compile on osx. The patch is still there. You can get it here. Maybe this is of help for you. Please note that the patch is not from me but credit goes someone that also worked on the topic back then (don't remember the name). It is probably out of date anyway. I personally switched from qmail to postfix cause qmail required to lot of effort maintaining and adjusting to each new version of osx.

JBoss, myfaces and tomahawk extensions

Jboss uses Apache myfaces as JSF implementation. The api and impl packages are included in jbossweb-tomcatXX/jsf-libs. Unfortunately when trying to deploy a webapp that uses the tomahawk extensions you run into classloading problems (java.lang.ClassCastException) because the impl package as well as the tomahwak.jar contain both shared classes. To solve these problems make sure that all jars are loaded by the same classloader (i.e. copy tomahawk.jar to jbossweb-tomcatXX/jsf-libs or remove jsf-libs and add myfaces-api.jar, myfaces-impl.jar and tomahawk.jar to your WEB-INF/libs). With the former solution, however, you're not able to access any resources from your webapp. Therefore it is best if you remove the jsf-libs and include all required libs in the webapp.