Settings JavaBridgeSettings - Versionsgeschichte

Sv: Weiterleitung nach Settings JavaBridgeSettings/en erstellt

2015-12-08T17:26:59Z

Weiterleitung nach Settings JavaBridgeSettings/en erstellt

← Nächstältere Version		Version vom 8. Dezember 2015, 17:26 Uhr
Zeile 1:		Zeile 1:
			#redirect [[ Settings JavaBridgeSettings/en ]]
	== Java Bridge Settings ==
		⚫	[[Category: Incomplete]]

			[[Category: Empty]]

	=== Show JavaBridge Menu in Main Menu ===

	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.
	Disable this, if you are not (heavily) using the Java Bridge functionality, and you want to keep the menu more compact.

	=== 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 unreproducable, 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 don't know which JVM to use, or you don't know the installation path.

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

	=== Path to the Java Installation ===

	Defines the path to the JavaVM and Java libraries which are to be used.
	The system tries to find out itself about which Java frameworks have been installed on the system and offers those pathes 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 reproducable test results. It may even be advisable, to use multiple tests/suites/runs which test the behavior against multiple commonly used Java installations.

	=== Use the Builtin JavaVM for local Groovy Actions ===

	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 intergrated 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 ===

	This checkbox is only shown if the Java Debugging Plugin is loaded, licenced 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.

	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.

	=== Confirm Close of Bridge Connections ===

	Especially during debugging, you may very often use the "Shutdown Bridge Connections" menu item from the main menu. By default, this operations must be confirmed by a dialog window, which may be annoying.
	This checkbox allows for the confirmation dialog to be suppressed.


⚫	[[Category:~~Settings~~]]

Cg: /* Path to the Java Installation */

2015-09-30T11:39:57Z

Path to the Java Installation

← Nächstältere Version		Version vom 30. September 2015, 11:39 Uhr
Zeile 20:		Zeile 20:

	Because Java VMs may differ in their behavior and set of supported features, we recommend that you use an explicit path for reproducable 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 reproducable test results. It may even be advisable, to use multiple tests/suites/runs which test the behavior against multiple commonly used Java installations.

			=== Use the Builtin JavaVM for local Groovy Actions ===

			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 intergrated 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 ===

Cg: /* JDI Debugging enabled */

2015-09-30T11:36:26Z

JDI Debugging enabled

← Nächstältere Version		Version vom 30. September 2015, 11:36 Uhr
Zeile 22:		Zeile 22:

	=== JDI Debugging enabled ===		=== JDI Debugging enabled ===

			This checkbox is only shown if the Java Debugging Plugin is loaded, licenced 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.

Cg: /* Confirm Close of Bridge Connections */

2015-09-30T11:35:20Z

Confirm Close of Bridge Connections

← Nächstältere Version		Version vom 30. September 2015, 11:35 Uhr
Zeile 31:		Zeile 31:
	=== Confirm Close of Bridge Connections ===		=== Confirm Close of Bridge Connections ===

	Especially during debugging, you may very often ~~sue~~ the "Shutdown Bridge Connections" menu item from the main menu. By default, this operations must be confirmed by a dialog window, which may be annoying.		Especially during debugging, you may very often use the "Shutdown Bridge Connections" menu item from the main menu. By default, this operations must be confirmed by a dialog window, which may be annoying.
	This checkbox allows for the confirmation dialog to be ~~skipped~~.		This checkbox allows for the confirmation dialog to be suppressed.

Cg: /* JDI Debugging enabled */

2015-09-30T11:34:48Z

JDI Debugging enabled

← Nächstältere Version		Version vom 30. September 2015, 11:34 Uhr
Zeile 23:		Zeile 23:
	=== JDI Debugging enabled ===		=== JDI Debugging 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. ~~If you encounter problems with the JDI interface, you may want to disable this feature.~~		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.

⚫	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.
			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.

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

Cg: /* Path to the Java Installation */

2015-09-30T11:33:47Z

Path to the Java Installation

← Nächstältere Version		Version vom 30. September 2015, 11:33 Uhr
Zeile 19:		Zeile 19:
	The system tries to find out itself about which Java frameworks have been installed on the system and offers those pathes 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 pathes 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 reproducable test results.		Because Java VMs may differ in their behavior and set of supported features, we recommend that you use an explicit path for reproducable test results. It may even be advisable, to use multiple tests/suites/runs which test the behavior against multiple commonly used Java installations.

	=== JDI Debugging enabled ===		=== JDI Debugging enabled ===

Cg: /* Path to the Java Installation */

2015-09-30T11:32:47Z

Path to the Java Installation

← Nächstältere Version		Version vom 30. September 2015, 11:32 Uhr
Zeile 18:		Zeile 18:
	Defines the path to the JavaVM and Java libraries which are to be used.		Defines the path to the JavaVM and Java libraries which are to be used.
	The system tries to find out itself about which Java frameworks have been installed on the system and offers those pathes 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 pathes 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 reproducable test results.

	=== JDI Debugging enabled ===		=== JDI Debugging enabled ===

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

2015-09-30T11:31:36Z

Use System's Default JVM

← Nächstältere Version		Version vom 30. September 2015, 11:31 Uhr
Zeile 10:		Zeile 10:
	=== Use System's Default JVM ===		=== Use System's Default JVM ===

	If on, the system's default jvm is used. That means, that the java VM which is found via the plain "java" command is used. This may make your test runs somewhat unreproducable, 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 don't know which JVM to use, or you don't 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 which is found via the plain "java" command is used. This may make your test runs somewhat unreproducable, 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 don't know which JVM to use, or you don't know the installation path.

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

Cg: /* Show JavaBridge Menu in Main Menu */

2015-09-30T11:31:08Z

Show JavaBridge Menu in Main Menu

← Nächstältere Version		Version vom 30. September 2015, 11:31 Uhr
Zeile 7:		Zeile 7:
	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.

			=== Use System's Default JVM ===

			If on, the system's default jvm is used. That means, that the java VM which is found via the plain "java" command is used. This may make your test runs somewhat unreproducable, 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 don't know which JVM to use, or you don't know the installation path.

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

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

Cg: /* JDI Debugging enabled */

2015-09-30T11:27:09Z

JDI Debugging enabled

← Nächstältere Version		Version vom 30. September 2015, 11:27 Uhr
Zeile 17:		Zeile 17:
	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.		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.
	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 ===