# Variables

With variables you can customize many aspects of install4j. They can be used in all text fields and text properties in the install4j IDE as well as from the [install4j API](../api/installer.md). The general variable syntax is

```
${prefix:variableName}
```

where prefix denotes the variable type and is one of

- **compiler** — Compiler variables are replaced by the install4j compiler when the project is built.
- **installer** — Installer variables are evaluated when the installer or uninstaller is running.
- **launcher** — Launcher variables are evaluated when a generated application launcher is started.
- **i18n** — Custom localization keys are evaluated at runtime and depend on the chosen installer language.
- **(no prefix)** — Variables with no prefix resolve to runtime environment variables when used in the launcher configuration.

Text fields in the install4j IDE where you can use variables have a ![](../images/variable_chooser.svg) variable selector next to them. In the popup menu, you first choose a variable system from the available variable types. In text properties of an [installer element](../beans/screensAndActions.md) or a [form component](../beans/formComponents.md), you can use compiler variables, installer variables and custom localization keys, but not launcher variables.

![](../images/ui/variables_type_selection.png)

The variable selection dialog then shows all known variables of the selected variable type.

![](../images/ui/variables_selection.png)

For both compiler and installer variables install4j offers a fixed set of "system variables" that are prefixed with "sys.". These variables are not writable, and it is discouraged to use this prefix for your own variables.

<a id="compiler"></a>

### Compiler variables

Compiler variables are written as

```
${compiler:variableName}
```

The value of a compiler variable is a string that is known and replaced at compile time. The installer runtime or the generated launchers do not see this variable, but just the value that was substituted at runtime. Compiler variables are defined on the "General Settings->Compiler Variables" step.

![](../images/ui/variables_compiler_definition.png)

You can use compiler variables for various purposes. The most common usage of a compiler variable is the possibility to define a string in one place and use it in many other places. You can then change the string in one place instead of having to look up all of its usages.

An example of this use case is the pre-defined sys.version variable that contains the value of the text field where you enter the application version. Another usage for compiler variables is to override certain project settings on a per-media file basis. There are two ways to do that: Either, you specify a platform-specific value right below the compiler variable value, or you override the compiler variable value for specific media files.

For example, if you want to include one directory in the distribution tree for Windows but another one for macOS, you use a compiler variable for that directory and set the platform-specific value for macOS.

![](../images/ui/variables_platform_override.png)

The common base value can be referenced with the syntax ${compiler:variableName} and does not lead to a recursive replacement error when used in a compiler variable value override. This is useful if you want to augment the base value in a platform-specific way, for example, in a compiler variable for VM parameters where additional VM parameters are required depending on the platform.

Alternatively, you can override values for single media files. Media file-specific overrides have a higher precedence than platform-specific overrides. The common base value can be referenced in the same way as for platform-specific overrides.

![](../images/ui/variables_media_override.png)

To quickly override multiple variables for a single media file, you can configure overridden values on the "Customize project defaults->Compiler variables" step of the media wizard.

![](../images/ui/variables_override.png)

Finally, compiler variables can be overridden from the [command line compiler](../cli/compiler.md) as well as from the [Gradle](../cli/gradle.md), [Maven](../cli/maven.md) and [Ant](../cli/ant.md) plugins.

Compiler variables often refer to paths either on the build machine or on the target machine. install4j has no way of knowing whether the value is actually a path and where it is necessary, so it does not replace file or path separators by default. With the "Separators" drop-down right below the variable value, you can choose to replace file separators and path separators: You can either replace them for the build platform where the install4j compiler is running or for the target platform associated with the currently compiled media file. This can be much more readable that using the explicit compiler variables:

- ${compiler:sys.fileSeparator} for the file separator on the build platform
- ${compiler:sys.pathlistSeparator} for the path separator on the build platform
- ${compiler:sys.mediaFileSeparator} for the file separator on the target platform
- ${compiler:sys.mediaPathlistSeparator} for the path separator on the target platform

