Settings JavaBridgeSettings/en - Versionsgeschichte

Cg: /* Specifying a different JVM Installation */

2022-11-02T16:01:53Z

Specifying a different JVM Installation

← Nächstältere Version		Version vom 2. November 2022, 16:01 Uhr
Zeile 28:		Zeile 28:
	JBridge.Java.setJavaPath("...path to your JRE or JDK...");		JBridge.Java.setJavaPath("...path to your JRE or JDK...");

	Notice that you'll have to duplicate "\"-characters inside a string constant in JavaScript, but not in Smalltalk. An even better implementation would have an input pin, and the path be passed in as action parameter.		Notice that you'll have to duplicate "<CODE>\</CODE>"-characters inside a string constant in JavaScript, but not in Smalltalk. An even better implementation would have an input pin, and the path be passed in as action parameter.

	The path given should be to the JRE/JDK folder, where "bin" and "lib" subfolders are present. Especially, "bin/java" or "bin\java.exe" should be present there.		The path given should be to the JRE/JDK folder, where "<CODE>bin</CODE>" and "<CODE>lib</CODE>" subfolders are present. Especially, "<CODE>bin/java</CODE>" or "<CODE>bin\java.exe</CODE>" should be present there.

	(a corresponding action is included in the newest version of the standard library as "Java [ Set Java Installation Path ]")		(a corresponding action is included in the newest version of the standard library as "<CODE>Java [ Set Java Installation Path ]</CODE>")

	=== Path to the Java Installation ===		=== Path to the Java Installation ===

Cg: /* Specifying a different JVM Installation */

2022-11-02T16:00:43Z

Specifying a different JVM Installation

← Nächstältere Version		Version vom 2. November 2022, 16:00 Uhr
Zeile 32:		Zeile 32:
	The path given should be to the JRE/JDK folder, where "bin" and "lib" subfolders are present. Especially, "bin/java" or "bin\java.exe" should be present there.		The path given should be to the JRE/JDK folder, where "bin" and "lib" subfolders are present. Especially, "bin/java" or "bin\java.exe" should be present there.

	(~~this~~ action ~~will be~~ included in ~~future~~ ~~versions~~ of the standard library)		(a corresponding action is included in the newest version of the standard library as "Java [ Set Java Installation Path ]")

	=== Path to the Java Installation ===		=== Path to the Java Installation ===

Cg: /* Specifying a different JVM Installation */

2022-11-02T15:47:50Z

Specifying a different JVM Installation

← Nächstältere Version		Version vom 2. November 2022, 15:47 Uhr
Zeile 28:		Zeile 28:
	JBridge.Java.setJavaPath("...path to your JRE or JDK...");		JBridge.Java.setJavaPath("...path to your JRE or JDK...");

	Notice that you'll have to duplicate "\"-characters inside a string constant in JavaScript, but not in Smalltalk.		Notice that you'll have to duplicate "\"-characters inside a string constant in JavaScript, but not in Smalltalk. An even better implementation would have an input pin, and the path be passed in as action parameter.

	The path given should be to the JRE/JDK folder, where "bin" and "lib" subfolders are present. Especially, "bin/java" or "bin\java.exe" should be present there.		The path given should be to the JRE/JDK folder, where "bin" and "lib" subfolders are present. Especially, "bin/java" or "bin\java.exe" should be present there.

Cg: /* Specifying a different JVM Installation */

2022-11-02T15:46:44Z

Specifying a different JVM Installation

