Example: Calling Java methods in the ActiveX to enterprise beans

In the ActiveX to Enterprise Java Beans (EJB) bridge, methods are called using the native language method invocation syntax.

• The following differences between Java invocation and ActiveX Automation invocation exist:

  • Unlike Java methods, ActiveX does not support method (and constructor) polymorphism; that is, one cannot have two methods in the same class with the same name.

  • Java methods are case-sensitive, but ActiveX Automation is not case-sensitive.

• Take care when invoking Java methods through ActiveX Automation. If you use the wrong case on a method call or use the wrong parameter type, you get an Automation Error 438 "Object doesn't support this property or method" thrown.

• To compensate for Java polymorphic behavior, give the exact parameter types to the method call. The parameter types determine the correct method to invoke. For a listing of correct types to use, see ActiveX to EJB bridge, converting data types.

• For example, the following Visual Basic code fails if the CLng() method was not present or the toHexString syntax was incorrectly typed as ToHexString

  ...
  Dim strHexValue as String
  strHexValue = clsMyString.toHexString(CLng(255))
  

• Sometimes it is difficult to force some development environments to leave the case of your method calls unchanged. For example, in Visual Basic if you want to call a method close() (lowercase), the Visual Basic code capitalizes it "Close()". In Visual Basic, the only way to effectively work around this behavior is to use the CallByName() method. For example

  o.Close(123)                                'Incorrect...
  CallByName(o, "close", vbMethod, 123)       'Correct...
  

  or in VBScript, use the Eval function

  o.Close(123)                                 'Incorrect...
  Eval("o.Close(123)")                         'Correct...
  

• The return value of a function is always converted dynamically to the correct type. However, take care to use the set keyword in Visual Basic. If you expect a non-primitive data type to return, use set. (If you expect a primitive data type to return, you do not need to use set.) See the following example for more explanation

  Set oMyObject = o.getObject
  iMyInt = o.getInt
  

• In some cases, you might not know the type of object returning from a method call, because wrapper classes are converted automatically to primitives (for example, java.lang.Integer returns an ActiveX Automation Long). In such cases, you might need to use your language built-in exception handling techniques to try to coerce the returned type (for example, On Error and Err.Number in Visual Basic).

• Methods with character arguments

  Because ActiveX Automation does not natively support character types supported by Java methods, the ActiveX to EJB bridge uses strings (byte or VT_I1 do not work because characters have multiple bytes in Java code). If you try to call a method that takes a char or java.lang.Character type use the JMethodArgs argument container to pass character values to methods or constructors. For more information about how this argument container is used, see Methods with "Object" Type as Argument and Abstract Arguments.

• Methods with "Object" Type as Argument and Abstract Arguments

  Because of the polymorphic nature of Java programming, the ActiveX to Java bridge uses direct argument type mapping to find a method. This method works well in most cases, but sometimes methods are declared with a Parent or Abstract class as an argument type (for example, java.lang.Object). You need the ability to send an object of arbitrary type to a method. To acquire this ability, use the XJB.JMethodArgs object to coerce your parameters to match the parameters on your method. We can get a JMethodArgs instance by using the JClassFactory.GetArgsContainer() method.

  The JMethodArgs object is a container for method parameters or arguments. This container enables you to add parameters to it one-by-one and then one can send the JMethodArgs object to your method call. The JClassProxy and JObjectProxy objects recognize the JMethodArgs object and attempt to find the correct method and let the Java language coerce your parameters appropriately.

  For example, to add an element to a Hashtable object the method syntax is Object put(Object key, Object value). In Visual Basic, the method usage looks like the following example code

  Dim oMyHashtable as Object
  Set oMyHashtable = _
      oXJB.NewInstance(oXJB.FindClass("java.utility.Hashtable"))
  
  ' This line will not work. The ActiveX to EJB bridge cannot find a method
  ' called "put" that has a short and String as a parameter:
  oMyHashtable.put 100, "Dogs"
  oMyHashtable.put 200, "Cats"
  
  ' You must use a XJB.JMethodArgs object instead:
  Dim oMyHashtableArgs as Object
  Set oMyHashtableArgs = oXJB.GetArgsContainer
  oMyHashtableArgs.AddObject("java.lang.Object", 100)
  oMyHashtableArgs.AddObject("java.lang.Object", "Dogs")
  
  oMyHashtable.put oMyHashTableArgs
  ' Reuse the same JMethodArgs object by clearing it.
  oMyHashtableArgs.Clear
  oMyHashtableArgs.AddObject("java.lang.Object", 200)
  oMyHashtableArgs.AddObject("java.lang.Object", "Cats")
  
  oMyHashtable.put oMyHashTableArgs
  
  

---

 

See Also

Example: Developing an ActiveX application client to enterprise beans

 

---