Questions? Don’t hesitate to ask. We love to help!

Lets you control miscellaneous options that doesn’t fit elsewhere.

Force formatting

Jalopy can keep track of which files have been formatted previously (Refer to Section 2.2.2.1, “History” for more information about this feature). If the history is enabled, Jalopy won’t format files that have not changed since the last formatting. However, you can disable this check to force a reformat. For example, you might need to update the copyright notice for the whole code base. Enabling this switch ensures that all source files are always formatted.

Test formatting

When enabled, formatting output is not written to disk and/or opened editors are not updated. This may be worthwhile when you want to determine what files cause warnings or errors during formatting. This way Jalopy can be used somewhat similar to a coding style checker (see Section 2.8.19, “Code Inspector” for the available style checks). This option is mostly useful for batch mode processing, therefore it can be enabled from the Console, Ant or Maven plug-ins directly, and should be normally left disabled here. Refer to Section 2.6.2, “Logging” for more information about the possible logging options.

Since 1.0

Insert trailing newline

When enabled, Jalopy inserts an empty line at the end of every file. This may help to avoid problems with certain text formatters and processors. Note that Jalopy always inserts at least one empty line after footers, so there is no real need (but it doesn’t hurt) to check the mark in case footers are used. See Section 2.8.16, “Footer” for more information on footers.

package foo;¶
¶
class Foo {¶
}¶

package foo;¶
¶
class Foo {¶
}¶
¶

Checkout read-only files

When enabled, Jalopy tries to checkout read-only files when it detects that a file is under source control. Such behavior should be the default with most SCM providers anyway, but if you happen to use a SCM system that does not work this way, this option might come to the rescue. Please note that this feature is currently only available with the Eclipse and IntelliJ IDEA plug-ins.

Since 1.9.2

Keep editor state

When enabled, Jalopy will keep the current editor state when formatting editor contents. If an editor is currently dirty, i.e. contains unsaved changes, Jalopy will only update the editor. Otherwise the file is changed on disk as well. Please note that depending on your IDE an undo might not be possible when this option has been enabled.

Since 1.9

Use current file in preview

When enabled, Jalopy will use the source file that is currently opened in the editor as the preview file for the configuration dialog. Otherwise custom code snippets are used instead. The preview uses the actual editor file, not the current editor contents. One therefore needs to persist any changes before they show up in the preview. Please note that you need to close and re-open the configuration dialog before an option change will take effect.

Since 1.9

In order to efficiently use formatting of projects with several developers, it is important to be able to only format files which have changed. Jalopy provides a simple way to accomplish this by calculating checksums. This stops formatting files that have just been updated from source control from having being formatted (and time stamps updated) and thus prevents checking-in files that actually weren’t touched by the developer later on.

To enable the history feature, select your preferred checksum method from the combo box on the left. Adler32 is faster, CRC32 is slightly more accurate. The history information of previous formatting runs will be saved in a file “history.dat”. Since Jalopy 1.0.3, you can specify the directory where the file is actually stored. The default is to store the history file in the current profile directory. The history file will grow over time, especially if one manages several big projects which share the same profile. As all history entries are read into memory at startup, it could eat up quite a bit of resources. Therefore a simple history viewer is provided which enables you to selectively remove obsolete entries if need be.

View

You can use the View button to display the history viewer. Entries can be selectively removed via the pop-up menu.

Directory

To change the directory where the history data is stored, press the Choose... button. A dialog appears that lets you enter a new directory. If the history directory has been already changed earlier, you can select from the last ten locations.

Figure 2.16. Choose history directory

Either enter a directory in the text field directly, or press the Browse... button to invoke a directory browser that lets you search the file system for an existing folder or create a new one.

Since 1.0.3

For security reasons, Jalopy creates a backup copy before it overwrites a file so the file may be restored in case a severe error occurred during the write process. The original file is stored in the backup directory and normally removed after the newly formatted file has been successfully written.

Level

The backup level defines how many numbered backups should be retained (up to 30). The default is to never keep any backups (i.e. the backup level is set to '0'). Use the slider to set the number of backups you want to keep.

Directory

Specifies the directory where file backups are stored. You should leave this setting untouched in order to make your code convention portable across different systems and platforms (See Section 2.1.1.11, “Export code convention” for more information about possible portability issues).

To change the backup directory, click on the Choose... button. A dialog appears that lets you enter a new directory. If the backup directory has been already changed earlier, you can select from the last ten locations.

Figure 2.17. Choose backup directory

During batch-formatting, Jalopy can divide the work onto several processors and/or cores to speed up processing. If you run Jalopy on a multi-processor or multi-core system, use the slider to set the number of processors or cores Jalopy should utilize.

Lets you specify whether and what line ending character(s) should be forced. Enabling the check box causes the selected line separator to be forced for newly formatted files. You can choose from one of the two common platform styles (Unix, Windows) to enforce a specific line terminator. Or select Platform default if you want to obey the line terminator of your platform. Choosing Preserve original keeps the style of the source files, but please note that Jalopy does not support mixed line separators. It will use the style of the first line separator found in a source file for the complete file!

When left disabled, the default behavior depends on the used plug-in: The Ant, Console and Maven plug-ins preserve the original line separator by default (this may be overridden via the “fileformat” attribute, the “format” command-line option, or the “fileFormat” parameter). The Eclipse 2.x and NetBeans plug-ins preserve the original format, too. All other plug-ins use the corresponding IDE setting (sometimes called line terminator or end-of-line characters).

Since 1.2.1

Lets you specify a specific output encoding to be used to write files. Enabling the check box causes the selected encoding to be forced for newly formatted files. You can either choose from one of the platform supported encodings or specify a specific encoding yourself.

When left disabled, the behavior depends on the used plug-in. When using one of the IDE plug-ins, the file encoding as specified in the IDE would be used. But the Ant, Console or Maven plug-ins would use the platform default encoding instead.

Since 1.9.1