| Method Attributes | Method Name and Description |
|---|---|
|
IloOplCallJava(objectRefOrClassname, methodName, methodSignature, paramN)
This function calls a Java method from a scripting block.
|
|
|
IloOplExec(command)
Exec command
|
|
|
IloOplGetEnv(name)
This function gives access to system environment variables.
|
|
|
IloOplImportJava(path)
This function makes some Java classes available in scripting blocks.
|
|
|
includeScript(path)
This function loads the script file passed as parameter.
|
|
|
Infinity()
|
This method allows you to call Java objects and class methods from script statements and to translate their parameters and return types back and forth between Java and ILOG Script.
Translation of Input Parameters:
ilog.opl.IloOplElement. ilog.opl.IloOplModel instances. "var myObject=IloOplCallJava(...,"method1",...); IloOplCallJava(...,"method2",myObject);",
then method2 will receive the Java object as it was returned by method1. IloObjective, IloOplDataElements, etc. are not handled
and are converted to a Java String containing their Script string representation. Translation of Output Results:
ilog.opl.IloOplDataSource objects are converted to ILOG Script data sources. This allows you to
use them in ILOG Script custom Java data sources.ILOG Script Java Wrapper Object:
Java objects returned from Java calls are wrapped in a special script object that allows you to 'transport' them to further Java classes (see above). As a convenience, they also support calls to their Java methods as if they were ILOG Script methods.
For example, if you obtain an object using:
var myObject=IloOplCallJava(...);
you can call its methods using either:
var result=IloOplCallJava(myObject,"myMethod","",...);
or with the shorter and more natural:
var result=myObject.myMethod(...);
Note that the former notation does not allow you to specify a signature, so it applies only to non-overloaded methods (i.e. it does not work when the object has several methods with the same names but different signatures).
package mypackage;
import ilog.opl.*;
public class MyClass {
static public myStaticMethod(IloOplModel model,String param1) { ... }
static public MyClass createInstance() { ... }
public MyClass() { ... }
public int performStuff(int param) { ... }
}execute {
IloOplImportJava("my_application_classes.jar");
// a simple call to a static method, giving parameters of different types:
IloOplCallJava("mypackage.MyClass", // class name
"myStaticMethod", // method name
"", // signature omitted, no ambiguity
thisOplModel,"p2"); // parameters
// same call with full signature:
IloOplCallJava("mypackage.MyClass", // class name
"myStaticMethod", // method name
"(Lilog/opl/IloOplModel;Ljava/lang/String;)V", // signature
thisOplModel,"p2"); // parameters
// a call to a static method returning a Java object instance:
var myObject=IloOplCallJava("mypackage.MyClass",
"createInstance","");
// calling directly the constructor:
var myObject=IloOplCallJava("mypackage.MyClass",
"<init>","");
// use the returned instance to call an instance method, giving some parameters,
// and that returns a simple int:
var result=IloOplCallJava(myObject, // object
"performStuff", // method
"", // signature omitted
13); // parameter
// the exact same call using direct script call shortcut:
var result=myObject.performStuff(13);
}It calls the Standard C library function getenv() internally.
| Note |
Do not confuse this function with the IBM ILOG Concert class IloEnv,
which creates environment instances that manage memory and identifiers for modeling objects.
|
execute {
writeln(" doesnotexist = ",IloOplGetEnv("doesnotexist"));
writeln(" PATH = ",IloOplGetEnv("PATH"));
}undefined.It expands the search path for the next calls to IloOplCallJava.
This method uses the resolver path (see IloOplSettings) to resolve the given path.
Relative paths or JAR file names are searched relative to the model file directory as well as in
other directories of the search path.
It is not necessary that the added path exists and its existence is not checked, as with any Java classpath. This allows you to add, for example, both the debug/release version of some classes in the path, and still work, whatever the version actually installed.
If your classes are not properly defined in the path you give, a
script error is raised (ClassNotFoundException exception) during the call to IloOplCallJava.
The first call to this function initializes the Java call support in ILOG Script. To do so, the implementation needs a Java Virtual Machine. If you are already running a Java Virtual Machine (as is the case in an OPL Java application or in an ODM application), that JVM is used. Otherwise, a new Java Virtual Machine is created. It looks for a Java Runtime Environment by using, in this order:
Note: If the environment variable JAVA_HOME is not set, the IloOplImportJava function will not work.
When a new Java Virtual Machine is created, its classpath is initially set with the OPL JAR files from the OPL installation. It also includes the ODM JAR files from the ODM installation if ODM has been installed. This allows the custom Java code to use the OPL and ODM Java APIs.
The OPL installation is found by using:
The ODM installation is found by using:
Calling external functions is not possible if the application is statically linked with the
OPL libraries (like oplrunsample). This is because the Java OPL library uses the
shared library version of OPL (oplxx.dll/.so) which cannot be mixed with the static
version. You can use an external call to Java in the OPL IDE, in oplrun, and in custom OPL or
ODM applications launched from Java.
execute {
IloOplImportJava("./classes");
IloOplImportJava("C:/myjars/my_global_classes.jar");
IloOplImportJava("my_application_classes.jar");
IloOplCallJava("MyClass","performStuff","");
}The path can be either absolute or relative.
If this path does not designate an existing file, the file is searched for using a method that depends on the application in which the script is embedded. Typically, the name of the script file is searched for in a list of directories specified in the application setup.
The effect of this function is the same as for loadFile. In OPL, you
have to use includeScript, as the function loadFile
does not recognize OPL objects, such as thisOplModel.
Limitation
Flow control instructions and global functions cannot be called from an external JavaScript file.
This limitation affects the following JavaScript classes:
IloOplCplexBasis, IloOplCplexVectors, IloOplDataElements, IloOplDataSource,
IloOplModelDefinition, IloOplModelSource
and JavaScript global functions:
IloOplCallJava, IloOplGetEnv, IloOplImportJava
Example showing the limitation:
Consider a function, such as myFunction below, in an external JavaScript file called a.js.
functionmyFunction(modName, masterOpl) {
var subSource = new IloOplModelSource(modName);
var subDef = new IloOplModelDefinition(subSource);
var subCplex = new IloCplex();
[...]
}
This example contains the limitation, as the file a.js is called from a main execution block.
main {
[...]
includeScript( "a.js" );
var res = myFunction("cutstock-sub.mod", masterOpl);
[...]
}
A workaround for this limitation is:
a.js:
functionmyFunction(Classes, modName, masterOpl) {
var subSource = new Classes[0](modName);
var subDef = new Classes[1](subSource);
var subCplex = new Classes[2]();
var subOpl = new Classes[3](subDef,subCplex);
var subData = new Classes[4]();
[...]
}
and in the main model:
main {
[...]
// Missing classes....
var classes = new Array( IloOplModelSource, IloOplModelDefinition, IloCplex, IloOplModel, IloOplDataElements);
includeScript( "a.js" );
[...]
var res = myFunction(classes,"cutstock-sub.mod", masterOpl);
[...]
}
execute {
includeScript("../kpiFile.js");
}