JALOPY | Java Source Code Formatter Beautifier Pretty Printer
Overview • Download • Documentation • Plug-ins • Links • Contact
Features | History | Manual | FAQ | Javadoc
This page generated: June 8 2004
4.3.13. Misc
Prev | 4.3. Printer | Next
- ### 4.3.13. Misc Lets you control miscellaneous settings that doesn't fit elsewhere. #### 4.3.13.1. Misc Insert expression parentheses It is always good advise to use more parentheses than you think you need. They may not be needed, but they add clarity and don't cost anything. Example 4.150. How is this expression evaluated?
      int result = 12 + 4 % 3 * 7 / 8;
  Example 4.151. How is this expression evaluated? (continued)
      int result = 12 + ((4 % 3 * 7) / 8);
- Insert serial version UID Common sense dictates to declare an explicit serial version UID in every serializable class to eliminate the serial version UID as a potential source of incompatibility (with the additional benefit of a small performance gain). If this switch is enabled and the class directly dereives from either `java.io.Serializable` or `java.io.Externalizable`, Jalopy computes and inserts a serial version UID for the class. For this feature to work, the class that has its serial version UID computed needs to be available on the classpath. Insert logging conditional Typically, logging systems have a method that submits a logging message like
      logger.debug("some message: " + someVar);
  This is fine, but if the debug level is set such that this message will NOT display, then time is wasted doing the string marshalling. Thus, the preferred way to do this is
      if (logger.isDebugEnabled()) {
          logger.debug("some message: " + someVar);
      }
- which will only use CPU time if the log message is needed. Enabling this switch will ensure that every logging call with the debug level set will be enclosed with the conditional expression. Use this feature with care! The current implementation only supports the Jakarta Log4J toolkit and is somewhat weak in that every method call called debug is treated as a logging call which could be incorrect in your application. However, it works fine for the l7dlog calls. Insert trailing newline If 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 footer insertion will be performed (see Section 4.3.11, “Footer”) Array brackets after identifiers Lets you choose where the brackets of array types should be placed. By default, Jalopy prints the square brackets right after the array type. Example 4.152. Array brackets after type
      int[] a;
  But C/C++ programmers may expect them to appear after the identifier. Example 4.153. Array brackets after identifier
      int a[];
Force formatting Jalopy can keep track of which files have been formatted previously. See Section 4.3.13.2, “History” below. If History is enabled, Jalopy will exclude files that have a modification date coincident with the last formatting. However, you can override this history check to force a format. 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 be formatted. Note that this switch is only meaningful if the history feature is enabled. #### 4.3.13.2. History The history feature offers a way to optimize the speed at which Jalopy processes of a group of files repeatedly. Using history, Jalopy is able to track file modifications between successive invocations, and only format those source files which have actually changed, or which weren't processed previously. This can save a huge amount of execution time for a project that is formatted repeatedly over time. There are two methods for keeping history. Use history file If you can't get along with a history header comment at the top of each source file, but would like historical optimization, the file-based approach may work for you. The history information of previous formatting will be saved in a file `history.dat` under the Jalopy settings directory. Note that this file will grow over time, especially if one manages several big projects. So the history file could become quite huge. As all history entries are read into memory at startup, it could eat up quite a bit of memory space. Therefore a little history viewer is provided which enables you to selectively remove obsolete entries. In order to effectively use formatting of a project with several developers it is nice to be able to only format files which have changed. There are three methods of working out if a file has changed provided in a drop down. Timestamp will use the modification time of the file, this does not work very well with source control and multiple developers. There are two standard checksums available. These work by taking a checksum of the file and comparing it to the one in the history file. If this checksum is different, the file is parsed and formatted in memory and a new checksum calculated. If the new checksum is different than the checksum for the unformatted file, it is written to disk. This stops files that have just been updated from source control from having being formatted (and timestamps updated). Use the View... button to display the history viewer. You can selectively remove entries via the popup menu. Use history comments Jalopy will insert a small comment in the first line of every source file. The comment encodes the time a file was last formatted along with the package name of the file. This method is precise and relatively foolproof but does not work well with SCM tools. #### 4.3.13.3. Backup For security reasons Jalopy creates a backup copy of the currently processed file so it can be restored in case a severe error occured during the formatting process. The original file is stored in the backup directory and normally deleted 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 hold any backups. Directory Specifies where file backups are stored. You should leave this setting untouched in order to make your code convention portable across different systems and platforms. #### 4.3.13.4. Threads Jalopy, more precisely the provided Plug-ins, are multi-threaded. On multi-processor systems the work can be divided onto several processors to speed up processing. Number Specifies the number of processing threads to be used. This setting should be equal to the number of processors your system has.
Prev | Up | Next
4.3.12. Sorting | Home | 4.4. Code Inspector
to top