Differences

This shows you the differences between two versions of the page.

--- at:tutorial:symbiosis [2007/07/05 09:34] – jdedecker
+++ at:tutorial:symbiosis [2008/08/01 14:41] – * tvcutsem
@@ Line 1: / Line 1: @@
-<note>This Tutorial is still under heavy construction</note>
 ====== Symbiosis with Java ======
@@ Line 57: / Line 56: @@
 If the Java method is overloaded based on arity (i.e. each overloaded method takes a different number of arguments), the number of arguments in the AmbientTalk invocation can be used to identify a unique Java method. Hence, overloading based on arity does not require special attention. If the Java method is overloaded based solely on argument types, the interpreter may derive that the actual arguments can only be converted from AmbientTalk to the appropriate Java types for one of the matching overloaded signatures. Again, if only one match remains, the unique match is invoked. In the remaining case in which the actual AmbientTalk arguments satisfy more than one overloaded method signature, the symbiotic invocation fails. It is then the AmbientTalk programmer's responsibility to provide explicit type information in the method invocation.
-Selection of the correct overloaded method is done using the **cast** method.  In the example below the expression **aVector.remove** returns a closure for the Java method **remove**.  This closure understands the **cast** method which takes a variable argument list.  The arguments supplied to this method are the types of the method that needs to be selected.  In the example below the method **remove**, which is overloaded with the primitive type **int** and the type **Object**, are first selected and then invoked with the argument **0** and the argument **3**.  In the former case the first element in the list will be removed.  In the latter case the object **3** is removed from the vector.
+Selection of the correct overloaded method is done using the ''cast'' method.  In the example below the expression ''aVector.&remove'' returns a closure for the Java method ''remove''.  This closure understands the ''cast'' method which takes a variable argument list.  The arguments supplied to this method are the types of the method that needs to be selected.  The method ''remove'' is overloaded with the primitive type ''int'', which is the index of the element that needs to be removed, and the type **Object**, which is the element that needs to be removed, in the class Vector.  To invoke the ''remove'' method that deletes elements based on their index in the vector we first select the method using ''remove.cast(jlobby.java.lang.Integer.TYPE)'' (note that primitive types are selected by referring to their associated Java class followed by the ''TYPE'' selector) and then invoke it with the argument ''0''.  Similarly, the ''remove'' method that is overloaded with the type **Object** is selected and then invoked ''3''.  In the former case the first element in the list will be removed.  In the latter case the object ''3'' is removed from the vector.
 <code>
->aVector.remove.cast(jlobby.java.lang.Integer.TYPE)(0)
+>def remove := aVector.&remove
->>
+>><java closure:remove>
+>remove.cast(jlobby.java.lang.Integer.TYPE)(0)
+>>1
 >aVector
->>
+>><java:[2, 3, 4, 5, 6, 7, 8, 9]>
->aVector.remove.cast(jlobby.java.lang.Object)(3)
+>remove.cast(jlobby.java.lang.Object)(3)
 >>true
 >aVector
->>
+>><java:[2, 4, 5, 6, 7, 8, 9]>
 </code>
@@ Line 79: / Line 80: @@
 def showSymbiosis() {
-	def javaDemo := SymbiosisDemo.new();
+  def javaDemo := SymbiosisDemo.new();
-	def atObject := object: {
+  def atObject := object: {
-		def ping() {
+    def ping() {
-          system.println("ping!");
+      system.println("ping!");
-          javaDemo.run2(self);
+      javaDemo.run2(self);
-        };
+    };
-		def pong() {
+    def pong() {
-          system.println("pong!");
+      system.println("pong!");
-        }
+    }
-	};
+  };
-	javaDemo.run(atObject);
+  javaDemo.run(atObject);
 };
@@ Line 121: / Line 122: @@
 If Java invokes a method declared in an interface with an overloaded method signature, all overloaded invocations are transformed into the same method invocation on the AmbientTalk object. In other words, the AmbientTalk object does not take the types into consideration. However, if the Java method is overloaded based on arity, the AmbientTalk programmer can take this into account in the parameter list of the corresponding AmbientTalk method, by means of a variable-argument list or optional parameters. Otherwise, the Java invocation may fail because of an arity mismatch.
