Java Interface Library/en - Versionsgeschichte

Cg am 18. März 2021 um 08:17 Uhr

2021-03-18T08:17:21Z

← Nächstältere Version		Version vom 18. März 2021, 08:17 Uhr
Zeile 693:		Zeile 693:
	Back to [[Plugins]]<br>		Back to [[Plugins]]<br>
	Back to [[Online Documentation#Library and Plugin Overview\|Online Documentation]].		Back to [[Online Documentation#Library and Plugin Overview\|Online Documentation]].

			[[Category: Plugins/en]]
			[[Category: Advanced/en]]

Mawalch: Link fix

2018-02-11T12:20:30Z

Link fix

← Nächstältere Version		Version vom 11. Februar 2018, 12:20 Uhr
Zeile 692:		Zeile 692:
	----		----
	Back to [[Plugins]]<br>		Back to [[Plugins]]<br>
	Back to [[~~OnlineDocumentation~~#Library and Plugin Overview\|Online Documentation]].		Back to [[Online Documentation#Library and Plugin Overview\|Online Documentation]].

Mawalch am 3. Januar 2018 um 13:27 Uhr

2018-01-03T13:27:17Z

← Nächstältere Version		Version vom 3. Januar 2018, 13:27 Uhr
Zeile 690:		Zeile 690:
	[[Java Interface Library v2 \| Version 2 of the Java Interface Library]]		[[Java Interface Library v2 \| Version 2 of the Java Interface Library]]

			----
	<hr>
	Back to [[Plugins]]<br>		Back to [[Plugins]]<br>
	Back to [[OnlineDocumentation#Library and Plugin Overview\|Online Documentation]].		Back to [[OnlineDocumentation#Library and Plugin Overview\|Online Documentation]].

Mawalch am 5. Juni 2017 um 19:36 Uhr

2017-06-05T19:36:26Z

← Nächstältere Version		Version vom 5. Juni 2017, 19:36 Uhr
Zeile 643:		Zeile 643:
	JavaScript: JAVA::Java.newWithServerForJavaPath("my\path\to\java.executable".asFilename());		JavaScript: JAVA::Java.newWithServerForJavaPath("my\path\to\java.executable".asFilename());

	=====newConnectedTo:~~aHhostString~~ port:aPortNumber withTimeout:aTimeoutSeconds=====		=====newConnectedTo:aHostString port:aPortNumber withTimeout:aTimeoutSeconds=====
	* This is used to connect to a running Java Bridge on the network. The Java Bridge must be started in server mode on the remote host. After connecting a new connected instance of JAVA::Java is returned.		* This is used to connect to a running Java Bridge on the network. The Java Bridge must be started in server mode on the remote host. After connecting a new connected instance of JAVA::Java is returned.
	:: '''aHostString''' - the hostname or IP of the remote machine as String		:: '''aHostString''' - the hostname or IP of the remote machine as String

Mawalch am 3. Juni 2017 um 19:19 Uhr

2017-06-03T19:19:05Z

Änderungen zeigen

Mawalch: Spelling fixes

2017-05-28T15:38:19Z

Spelling fixes

← Nächstältere Version		Version vom 28. Mai 2017, 15:38 Uhr
Zeile 264:		Zeile 264:
	observer := java Observer new.		observer := java Observer new.
	observer update:[:sourceObservable :argument\|		observer update:[:sourceObservable :argument\|
	argument notNil ifTrue:[ Transcript showCR:('I was ~~notifyed~~ with: ',argument toString) ]		argument notNil ifTrue:[ Transcript showCR:('I was notified with: ',argument toString) ]
	ifFalse:[ Transcript showCR:'I was ~~notifyed~~ and the argument was nil' ].		ifFalse:[ Transcript showCR:'I was notified and the argument was nil' ].
	].		].
	myObservable addObserver:observer.		myObservable addObserver:observer.

Mawalch am 28. Mai 2017 um 15:29 Uhr

2017-05-28T15:29:37Z

← Nächstältere Version		Version vom 28. Mai 2017, 15:29 Uhr
Zeile 236:		Zeile 236:
	If there are both fields and methods by the same name, and you use the non-explicit call,		If there are both fields and methods by the same name, and you use the non-explicit call,
	the bridge will always assume that you want to call the getter/setter and perform a method call.		the bridge will always assume that you want to call the getter/setter and perform a method call.


	== Callbacks from Java ==		== Callbacks from Java ==

Mawalch: Spelling fixes

2017-05-28T15:29:04Z

Spelling fixes

← Nächstältere Version		Version vom 28. Mai 2017, 15:29 Uhr
Zeile 33:		Zeile 33:


	This setup allows for transparent communication with objects inside a local or remote Java VM. This may be either utility functions which happen to be convenient for the test application (for example: file parsing, syntax analysis, protocol ~~implementaitons~~ or access to specific hardware via driver libraries), or the tested application in the system under test itself.		This setup allows for transparent communication with objects inside a local or remote Java VM. This may be either utility functions which happen to be convenient for the test application (for example: file parsing, syntax analysis, protocol implementations or access to specific hardware via driver libraries), or the tested application in the system under test itself.

	Especially, it allows for the objects of the tested application to be looked into, manipulated and for functions of it or underlying frameworks to be called.		Especially, it allows for the objects of the tested application to be looked into, manipulated and for functions of it or underlying frameworks to be called.
Zeile 43:		Zeile 43:
	Notice that a similar mechanism is used in expecco to communicate with DOTNET, Qt (C++) and C applications.		Notice that a similar mechanism is used in expecco to communicate with DOTNET, Qt (C++) and C applications.




	== Initializing / Releasing the Bridge ==		== Initializing / Releasing the Bridge ==
Zeile 94:		Zeile 92:
	====Startup Parameters====		====Startup Parameters====
	You can use any parameter in any order.		You can use any parameter in any order.
	If no parameter is used then the bridge ~~listenes~~ on port 14014 in server mode without keepAlive.		If no parameter is used then the bridge listens on port 14014 in server mode without keepAlive.
	;<code>-help</code>		;<code>-help</code>
	* Shows the help		* Shows the help
Zeile 158:		Zeile 156:
	In Java, the message name is a single identifier, and arguments are written in an argument list after the message name: "receiver.fooBar(arg1, arg2)".		In Java, the message name is a single identifier, and arguments are written in an argument list after the message name: "receiver.fooBar(arg1, arg2)".

	When message names are translated, only the very first part of the Smalltalk keyword message is taken ("foo" in the above example), and the remaining parts are ~~simpl~~ ignored. Thus, any of the Smalltalk messages "foo:bar:", "foo:xxxx:" and "foo:_:" (a single underscore as second part) all translate to the same Java message name "foo()".		When message names are translated, only the very first part of the Smalltalk keyword message is taken ("foo" in the above example), and the remaining parts are simply ignored. Thus, any of the Smalltalk messages "foo:bar:", "foo:xxxx:" and "foo:_:" (a single underscore as second part) all translate to the same Java message name "foo()".

	Therefore, to call a method with more than one argument, like <CODE>"setSize(int width,int height)"</CODE> on a JFrame instance we can write:		Therefore, to call a method with more than one argument, like <CODE>"setSize(int width,int height)"</CODE> on a JFrame instance we can write:
Zeile 253:		Zeile 251:
	button addMouseListener:listener.		button addMouseListener:listener.
	</PRE></CODE>		</PRE></CODE>
	Now, with the press of the button in the Java GUI, the Smalltalk block will be executed and writes <CODE>"Hello from Java"</CODE> ~~tothe~~ Smalltalk console.		Now, with the press of the button in the Java GUI, the Smalltalk block will be executed and writes <CODE>"Hello from Java"</CODE> to the Smalltalk console.
	Of course, any other (Smalltalk-)action code can be made to run via this mechanism.		Of course, any other (Smalltalk-)action code can be made to run via this mechanism.

	But be aware, that the callback is possibly called later (when the elementary action, which installed the code, has already finished long ago). Also, as the Java code execution is not synchronized with any of your expecco action execution, the callback may also be called at any ~~arbutrary~~ time, even at times when no activity at all is executed on the expecco side. If you forget to cleanup, and the Java object is still alive, it may even be called after you have finished your test run (if you keep the java bridge handle around and alive, for example in an ~~expecoo~~ environment variable).		But be aware, that the callback is possibly called later (when the elementary action, which installed the code, has already finished long ago). Also, as the Java code execution is not synchronized with any of your expecco action execution, the callback may also be called at any arbitrary time, even at times when no activity at all is executed on the expecco side. If you forget to cleanup, and the Java object is still alive, it may even be called after you have finished your test run (if you keep the java bridge handle around and alive, for example in an expecco environment variable).

	So the Smalltalk callback code should not depend on any particular elementary action to be currently running, but instead in most cases write some information into a shared data container, preferably an instance of "SharedQueue", which is thread safe. Then, some other action (an elementary action) would read-wait and read events from that shared queue.		So the Smalltalk callback code should not depend on any particular elementary action to be currently running, but instead in most cases write some information into a shared data container, preferably an instance of "SharedQueue", which is thread safe. Then, some other action (an elementary action) would read-wait and read events from that shared queue.

	make sure that your test correctly cleans up any such callbacks afterwards. As a last resort, use the "Shutdown Bridge Connection" menu item, which closes the bridge connection, and thereby - as a side effect - removes any leftover callbacks. It does close the connection, and any ~~remaininf~~ java proxy object handles become invalid, though.		make sure that your test correctly cleans up any such callbacks afterwards. As a last resort, use the "Shutdown Bridge Connection" menu item, which closes the bridge connection, and thereby - as a side effect - removes any leftover callbacks. It does close the connection, and any remaining java proxy object handles become invalid, though.


Zeile 283:		Zeile 281:
	For this, it is possible to load a class at runtime into the JavaVM. The code of the class will first be sent to the JavaVM, which will compile and load the generated byte code. Then, the class can be accessed via the bridge just like any other preloaded class.		For this, it is possible to load a class at runtime into the JavaVM. The code of the class will first be sent to the JavaVM, which will compile and load the generated byte code. Then, the class can be accessed via the bridge just like any other preloaded class.

	The following example specifies the class code in a ~~smalltalk~~ string and inject the code into the JavaVM. Then an instance of that new class will be instantiated and finally a method of the object instance will be invoked:		The following example specifies the class code in a Smalltalk string and inject the code into the JavaVM. Then an instance of that new class will be instantiated and finally a method of the object instance will be invoked:
	<CODE><PRE>		<CODE><PRE>
	classCode := '		classCode := '
Zeile 380:		Zeile 378:

	=== Code Sources for Class injection ===		=== Code Sources for Class injection ===
	There are 3 possible types of class code sources which we can use to inject the code. In the examples before we directly used a simple <CODE>"String"</CODE> in the ~~smalltalk~~ code as a code source. We also can use a <CODE>"*.java"</CODE> file as source. Just read the content of the file into a string and use it as in the previous examples.		There are 3 possible types of class code sources which we can use to inject the code. In the examples before we directly used a simple <CODE>"String"</CODE> in the Smalltalk code as a code source. We also can use a <CODE>"*.java"</CODE> file as source. Just read the content of the file into a string and use it as in the previous examples.

	To inject a <CODE>"*.class"</CODE> file use the following code:		To inject a <CODE>"*.class"</CODE> file use the following code:
Zeile 390:		Zeile 388:
	== Examples ==		== Examples ==

	This example creates a JFrame with one button inside. Then a ~~Mouselistener~~ is created and registered on the button. When the button is pressed, the title of the window changes to <CODE>"onPressed"</CODE> and the Transcript shows the message <CODE>"onPressed"</CODE>. When the button is released, the title of the window is changed to <CODE>"onReleased"</CODE> and the Transcript shows <CODE>"onReleased"</CODE>. If the button lost the mouse focus, the bridge will exit (disconnect), and the Java side is terminated.		This example creates a JFrame with one button inside. Then a MouseListener is created and registered on the button. When the button is pressed, the title of the window changes to <CODE>"onPressed"</CODE> and the Transcript shows the message <CODE>"onPressed"</CODE>. When the button is released, the title of the window is changed to <CODE>"onReleased"</CODE> and the Transcript shows <CODE>"onReleased"</CODE>. If the button lost the mouse focus, the bridge will exit (disconnect), and the Java side is terminated.
	<CODE><PRE>		<CODE><PRE>
	\|java frame button listener\|		\|java frame button listener\|
Zeile 551:		Zeile 549:


	Now the same code but with a callback to ~~smalltalk~~ via an Java observer.		Now the same code but with a callback to Smalltalk via an Java observer.
	<CODE><PRE>		<CODE><PRE>
	\| java packageName className classCode observer \|		\| java packageName className classCode observer \|
Zeile 619:		Zeile 617:
	java myPackage_test_MyExampleClass main.		java myPackage_test_MyExampleClass main.

	"/creating a java observer proxy on in ~~smalltalk~~		"/creating a java observer proxy on in Smalltalk
	observer := java Observer new.		observer := java Observer new.

Zeile 629:		Zeile 627:
	].		].

	"/register the observer to the observable we want to be ~~notifyed~~ from		"/register the observer to the observable we want to be notified from
	MyExampleClass anInstanceOfMe addObserver:observer.		MyExampleClass anInstanceOfMe addObserver:observer.
	</PRE></CODE>		</PRE></CODE>
Zeile 656:		Zeile 654:

	=====newWaitingForConnectOnHost:aListeningAddressString port:aListeningPortNumber withTimeout:aTimeoutSeconds=====		=====newWaitingForConnectOnHost:aListeningAddressString port:aListeningPortNumber withTimeout:aTimeoutSeconds=====
	* This is used to wait for ~~incomming~~ ~~connecions~~ of a running JavaBridge on the network. The JavaBridge must be started in client mode on the remote host. After connecting a new connected instance of JAVA::Java is returned.		* This is used to wait for incoming connections of a running JavaBridge on the network. The JavaBridge must be started in client mode on the remote host. After connecting a new connected instance of JAVA::Java is returned.
	:: '''deprecated: aListeningAddressString''' - no longer used. Can be nil.		:: '''deprecated: aListeningAddressString''' - no longer used. Can be nil.
	:: '''aListeningPortNumber ''' - the port on which to listen for ~~incomming~~ connections as Number		:: '''aListeningPortNumber ''' - the port on which to listen for incoming connections as Number
	:: '''aTimeoutSeconds''' - a connect timeout in seconds as Number, If nil it will wait endless.		:: '''aTimeoutSeconds''' - a connect timeout in seconds as Number, If nil it will wait endless.

Zeile 669:		Zeile 667:
	====instance protocol====		====instance protocol====
	=====addJarByPath:aPath=====		=====addJarByPath:aPath=====
	* Adds a jar to the class path of the running JavaVM. If the jar depends on other jars or ~~librarys~~ you have to add them too.		* Adds a jar to the class path of the running JavaVM. If the jar depends on other jars or libraries you have to add them too.
	:: '''aPath''' - the path to the jar file as String.		:: '''aPath''' - the path to the jar file as String.

	=====addLibraryByPath:aPath=====		=====addLibraryByPath:aPath=====
	* Adds a library to the library path of the running JavaVM. If the library depends on other ~~librarys~~ you have to add them too.		* Adds a library to the library path of the running JavaVM. If the library depends on other libraries you have to add them too.
	:: '''aPath''' - the path to the library file as String.		:: '''aPath''' - the path to the library file as String.

Sv am 15. März 2017 um 12:09 Uhr

2017-03-15T12:09:33Z

← Nächstältere Version		Version vom 15. März 2017, 12:09 Uhr
Zeile 1:		Zeile 1:
			'''This Article describes the old, now obsolete Java Bridge V1. Here is the documentation of the new [[Java Interface Library v2 \| "Java Bridge V2"]]'''
	Documentation for expecco 2.1

	== Introduction ==		== Introduction ==

Mawalch: /* Java Package Import and Class Access */ Spelling fix.

2017-02-02T10:40:41Z

Java Package Import and Class Access: Spelling fix.

← Nächstältere Version		Version vom 2. Februar 2017, 10:40 Uhr
Zeile 124:		Zeile 124:
	== Java Package Import and Class Access==		== Java Package Import and Class Access==

	The import (loading) of additional required packages is done automatically in the JVM, when one of the package's classes is accessed for the very first time. In other words, when the Java code references a class for the first time, whose package is not yet loaded, it will search for the package along the class path and load it. Thus the above "addToClassPath:" actually does not yet verify or load the package, but only prepare any future "load on demand". This may be a bit dangerous, as failures may be reported much later, when a missing class is actually loaded (so better double check, that all the class ~~pathes~~ are valid, and the corresponding files are present on the system on which the JVM runs).		The import (loading) of additional required packages is done automatically in the JVM, when one of the package's classes is accessed for the very first time. In other words, when the Java code references a class for the first time, whose package is not yet loaded, it will search for the package along the class path and load it. Thus the above "addToClassPath:" actually does not yet verify or load the package, but only prepare any future "load on demand". This may be a bit dangerous, as failures may be reported much later, when a missing class is actually loaded (so better double check, that all the class paths are valid, and the corresponding files are present on the system on which the JVM runs).