← Nächstältere Version		Version vom 2. November 2022, 15:46 Uhr
Zeile 18:		Zeile 18:
	JVM versions. For this, you can use two mechanisms:		JVM versions. For this, you can use two mechanisms:
	* either save and keep multiple settings files, each with different JVM settings, and run expecco with a corresponding "--settings" comamnd line argument.		* either save and keep multiple settings files, each with different JVM settings, and run expecco with a corresponding "--settings" comamnd line argument.
	* create a little elementary action which shuts down all runing Java Bridges and changes the default path for future new bridges and execute this action before each test run. The action's code should be:		* create a little elementary action which shuts down all runing Java Bridges and changes the default path for future new bridges and execute this action before each test run. The action's Smalltalk code should be:
	execute		execute
	JBridge::Java exitAllInstances.		JBridge::Java exitAllInstances.
	JBridge::Java setJavaPath:'...path to your JRE or JDK...'.		JBridge::Java setJavaPath:'...path to your JRE or JDK...'.

			or as JavaScript action:
			execute() {
			JBridge.Java.exitAllInstances();
			JBridge.Java.setJavaPath("...path to your JRE or JDK...");

			Notice that you'll have to duplicate "\"-characters inside a string constant in JavaScript, but not in Smalltalk.

	The path given should be to the JRE/JDK folder, where "bin" and "lib" subfolders are present. Especially, "bin/java" or "bin\java.exe" should be present there.		The path given should be to the JRE/JDK folder, where "bin" and "lib" subfolders are present. Especially, "bin/java" or "bin\java.exe" should be present there.

Cg: /* Specifying a differewnt JVM Installation */

2022-11-02T15:44:24Z

Specifying a differewnt JVM Installation

← Nächstältere Version		Version vom 2. November 2022, 15:44 Uhr
Zeile 14:		Zeile 14:
	However, we recommend using a definite JVM version for real test runs, to ensure consistent behavior.		However, we recommend using a definite JVM version for real test runs, to ensure consistent behavior.

	==== Specifying a ~~differewnt~~ JVM Installation ====		==== Specifying a different JVM Installation ====
	If you are to test deployability of your Java application, it may be a good idea to test against multiple		If you are to test deployability of your Java application, it may be a good idea to test against multiple
	JVM versions. For this, you can use two mechanisms:		JVM versions. For this, you can use two mechanisms:

Cg: /* Use System's Default JVM */

2022-11-02T15:44:09Z

Use System's Default JVM

← Nächstältere Version		Version vom 2. November 2022, 15:44 Uhr
Zeile 13:		Zeile 13:

	However, we recommend using a definite JVM version for real test runs, to ensure consistent behavior.		However, we recommend using a definite JVM version for real test runs, to ensure consistent behavior.

⚫	If you are to test deployability of your Java application, it may ~~even~~ be a good idea to test against multiple
			==== Specifying a differewnt JVM Installation ====
		⚫	If you are to test deployability of your Java application, it may be a good idea to test against multiple
	JVM versions. For this, you can use two mechanisms:		JVM versions. For this, you can use two mechanisms:
	* either save and keep multiple settings files, each with different JVM settings, and run expecco with a corresponding "--settings" comamnd line argument.		* either save and keep multiple settings files, each with different JVM settings, and run expecco with a corresponding "--settings" comamnd line argument.

Cg: /* Use System's Default JVM */

2022-11-02T15:42:23Z

Use System's Default JVM

← Nächstältere Version		Version vom 2. November 2022, 15:42 Uhr
Zeile 12:		Zeile 12:
	If on, the system's default JVM is used and the JVM path below is ignored. That means, that the Java VM is used which is found via the plain "<CODE>java</CODE>" command. This may make your test runs somewhat unreproducible, because JVMs may differ in their behavior, depending on the Java version. However, it may be useful to test default setups or to allow for a quick start, in case you do not know which JVM to use, or you do not know the installation path.		If on, the system's default JVM is used and the JVM path below is ignored. That means, that the Java VM is used which is found via the plain "<CODE>java</CODE>" command. This may make your test runs somewhat unreproducible, because JVMs may differ in their behavior, depending on the Java version. However, it may be useful to test default setups or to allow for a quick start, in case you do not know which JVM to use, or you do not know the installation path.

	However, we recommend using a definite JVM version for real test runs, to ensure ~~reproducible~~ behavior.		However, we recommend using a definite JVM version for real test runs, to ensure consistent behavior.
			If you are to test deployability of your Java application, it may even be a good idea to test against multiple
			JVM versions. For this, you can use two mechanisms:
			* either save and keep multiple settings files, each with different JVM settings, and run expecco with a corresponding "--settings" comamnd line argument.
			* create a little elementary action which shuts down all runing Java Bridges and changes the default path for future new bridges and execute this action before each test run. The action's code should be:
			execute
			JBridge::Java exitAllInstances.
			JBridge::Java setJavaPath:'...path to your JRE or JDK...'.

			The path given should be to the JRE/JDK folder, where "bin" and "lib" subfolders are present. Especially, "bin/java" or "bin\java.exe" should be present there.

			(this action will be included in future versions of the standard library)

	=== Path to the Java Installation ===		=== Path to the Java Installation ===

Cg: /* Use System's Default JVM */

2022-11-02T15:33:28Z

Use System's Default JVM

← Nächstältere Version		Version vom 2. November 2022, 15:33 Uhr
Zeile 10:		Zeile 10:
	=== Use System's Default JVM ===		=== Use System's Default JVM ===

	If on, the system's default JVM is used and the JVM path below is ignored. That means, that the Java VM which is found via the plain "java" command ~~is used~~. This may make your test runs somewhat unreproducible, because JVMs may differ in their behavior, depending on the Java version. However, it may be useful to test default setups or to allow for a quick start, in case you do not know which JVM to use, or you do not know the installation path.		If on, the system's default JVM is used and the JVM path below is ignored. That means, that the Java VM is used which is found via the plain "<CODE>java</CODE>" command. This may make your test runs somewhat unreproducible, because JVMs may differ in their behavior, depending on the Java version. However, it may be useful to test default setups or to allow for a quick start, in case you do not know which JVM to use, or you do not know the installation path.

	However, we recommend using a definite JVM version for real test runs, to ensure reproducible behavior.		However, we recommend using a definite JVM version for real test runs, to ensure reproducible behavior.

Chzeiher am 11. Dezember 2018 um 10:52 Uhr

2018-12-11T10:52:32Z

← Nächstältere Version		Version vom 11. Dezember 2018, 10:52 Uhr
Zeile 29:		Zeile 29:

	This checkbox is only shown if the Java Debugging Plugin is loaded, licensed and enabled.		This checkbox is only shown if the Java Debugging Plugin is loaded, licensed and enabled.
			Please be aware that JDI Debugging is an experimental feature that eXept is not supporting as of yet.

	Expecco can make use of the JDI (Java Debugging Interface) to interact with the Java VM for debugging purposes. This is especially useful to set/clear breakpoints, to single step in the tested Java application and to get more detailed information about the call stack in the debugger. However, it may affect the tested Java application's behavior, especially timing. Also, it may require appropriate security rights for the debug connection to be made.		Expecco can make use of the JDI (Java Debugging Interface) to interact with the Java VM for debugging purposes. This is especially useful to set/clear breakpoints, to single step in the tested Java application and to get more detailed information about the call stack in the debugger. However, it may affect the tested Java application's behavior, especially timing. Also, it may require appropriate security rights for the debug connection to be made.

Mawalch: Unify spelling of "Java Bridge", "Java VM" etc.

2017-06-03T19:12:51Z

Unify spelling of "Java Bridge", "Java VM" etc.

← Nächstältere Version		Version vom 3. Juni 2017, 19:12 Uhr
Zeile 2:		Zeile 2:


	=== Show ~~JavaBridge~~ Menu in Main Menu ===		=== Show Java Bridge Menu in Main Menu ===

	If off, menu items for ~~java~~ ~~bridge~~ functions are only shown in the corresponding plugins submenu.		If off, menu items for Java Bridge functions are only shown in the corresponding plugins submenu.
	If on, an extra submenu is shown in the top menu area.		If on, an extra submenu is shown in the top menu area.
	Disable this, if you are not (heavily) using the Java Bridge functionality, and you want to keep the menu more compact.		Disable this, if you are not (heavily) using the Java Bridge functionality, and you want to keep the menu more compact.
Zeile 16:		Zeile 16:
	=== Path to the Java Installation ===		=== Path to the Java Installation ===

	Defines the path to the ~~JavaVM~~ and Java libraries ~~which~~ are to be used.		Defines the path to the Java VM and Java libraries that are to be used.
	The system tries to find out itself about which Java frameworks have been installed on the system and offers those paths in the combo list. However, if you have installed Java at a non standard or private place, either enter the path or select it using a browser dialog (click on the "..." button).		The system tries to find out itself about which Java frameworks have been installed on the system and offers those paths in the combo list. However, if you have installed Java at a non standard or private place, either enter the path or select it using a browser dialog (click on the "..." button).

	Because Java VMs may differ in their behavior and set of supported features, we recommend that you use an explicit path for reproducible test results. It may even be advisable, to use multiple tests/suites/runs ~~which~~ test the behavior against multiple commonly used Java installations.		Because Java VMs may differ in their behavior and set of supported features, we recommend that you use an explicit path for reproducible test results. It may even be advisable, to use multiple tests/suites/runs that test the behavior against multiple commonly used Java installations.

	=== Use the Builtin ~~JavaVM~~ for local Groovy Actions ===		=== Use the Builtin Java VM for local Groovy Actions ===

	This is an experimental feature, which should (currently) only be enabled by expecco developers (i.e. eXept staff).		This is an experimental feature, which should (currently) only be enabled by expecco developers (i.e. eXept staff).
	When enabled, the ST/X-libjava builtin JVM is used. This VM is tightly integrated into the ST(X system itself and does not use an external (~~oracle~~-) JVM. This VM allows for much improved hot-pluggable code changes in the browser and debugger and offers a Smalltalk-like user experience to programmers. It does not support all of the newest Java features, and may therefore be not able to execute all Java programs. Please do not enable this feature in the current (2.8) version.		When enabled, the ST/X-libjava builtin JVM is used. This VM is tightly integrated into the ST/X system itself and does not use an external (Oracle-) JVM. This VM allows for much improved hot-pluggable code changes in the browser and debugger and offers a Smalltalk-like user experience to programmers. It does not support all of the newest Java features, and may therefore be not able to execute all Java programs. Please do not enable this feature in the current (2.8) version.

	=== JDI Debugging enabled ===		=== JDI Debugging enabled ===
Zeile 30:		Zeile 30:
	This checkbox is only shown if the Java Debugging Plugin is loaded, licensed and enabled.		This checkbox is only shown if the Java Debugging Plugin is loaded, licensed and enabled.

	Expecco can make use of the JDI (Java Debugging Interface) to interact with the Java VM for debugging purposes. This is especially useful to set/clear breakpoints, to single step in the tested Java application and to get more detailed information about the call stack in the debugger. However, it may affect the tested Java application's behavior, especially timing. Also, it may require appropriate security rights for the debug connection to be made.		Expecco can make use of the JDI (Java Debugging Interface) to interact with the Java VM for debugging purposes. This is especially useful to set/clear breakpoints, to single step in the tested Java application and to get more detailed information about the call stack in the debugger. However, it may affect the tested Java application's behavior, especially timing. Also, it may require appropriate security rights for the debug connection to be made.

	If you encounter problems with the JDI interface, you may want to disable this feature.		If you encounter problems with the JDI interface, you may want to disable this feature.

	Be aware that line breakpoints, single stepping in a Java application and some other features will be disabled in the debugger then. You can still place coded breakpoints (i.e. "halt();") and print statements into ~~groovy~~ blocks for debugging.		Be aware that line breakpoints, single stepping in a Java application and some other features will be disabled in the debugger then. You can still place coded breakpoints (i.e. "halt();") and print statements into Groovy blocks for debugging.

	=== Confirm Close of Bridge Connections ===		=== Confirm Close of Bridge Connections ===