With the automatic separator conversion, you can use either Unix-style ('/' and ':') or Windows-style ('\\' and ';') file and path separators in the value. Both styles are converted in the same way. If you replace for the target platform and the variable is not used in a media file-specific context, no conversion will be performed.

When you use a compiler variable in your project that is not a system variable, it must be defined in on the "General Settings->Compiler Variables" step. If an unknown variable is encountered, the build will fail. You can use other variables in the value of a variable. Recursive definitions are detected and lead to a failure of the build. It is not possible to define compiler variables with the name of a system variable.

install4j provides a number of system compiler variables:

- **sys.date [Machine-specific variables]** — The current date in the format `YYYYMMDD` (e.g. "20250210"). The value is set at the start of a build and will not change during a single build.
- **sys.year [Machine-specific variables]** — The current year in format `YYYY`The value is set at the start of a build and will not change during a single build.
- **sys.time [Machine-specific variables]** — The current time in the format `HHMMSS` (e.g. "153012") where HH is the hour in 24-hour format, MM is the minute, and SS is the second. The value is set at the start of a build and will not change during a single build.
- **sys.timestamp [Machine-specific variables]** — The current time as the Unix epoch. This is a long value with the milliseconds since January 1st, 1970 (UTC). The value is set at the start of a build and will not change during a single build.
- **sys.install4jHome [Machine-specific variables]** — The installation directory of install4j that is used for compiling the media files.
- **sys.install4jVersion [Machine-specific variables]** — The version of install4j that is used for compiling the media files.
- **sys.tempDir [Machine-specific variables]** — The temporary directory of the build machine. This is `/tmp` on Linux, the `TMPDIR` directory on macOS and the `TEMP` directory on Windows. The value is set at the start of a build and will not change during a single build.
- **sys.fileSeparator [Machine-specific variables]** — The platform-dependent separator for directories in a file path. On Windows, this is a backslash ("\"), on Unix a forward slash ("/"). The value of this variable is intended to refer to files on the build machine. For a value that is valid at runtime, use `sys.mediaFileSeparator` instead.
- **sys.newLine** — A Unix newline character (`\n`).
- **sys.pathlistSeparator [Machine-specific variables]** — The platform-dependent separator for lists of directories. On Windows, this is a semicolon (";"), on Unix a colon (":"). The value of this variable is intended to refer to files on the build machine. For a value that is valid at runtime, use `sys.mediaPathlistSeparator` instead.
- **sys.version [Project-specific variables]** — The version of your application as configured under General Settings->Application Info.
- **sys.shortName [Project-specific variables]** — The short name of your application as configured under General Settings->Application Info.
- **sys.fullName [Project-specific variables]** — The full name of your application as configured under General Settings->Application Info.
- **sys.publisher [Project-specific variables]** — The publisher of your application as configured under General Settings->Application Info.
- **sys.publisherUrl [Project-specific variables]** — The publisher URL of your application as configured under General Settings->Application Info.
- **sys.languageId [Project-specific variables]** — The 2-letter ISO 639 code (see [https://www.loc.gov/standards/iso639-2/php/code_list.php](https://www.loc.gov/standards/iso639-2/php/code_list.php)) for the principal language of the installer. This variable can be overridden on the command line or the ant task, which is useful if you build different installers for different languages.
- **sys.javaMinVersion [Project-specific variables]** — The minimum Java version as configured under General Settings->Java Version
- **sys.javaMaxVersion [Project-specific variables]** — The maximum Java version as configured under General Settings->Java Version
- **sys.applicationId [Project-specific variables]** — The application ID as configured under Installer->Update Options
- **sys.updatesUrl [Project-specific variables]** — The URL where auto updaters can download the update descriptor file `updates.xml` as configured under Installer->Auto-Update Options. This variable is usually used in the "Update descriptor URL" property of a "Check for update" action.
- **sys.mediaFileName [Media-specific variables]** — The file name of the currently compiled media file as configured in the Media section and possibly overridden in "Customize project defaults->Media file name" step of the media wizard.
- **sys.mediaName [Media-specific variables]** — The display name in the install4j IDE of the currently compiled media file as configured in the Media section. If the default name of the media file is not suitable, you can rename the media file.
- **sys.mediaId [Media-specific variables]** — The ID of the currently compiled media file as configured in the Media section. This corresponds to the return value of `context.getMediaFileId()`.
- **sys.platform [Media-specific variables]** — The platform descriptor of the currently compiled media file. One of `windows-x64`, `windows-x32`, `windows-arm64`, `linux`, `unix` or `macos`. The value of this variable depends on your choice in the platform step of the media file wizard.
- **sys.withJre [Media-specific variables]** — A variable that contains "_with_jre" if a JRE is statically bundled with a media file and the empty string if not. This is useful if media files with and without JRE are built.
- **sys.jreBundleVersion [Media-specific variables]** — The Java version of the JRE bundle if a JRE bundle is configured for a media file and the empty string if not.
- **sys.jreBundleArch [Media-specific variables]** — The architecture of the JRE bundle if a JRE bundle is configured for a media file and the empty string if not.
- **sys.mediaFileSeparator [Media-specific variables]** — The platform-dependent separator for directories in a file path based on the current media set. For Windows media sets, this is a backslash ("\"), for all others a forward slash ("/").
- **sys.mediaPathlistSeparator [Media-specific variables]** — The platform-dependent separator for lists of directories based on the current media set. For Windows media sets, this is a semicolon (";"), for all others a colon (":").
- **sys.msiProductId [Media-specific variables]** — The product GUID if a Windows installer is wrapped in an MSI package, otherwise an empty string.

You can access environment variables on the build machine with the syntax

```
${compiler:env.environmentVariableName}
```

where "environmentVariableName" is the name of an environment variable. This is resolved at build time and only works if no compiler variable with the same name is defined on the "General Settings->Compiler Variables" step.

Compiler variable values in the IDE cannot be multi-line strings. If you need to insert a variable with a multi-line string, you can use the text file reference syntax

```
${compiler:file("path/to/file")}
```

where path/to/file is either an absolute file path or a path relative to the config file. All text areas that have an adjacent variable selector button offer the "Insert contents of text file" action in its popup menu. The file chooser has an option whether to use a relative or an absolute path in the variable expression.

In order to debug problems with compiler variables, you can switch on the extra verbose output flag in the [Build step](build.md). All variable replacements will then be printed to the build console.

The file path can be a variable expression itself, like in

```
${compiler:file(${compiler:myFile})}
```

so you can override it for each media file or pass it as a parameter to a command line build.

### Installer variables

Installer variables are written as

```
${installer:variableName}
```

The value of an installer variable is an arbitrary object that is not known at compile time. Installer variables are replaced at runtime in the installer, the uninstaller and in custom installer applications. They can optionally be predefined in the install4j IDE like compiler variables, but this is not required.

Undefined installer variables come into existence the first time they are defined at runtime. However, it is an error to use an undefined variable. For example, if you use an installer variable in an action, you have to make sure that the installer variable is defined before the action is executed.

Installer variables are used to wire together actions, screens and form components at runtime. The user input in screens is saved to variables that can be used in the properties of actions. Furthermore, installer variables can be used in condition and validation expressions. Some examples are given in the help topic on [form screens](formScreens.md). In script properties, you retrieve variables by invoking

```
context.getVariable("variableName")
```

Variable values can be set with the installer API by invoking

```
context.setVariable("variableName", variableValue)
```

You can analyze the bindings of an installer variable on the "Installer Variables" tab of an installer application configuration. That tab will show you a list of bound variables together with all bindings.

![](../images/ui/variables_binding_tree.png)

In order to document and categorize bound installer variables, you can pre-define them and set descriptions that will be displayed in the installer variable selector in the install4j IDE.

![](../images/ui/variables_predefined.png)

For pre-defined installer variables that take string values, the same file and path separator replacements as for compiler variables are available.

A common scenario is the need to calculate a variable value at runtime with some custom code and use the result as the initial value of a form component. To achieve this, you can add a "Set a variable" action to the startup screen and set its "Variable name" property to some variable name. In this context, install4j expects a variable name, and you must not use the ${installer:variableName} syntax but specify the plain variableName only. The return value of the "Script" property is written to the variable.

![](../images/ui/variables_set_variable_action.png)

For example, if this variable represents the initial directory that is displayed for a "Directory chooser" form component, you set the "Initial Directory" property of that form component to ${installer:variableName}. In this way you have wired the results of an action with a behavior of a screen.

Another important use of installer variables is in the names of [custom installation roots](files.md). In most cases, the name of a custom installation root contains an installer variable that is resolved at runtime. Often, one of the system installer variables that represent a "magic" folder can be used, such as ${installer:sys.system32Dir} for the Windows `system32` directory.

When you use installer variables in properties that display text, such as the screen title or the label properties of form components, a live binding will be created and the displayed text is updated automatically when the variable values change.

Installer variables can be passed to the installer, uninstaller or custom installer applications from the command line prefixed with -V:

```
-VmyVar=test "-VmyVarWithSpaces=this is a test"
```

Alternatively, you can specify a property file containing installer variables with -varfile my.properties, where the file `my.properties` contains one variable definition per line. The variables that are created will be instances of `java.lang.String`.

install4j provides a number of system installer variables:

- **sys.installationDir [Source and Target]** — The installation directory for the current installation. The value of this variable can change in the installer as the user selects an installation directory in the "Installation directory" screen or the installation directory is set via `context.setInstallationDirectory(File installationDirectory)`.Note that for single bundle archives on macOS, the installation directory usually is just `/Applications`, not a separate subdirectory.
- **sys.installForAllUsers [Source and Target]** — If the current installer should be installed for all users. By default, this variable is set to `true` only if the current process already has the rights to install for all users. That condition is available in the API from the Util.hasAllUserInstallationRights() method.The variable value can be changed programatically or with the "Set installation directory" action.When the initial installation directory for an installer results in an update installation or if the installation directory was specified on the command line with the `-dir` argument, the value of this variable is set to `true` if the directory is not writable by the current process.
- **sys.contentDir [Source and Target]** — The directory that holds the installed files. On Windows, Linux and Unix, this is the same as the installation directory. For single bundle archives on macOS, this is `[Bundle name].app/Contents/Resources/app/`. To reference an installed file in a cross-platform way, use this variable and not sys.installationDir.
- **sys.mediaFile [Source and Target]** — The path of your media file. Not available for uninstallers.On Unix and for non-MSI Windows installers this is the same as sys.installerFile. For MSI installers, this is the MSI file. On macOS, this is the path to the DMG file. If you want to reference the installer file, use sys.installerFile instead.
- **sys.mediaDir [Source and Target]** — The path of the directory where your installer file is located. Not available for uninstallers.On Unix and for non-MSI Windows installers this is the same as sys.installerDir. For MSI installers, this is the directory where the MSI file is located. On macOS, this is the directory where the DMG file is located. If you want to reference files inside the DMG file, use sys.installerDir instead.
- **sys.installerFile [Source and Target]** — The path of your installer file. Not available for uninstallers.On Unix and for non-MSI Windows installers this is the same as sys.mediaFile. For MSI installers, this is the extracted installer executable. On macOS, this is the path to the installer inside the mounted DMG. If you want to reference the DMG file, use sys.mediaFile instead.
- **sys.installerDir [Source and Target]** — The path of the directory where your installer file is located. Not available for uninstallers.On Unix and for non-MSI Windows installers this is the same as sys.mediaDir. For MSI installers, this is the directory the installer was extracted to. On macOS, this is the path into the mounted DMG. If you want to reference files in the same directory as the DMG file, use sys.mediaDir instead.
- **sys.resourceDir [Installer application state]** — The directory where the resource files are present that have been configured on the Installer->Custom Code & Resources tab.
- **sys.installationTypeId [Installer application state]** — The ID of the selected installation type. This is only relevant if the "Installation Type" screen has been added to the installer. The value is `null` as long as no installation type has been selected.
- **sys.version [Installer application state]** — For installers, the version of your application as configured under General Settings->Application Info. In that case, the variable yields the same value as the compiler variable of the same name. For custom installer applications, the installed version, which might not be the same as the version for which the custom installer application was originally compiled.
- **sys.logFile [Installer application state]** — The full path to the currently used log file. This is a path in the `TEMP` directory. For installers, this changes after the "Install Files" action, when the log file is moved to a path in the installation directory.
- **sys.responseFile [Installer application state]** — If a response file is supplied with a `-varfile` command line argument, the full path to the response file. If no response file is used, the variable value is `null`.
- **sys.preferredJre [Installer application state]** — The home directory of the JRE that will be used by the installed launchers. This variable will only be set after the "Install files" action has run. It will be the same as `System.getProperty("java.home")` or the `sys.javaHome` installer variable unless a bundled JRE has been installed. This variable is not available in the uninstaller or custom installer applications, use the `sys.javaHome` directory there.
- **sys.languageId [Installer application state]** — The 2-letter ISO 639 code (see [https://www.loc.gov/standards/iso639-2/php/code_list.php](https://www.loc.gov/standards/iso639-2/php/code_list.php)) for the actual language of the installer. For fixed-language installers, this is the same as the compiler variable of the same name. For multi-language installers, the value is determined at runtime.
- **sys.installerApplicationMode [Installer application state]** — A string that reports the type of the installer application: "installer" for the installer, "uninstaller" for the uninstaller and "custom" for custom installer applications.
- **sys.fileSeparator [Cross-platform variables]** — The platform-dependent separator for directories in a file path. On Windows, this is a backslash ("\"), on Unix a forward slash ("/").
- **sys.pathlistSeparator [Cross-platform variables]** — The platform-dependent separator for lists of directories. On Windows, this is a semicolon (";"), on Unix a colon (":").
- **sys.userHome [Cross-platform variables]** — The user home directory, typically something like `C:\Users\$USER` on Windows or `/home/$USER` on Unix platforms.
- **sys.userName [Cross-platform variables]** — The user account name.
- **sys.workingDir [Cross-platform variables]** — The working directory. For the installer, this is the temporary directory that the installer was extracted to.
- **sys.tempDir [Cross-platform variables]** — The temporary directory of the operating system. On all supported platforms, this is the value of the `TEMP` environment variable.
- **sys.javaHome [Cross-platform variables]** — The Java home directory of the currently used JRE.
- **sys.javaVersion [Cross-platform variables]** — The Java version of the currently used JRE.
- **sys.streamlinedInstallation [Cross-platform variables]** — If the user has confirmed to perform a streamlined installation. This variable is set by the "Streamlined installation chooser" form component, which is typically present on the "Welcome" screen. It asks the user whether to perform a streamlined installation or a customized installation. The result of that question is saved to this variable. If the form component is not shown, this variable is not set and `Context#getBooleanVariable(...)` returns false for this variable.
- **sys.desktopDir [Cross-platform variables]** — The directory used to physically store file objects on the desktop. On Windows, a typical path is `C:\Users\[user name]\Desktop`. On macOS, this is the `~/Desktop` directory and on Unix the freedesktop.org setting for the `XDG_DESKTOP_DIR` directory is returned.
- **sys.docsDir [Cross-platform variables]** — The directory used to physically store a user's common repository of documents. On Windows, a typical path is `C:\Users\[user name]\Documents`. On macOS, this is the `~/Documents` directory and on Unix the freedesktop.org setting for the `XDG_DOCUMENTS_DIR` directory is returned.
- **sys.downloadsDir [Cross-platform variables]** — The directory used to physically store a user's downloads. On Windows, a typical path is `C:\Users\[user name]\Downloads`. On macOS, this is the `~/Downloads` directory and on Unix the freedesktop.org setting for the `XDG_DOWNLOAD_DIR` directory is returned.
- **sys.appdataDir [Platform-specific variables]** — The directory that serves as a common repository for application-specific data. On Windows, a typical path is `C:\Users\[user name]\AppData\Roaming`. On macOS, this is the `~/Library/Application Support` directory. On Unix, the value of the `XDG_DATA_HOME` environment variable or if not defined `~/.local/share` is returned.
- **sys.localAppdataDir [Platform-specific variables]** — The user-specific directory that serves local applications to store computed data. On Windows, a typical path is `C:\Users\[user name]\AppData\Local`. On macOS, this is the `~/Library/Caches` directory. On Unix, the value of the `XDG_CACHE_HOME` environment variable or if not defined `~/.cache` is returned.
- **sys.windowsDir [Platform-specific variables]** — The Windows installation directory, typically `C:\Windows`.
- **sys.system32Dir [Platform-specific variables]** — The system32 directory of your Windows installation, typically `C:\Windows\system32`.
- **sys.commonDir [Platform-specific variables]** — The common files directory of your Windows installation, typically `C:\Program Files\Common Files`.
- **sys.programDataDir [Platform-specific variables]** — The directory where applications can save data that is not specific to particular users. A typical path is `C:\ProgramData`.
- **sys.startMenuDir [Platform-specific variables]** — The directory containing Start menu items. A typical path is `C:\Users\[user name]\AppData\Roaming\Microsoft\Windows\Start Menu`.
- **sys.programsDir [Platform-specific variables]** — The directory that contains the user's start menu entries. A typical path is `C:\Users\[user name]\AppData\Roaming\Microsoft\Windows\Start Menu\Programs`.
- **sys.startupDir [Platform-specific variables]** — The directory that corresponds to the user's Startup start menu folder. The system starts these programs whenever any user logs onto Windows. A typical path is `C:\Users\[user name]\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup`.
- **sys.sendToDir [Platform-specific variables]** — The directory that contains Send To menu items. A typical path is `C:\Users\[user name]\AppData\Roaming\Microsoft\Windows\SendTo`.
- **sys.templatesDir [Platform-specific variables]** — The directory that serves as a common repository for document templates. A typical path is `C:\Users\[user name]\AppData\Roaming\Microsoft\Windows\Templates`.
- **sys.favoritesDir [Platform-specific variables]** — The directory that serves as a common repository for the user's favorite items. A typical path is `C:\Users\[user name]\Favorites`.
- **sys.fontsDir [Platform-specific variables]** — The folder that contains fonts. A typical path is `C:\Windows\Fonts`. On macOS, the value is `/Library/Fonts`.
- **sys.programFilesDir [Platform-specific variables]** — The directory where programs are installed, typically something like `C:\Program Files`. On macOS, the value is `/Applications`.
- **sys.date [Cross-platform variables]** — The current date in the format `YYYYMMDD` (e.g. "20250210"). The value is set when the installer is started and will not change for the current process.
- **sys.year [Cross-platform variables]** — The current year in format `YYYY`The value is set when the installer is started and will not change for the current process.
- **sys.time [Cross-platform variables]** — The current time in the format `HHMMSS` (e.g. "153012") where HH is the hour in 24-hour format, MM is the minute, and SS is the second. The value is set when the installer is started and will not change for the current process.
- **sys.timestamp [Cross-platform variables]** — The current time as the Unix epoch. This is a long value with the milliseconds since January 1st, 1970 (UTC). The value is set when the installer is started and will not change for the current process.

<a id="launcher"></a>

### Launcher variables

Launcher variables are written as

```
${launcher:variableName}
```

The value of a launcher variable is a string that is not known at compile time. In contrast to installer variables, they are replaced by the launcher and not by Java code, so the replaced value is seen by the JVM at startup. Launcher variables can only be used in the "VM parameters" and "Arguments" text fields on the "Java invocation" step of the [launcher wizard](launchers.md).

No user-defined launcher variables exist, the available system launcher variables are:

- **sys.launcherDirectory** — The directory in which your launcher has been installed at runtime.
- **sys.jvmHome** — The home directory of the JVM that your launcher is running with. This is useful to put JAR files from the JRE into your boot classpath. The "home directory" is the directory that contains the "bin" directory of the JRE.
- **sys.tempDir** — The temporary directory for the current user.
- **sys.userHome** — The home directory of the current user.

### I18N messages

I18N messages are written as

```
${i18n:keyName}
```

The value of an I18N message depends on the language that is selected for the installer. You can use this facility to localize messages in your installers if they support [multiple languages](localization.md). To do that, you supply key-value pairs in the custom localization file. The variable selection dialog for I18N messages shows all system messages as well as all messages in the custom localization file for the principal language of your project.

![](../images/ui/variables_i18n_selection.png)

All standard messages displayed by install4j can be referenced with this syntax as well. You can locate the key name in one of the `message_*.utf8` files in the `$INSTALL4J_HOME/resource/messages` directory and use it anywhere in your project. The standard messages can be overwritten by your custom localization files.

### Default values for missing variables

For the text field syntax of installer and compiler variables there is a mechanism to supply a default value in case the variable is not defined: After the variable name you add the delimiter ?: and insert the default value before the closing curly bracket.

For example:

```
${installer:myVariable?:defaultValue}
```

will resolve to defaultValue if the installer variable "myVariable" is not defined. The default value can be another variable, also of a different type. For example:

```
${installer:updatesUrl?:${compiler:sys.updatesUrl}}
```

If the installer variable "updatesUrl" is not defined, the compiler variable "sys.updatesUrl" is inserted. This is the default value for the "Update descriptor URL" property of the "Check for update" action.

The chain of default values can be arbitrarily long:

```
${installer:one?:${installer:two?:${installer:three?:${installer:four?:some plain text}}}}
```

This will resolve to the first defined installer variable out of "one", "two", "three", "four" or to some plain text if none of them are defined.

### Binding variables to non-text properties

Many bean properties do not take text input, for example, boolean, integer or enum properties, so that the variable syntax ${installer:myVariable} for text fields is not applicable. For these properties, you can select "Switch to text mode" in the context menu and enter a variable expression that resolves to the required type. Conversions from string values are important because compiler variables can only hold string values, unlike installer variables that can hold arbitrary types.

![](../images/ui/variables_text_override_action.png)

The help icon in the property editor tells you what the property type is and also informs about the supported conversions from other primitive types or strings. For example, "true" or "false" string values are supported for boolean properties as well, which is what you would use with a compiler variable. For enum properties, the name of the enum or the ordinal as a number or as a string will be resolved to the actual enum value. Also, numeric values will be parsed from strings.

![](../images/ui/variables_text_override_editor.png)

If you develop a custom bean and want to support that functionality as well, you have to enable it in the property descriptor and insert a call into the property getter as explained in the [Javadoc for AbstractBean](../../reference/api/beans/AbstractBean.md).

### Using variables in your own applications

Frequently there is a need in the installed applications to access user input that was made in the installer. The [launcher API](../api/launcher.md) provides the helper class `com.install4j.api.launcher.Variables` to access the values of installer variables.

There are two ways that installer variables can be persisted in the installer: First, installer variables are saved to the default [response file](../installers/responseFile.md) `.install4j/response.varfile` that is created when the installer exits, or if a "Create response file" action is executed. Only response file variables are saved to that file. Secondly, selected installer variables can be saved to the Java preference store. `com.install4j.api.launcher.Variables` offers methods to load variables from both sources.

Saving to the Java preference store is interesting if you want to modify those variable values in your applications and save back the modified values. The Java preference store is available on a per-user basis so that it is possible to modify settings even if the user does not have write permissions for the installation directory. `com.install4j.api.launcher.Variables` has methods for loading and saving the entire map of installer variables that was saved in the installer. Also, it is possible to specify an arbitrary package to which the installer variables are saved, so that settings can be shared between different installers.

![](../images/ui/variables_save_to_preference_store.png)

Finally, it is useful to access compiler variables in your own applications. For example, the version number configured in the install4j IDE can be accessed in your own application through `com.install4j.api.launcher.Variables`.
