accessing the internal
workings of the dotnetproxy. For example, it can be used to obtain the object
database and inspect what objects exist, their reference counts, etc. From a
basic developer perspective, this bridge bean only has one method which needs
considering, and that is the method which turns tracing on and off. For example:
JavaNetBridgeBean bean = Oaa2JavaInterop.getSingleton().getJavaNetBridgeBean();
bean.setTraceMethods(false);
If setTraceMethods is called with a "true" value, then the dotnetproxy
will print information every time a java method is invoked. This can be very verbose,
and is intended only for debugging purposes.
The remaining API is almost equivalent to the OAA2 Java API with the following differences:
-
Methods and constructors which have a return value or parameters that is an array
of objects are not generated. These methods are not supported. However, an array of
String objects is supported.
-
Exceptions are not mapped to .NET. If a Java exception occurs, a System.Exception
will be thrown by the dotnetproxy assembly containing a description of the error
and the java stack trace.
-
The dotnetproxy classes are packaged starting with "jnb". For example, the java
package "com.sri.oaa2.icl" presents itself as "jnb.com.sri.oaa2.icl" in the dotnetproxy
API.
-
Every java class which is mapped has the static const "JAVA_CLASS_NAME" defined
(this does not include interfaces). Furthermore, two constructors and two static
methods which start with "new" are defined internaly to the dotnetproxy. Normally
these constructors and methods are not intended to be used. However, under special circustances
they may be required. The static methods provide the same functionality of the
constructors. The constructors are used to cast an arbitrary object to an object
of that particular type. The first constructor accepts a "JavaObject" type,
which is a mapping to the base java object (see below). The second accepts
an id and a flag inidicating whether or not to add a reference for the object.
Using these methods can be dangerous, and errors will occur if the input object
ot object id is not the expected class. Use these generated constructors and
static methods with caution, or do not use them at all.
It is important to avoid using these constructors on accident. For example, it
may appear that you can supply any object to the constructor, when in Java code that
it not the case. Understand that this constructor is only intended for casting,
and check the constructor syntax before using it.
-
For interfaces only, callback implementation stubs are provided. See the next section
on how to do callbacks with the dotnetproxy API.
In addition to the OAA classes, basic java.lang and java.util classes are also
generated. They include:
-
jnb.java.lang.*: This package contains java language classes as well
as reflection classes. The base class, "JavaObject" maps to the base java class.
Note that when the "ToString" method of any proxy object is called, the Java
"toString" method will be invoked. Also note that the proxy attempts to avoid
nameclashing with existing dotnet objects. For example, "JavaObject", "JavaLong",
"JavaString", etc.
-
jnb.java.util.*: Contains a subset of the java.util package. Some of these
interfaces and classes are used in OAA.
Back To Top
Callbacks
As mentioned, callback stubs are provided for interfaces. Suppose a Java method
has a arameter which is an interface, and you want to implement that interface in
.NET? By conventional means, it is necessary to implement that interface in .NET.
However, this is not trivial because every Java interface that is generated also
requires java object methods to be implemented, as well as underlying proxying
code. `ö QF1 ¿LÉõ_ö € € Sï < e
`ö QF1 ¿LÉõ_ö € € Sï < e
`ö QF1 ¿LÉõ_ö € € Sï < e
`ö QF1 ¿LÉõ_ö € € Sï < e