Table of Contents Previous Section

Wrapping Your Objective-C Classes

"bridget" (NEXT_ROOT/NextDeveloper/Executables/bridget.exe) uses information supplied on a per-package basis by a Java Objective-C Binding Specification file (.jobs) and builds a package of Java classes whose native implementations are provided in C stub code (which is also generated by bridget). The .jobs file, which you must manually construct, specifies exactly what should be done on a per class, type, and method basis.

bridget produces a file (the name of which you specify in your .jobs file) which contains initialization code for the wrapper classes. This file must be compiled and included in your dll in order for your application to work. See NEXT_ROOT/NextDeveloper/Examples/Java for examples of how to use bridget to wrap an Objective-C class, and "Compiling and Linking Wrapped Classes," below, for tips on compiling bridget-generated files.

After first processing the .jobs file and building up an idea of what classes, protocols, and methods are being wrapped, bridget processes the Objective-C header files specified in the .jobs file to obtain the actual parameter and return type details. Assuming that no errors are detected, bridget then generates the various output files.

Invoking bridget

bridget is a command-line too that's invoked as follows: 

bridget [-IjobsDirPath] [-stubs] [-java] [-init] [-missing] [-o destDirPath] jobsFile

If neither -stubs, -java, -init, or -missing are specified, -stubs, -init, and -java are assumed. Thus, with no options bridget will write the Objective-C stub code, the library initialization code, and the java class files in the current directory.

bridget searches both the current directory and NEXT_ROOT/NextDeveloper/jobs for any imported .jobs files.

Compiling and Linking Wrapped Classes

When compiling and linking files generated with bridget, you'll need to specify the following header include paths: You'll also need to include NEXT_ROOT/NextLibrary/JDK-1_0_2/lib in your library search path, and you'll need to link in library javai.lib.

jobs File Reference

If you have Objective-C classes and/or Frameworks that you need to access from Java, you'll need to build a .jobs file and feed it to bridget, which will in turn build the Java methods and the Objective-C support library. Each .jobs file describes what will become a single Java package composed of wrapped Objective-C classes. Although the .jobs file may at first look complex, many of its sections---such as those that include Java code and those that add "helper" Objective-C source code---are optional.

NEXT_ROOT/NextDeveloper/Java contains the .jobs files used to create the next.util, next.eo, and next.wo frameworks that are shipped with the WebObjects Java Extensions. These files should serve as a good starting place to learn how to construct your own .jobs files.

The complete syntax of a .jobs file is illustrated in the following contrived example: 

// ExhaustiveExample.jobs - an example

name Junk
// The name "Junk.m" will be used for the library initialization file.
// You must specify this.

header AppKit/AppKit.h
// Required. This causes bridget to search through the AppKit for the 
// Objective-C classes to wrap

import NextJava.jobs
// Essentially required. This provides the standard mappings for Foundation

preinit-callout your_pre_initialization_function
// Optional. Allows you to insert code to initialize your subsystem before
// anything else is done.

postinit-callout your_post_initialization_function
// Optional. Allows you to insert code to initialize your subsystem after
// we do our thing.

stub-import MyHeader.h
// Optional. Allows you to specify a file that should be imported by the
// stub files. This is useful if you have to write a few category
// methods to cover unmappable cases like varargs.

// Global type mappings (sometimes useful)
type
NSButtonType = int
NSGradientType = int

// Routines for doing mapping and translations of objc and java classes
map
NSDate = java.util.Date using ObjCDateToJavaDate JavaDateToObjCDate
// the types are id and java handles (NSJavaHandle).

// Global selector mappings
selector
-insertNewButtonImage:in: = insertImageIntoButtomCell

// Allows you to specify some pure Java code that will go at the top of 
// the Java package declaration
@top{
   // some java constants to stand in for enumerations
   static final int ViewNotSizable = 0;
   static final int ViewWidthSizable = 2;
@}

// Wrap a protocol. Java doesn't allow a constructor in an interface,
// so the -init... method has to be requested for each interface implementor
protocol NSColorPicking = com.yourFirm.Junk.ColorPicking
-provideNewButtonImage
-viewSizeChanged:
-alphaControlAddedOrRemoved:
-attachColorList:
-detachColorList:
-setMode:

// Wrap a class
class NSColorPicker = com.yourFirm.Junk.ColorPicker
implements NSColorPicking
// The above causes all NSColorPicking methods to get wrapped

constructor -initWithPickerMask:colorPanel:
// A special effort is made to map this to an appropriately typed constructor

use all methods
// The above, although convenient, should be used with care.

// Some Java code for the ColorPicker class
@{
   public static ColorPicker defaultPicker; // a global!
@}

// Wrap additional classes
// (exercise left for the reader)

// Some Java code to be placed at the bottom of the package
@end{
   private class notSeenAnywhereElse {
      int secret() { return 2001; }
   }
@}

Table of Contents