This is a feature of JBuilder Enterprise.
To open the Properties dialog box for an IDL file, right-click an IDL file in the project pane and select Properties. In order for this dialog box to display, select VisiBroker as the IDL Compiler on the Build page of the Project Properties dialog box.
The Properties dialog box for VisiBroker IDL enables you to specify options for compiling remote interfaces defined in the Interface Definition Language (IDL). When an IDL file is compiled, it generates Java interface definitions and Java client stubs and server skeletons. This allows a Java client to transparently invoke an IDL object that resides on a remote server or allows a Java server to define objects that can be transparently invoked from IDL clients.
When the IDL compiler, idl2java,
a Java-based preprocessor, is invoked by right-clicking on an IDL file and selecting Make, the IDL source file is compiled, and a directory structure containing the Java mappings for the IDL declarations is created. Typically, one IDL file will be mapped to many Java files that marshall/unmarshall Java data types to CORBA types and provide IIOP messaging. IDL file names must end with the .idl extension. More information about this compiler is available in the VisiBroker for Java Reference Manual.
When this option is selected, you can set compiler options, add the compiled files and/or packages to the current project, and view compiler output.
When this option is checked, selecting OK sets the options to be used by the VisiBroker tool idl2java
, a Java-based preprocessor, when the IDL file is compiled. Set the correct options so that when compiled, Java interface definitions and Java client and server stubs and skeletons are generated.
When the Process This IDL File option is not checked, selecting OK saves the selected options, but does not call the idl2java
compiler when the IDL file is compiled. This means that the client stubs and server skeletons are not generated when the IDL file is compiled.
The first step to creating an application of this type to specify all of your objects and their interfaces using the OMG's Interface Definition Language (IDL). The IDL can be mapped to a variety of programming languages. The IDL mapping for the Java language is summarized in the chapter titled "The IDL to Java Mapping" in the VisiBroker for Java Reference Manual.
The interface specification you created is used to generate stub routines for the client program and skeleton code for the object implementation. The stub routines are used by the client program for the method invocations. You use the skeleton code, along with code you write, to create the server that implements the object. The code for the client and object, once completed, is used as input to your Java compiler to produce a Java applet or application and an object server.
This page provides options for modifying the Java source code generated when an IDL source file is compiled. By default, a Java-based preprocessor compiles an IDL source file and creates a directory structure containing the Java mappings for the IDL declarations. Typically, one IDL file will be mapped to many Java files because Java allows only one public interface or class per file.
The options are discussed in more detail in the chapter titled "Programmer Tools" in the VisiBroker for Java Reference Manual.
Code is generated in the specified package. The package name for definitions is prepended with the specified package name. If a directory with the specified package name does not exist, it will be created. If the package directory exists, its contents will be updated. When this option is not set, idl2java
generates code using the CORBA package resolution rules.
When this option is selected and the IDL file is compiled, code which can run on any CORBA-compliant ORB is generated. This means that any VisiBroker-specific code will not be generated, including code that generates smart stubs. Selecting this option also suppresses the generation of toString()
and bind()
methods.
If unselected, the portable stubs will not be generated. VisiBroker-specific extensions and optimizations will be present in the code that is generated. Generated stubs will specifically be for use in VisiBroker ORB environments.
When this flag is on, the compiler generates skeleton code using the Dynamic Skeleton Interface (DSI). To understand how to do any type of DSI, create an IDL file, select this option, compile, and look at the skeleton code.
For more information on this option, see the chapter titled "The Dynamic Skeleton Interface" in the VisiBroker Programmer's Guide.
When this option is selected, example classes will be generated when the IDL file is compiled. If unchecked, the generation of example classes will be suppressed.
When this option is selected, comments will be generated in the generated code. If unchecked, comments will be suppressed in the generated code.
When this option is selected, _tie
classes will be generated when the IDL file is compiled. If unchecked, the generation of _tie
classes will be suppressed.
The tie mechanism offers an alternative when it is not convenient or possible to have your implementation class inherit from the VisiBroker skeleton class. Object implementation classes must inherit from the VisiBroker skeleton class. Java does not allow multiple class inheritance and you may want your implementation class to inherit from a different class.
Inheritance is easier to use than the tie mechanism because implementation objects look and behave just like object references. If an implementation object happens to be in the same process as a client using it, operation invocations involve less overhead because no transport, indirection, or delegation of any kind is required.
The tie mechanism provides a delegator implementation
class that inherits from org.omg.CORBA.Object
. The delegator implementation class does not provide any semantics of its own. It simply delegates every call to the real implementation class, which can be implemented separately and can inherit from whichever class it wishes.
The Operations
class defines all of the methods that must be implemented by the object implementation. This class acts as the delegate object for the associated _tie
class when the tie mechanism is used.
For more information on this option, see the chapter titled "The Tie Mechanism" in the VisiBroker Programmer's Guide.
Click the ellipsis button to open a dialog box that allows you to select a directory to be searched for the list of files to include in the build. You must select a directory that contains an .idl
file.
This field allows you to specify options that are not available in this dialog box. For a list of possible options, see the VisiBroker for Java Reference Manual section "Programmer Tools: idl2java".
This is the equivalent of the command line parameter -idl2package idl pkg
. It puts definitions in scope of idl into the specified Java package, for example:
-idl2package ::CORBA org.omg.CORBA
What this means is that if any part of the IDL file is in the scope ::CORBA, then the java code generated for it is placed in the java package org.omg.CORBA.
In this example, the IDL has a module name of CORBA
. When the Java code is generated, these CORBA
classes should have the org.omg.CORBA
name space. To do this, set the idl2package option of ::CORBA
to org.omg.CORBA
.
When this option is not set, the idl2java compiler generates code using the CORBA package resolution rules.
This page displays symbols defined for conditional compilation.
Displays a list of symbols defined for conditional IDL compilation. Click New to add a new symbol, click Delete to delete the highlighted symbol.
Opens a dialog box that enables you to define a symbol name for conditional IDL compilation, for example #define name def
.
This button enables you to delete the selected symbol from the list of symbols defined for conditional compilation.
When the Process This IDL File option is checked, selecting OK sets the options to be used by the VisiBroker tool idl2java
, a Java-based preprocessor, when the IDL file is compiled. Set the correct options so that when compiled, Java interface definitions and Java client and server stubs and skeletons are generated in a subdirectory of the project with the same name as the project.
When the Process This IDL File option is not checked, selecting OK saves the selected options, but does not call the idl2java
compiler when the IDL file is compiled. This means that the client stubs and server skeletons are not generated when the IDL file is compiled.