+<code>
+>def test := /.at.tutorial.symbiosis
+>><obj:{super,super:=,Vector,Vector:=,aVector,...}>
+>test.showSymbiosis()
+ping!
+pong!
+>>42
+</code>
+==== Starting an AmbientTalk interpreter from Java ====
+So far, the examples have illustrated how to reuse Java code from within AmbientTalk. They have shown how to access Java classes, instantiate them and invoke methods on the resulting objects. Moreover,  AmbientTalk objects can be passed as parameters to such Java methods, provided that the method expects an interface type. Whereas the ability to reuse Java code from within AmbientTalk provides  means to e.g. build applications which offer a graphical user interface or which talk to a database, it is also often useful to embed AmbientTalk in an existing Java application.
+Embedding AmbientTalk in an application, requires one to start an AmbientTalk virtual machine, a task performed by the EmbeddableAmbientTalk class. Java programs start a virtual machine by sending an instance of this class the ''initialize'' message. The corresponding method expects the following arguments in order to be able to correctly initialize the resulting virtual machine and evaluation actor: a parsed version of the init file, a set of fields which should be visible in every actor created on the virtual machine and the network on which the virtual machine will broadcast its presence. The example below shows the default settings:
+<code>
+EmbeddedAmbientTalk vm = new EmbeddedAmbientTalk();
+vm.initialize(
+	NATParser.parse(
+		initFile.getName(),
+		Evaluator.loadContentOfFile(initFile)),
+	new SharedActorField[] {
+		vm.computeSystemObject(arguments),
+		vm.computeWorkingDirectory(),
+		vm.computeObjectPath(objectPath) },
+	"AmbientTalk");
+</code>
+The code excerpt also illustrates that the EmbeddableAmbientTalk class provides methods to create definitions for fields such as ''system'' which by default offers I/O through the console and provides access to the program arguments, ''~'' which allows addressing source files located in the working directory (i.e. the directory from which the Java application was started) and the object path (''lobby'' or ''/'') which allows loading files situated in a library path.
+Once the virtual machine is properly initialized, the embedding program can start to evaluate AmbientTalk code. The EmbeddedAmbientTalk class provides two methods to do this, namely ''evalAndPrint'' and ''evalAndWrap''. The former method can be used to write the result of evaluating the code to a PrintStream, which is used for instance to build the Interactive AmbientTalk (iat) shell. The latter can be used to return the resulting object, albeit wrapped as an object adhering to a particular interface. This wrapped object can then be used further by the Java application. In the example below we create a controller instance in a model-view-controller application by evaluating an AmbientTalk source file. This controller will take care of the distribution aspects and will be sent messages by the views when they request changes:
+<code>
+public interface Controller {
+	public void executeEvent(ApplicationEvent evt);
+	public void executeEventWithoutUndo(ApplicationEvent evt);
+	public void undo();
+}
+...
+private Controller controller =
+	(Controller) vm.evalAndWrap(
+		Evaluator.loadContentsOfFile("controller.at"),
+		Controller.class);
+</code>
+The corresponding AmbientTalk code should then return an object which implements the three methods to modify the model, and can be used to detect other reachable controllers with which it can exchange ApplicationEvents.
+<note>
+When starting an AmbientTalk virtual machine from a Java application, the resulting system is inherently multithreaded. The wrappers created by the ''evalAndWrap'' method will ensure that the Java code cannot break the concurrency properties of AmbientTalk. Moreover, by default this wrapper will ensure that the Java thread waits for the result of evaluating the AmbientTalk code which prevents concurrent access on possible Java objects used by the evaluated code. For more detailed information on this topic we refer to our [[ftp://prog.vub.ac.be/tech_report/2007/vub-prog-tr-07-15.pdf|ICDL2007 paper]].
+</note>