JMLDOC(l) JMLDOC(l) 1mNAME0m jmldoc - generate HTML pages from JML and Java files 1mSYNOPSIS0m 1mjmldoc 22m[option] ... file-or-package-or-directory [file-or-package-or- directory] ... 1mjmldoc-gui 22m[option] ... file-or-package-or-directory [file-or-package- or-directory] ... 1mDESCRIPTION0m The command 1mjmldoc 22mand the graphical user interface version 1mjmldoc-gui0m generate HTML (web) pages from JML annotated Java(TM) and JML files. This is similar to Javadoc, but 1mjmldoc 22munderstands JML specifications, and includes this information in the generated HTML pages. The program also type checks the JML specifications to some extent and combines annotations across refinement files. The output is a set of HTML files that can be browsed using a web browser. The 1mjmldoc 22mscript sets the CLASSPATH and then runs the Java class org.jmlspecs.jmldoc.Main, which does both syntax and type checking of Java and JML files, and then generates the HTML pages. The 1mjmldoc-gui 22mscript is similar, but just runs the Java class org.jml- specs.jmldoc.JmldocGUI, which brings up a graphical user-interface to do the HTML generation. This version of jmldoc is compatible with Java 1.4.1 and not with any earlier versions of the Java developement kit. The non-option arguments may be either a filename, a dot-separated package name, or a directory name. A simple name is interpreted as a package name. When packages or directories are given, jmldoc processes all files in the named directory with either a .java suffix or a legal refinement suffix (e.g. .refines-java). 1mOPTIONS0m This program supports the options described below. There are two kinds of options, some contributed by javadoc and some contributed by the mjc parser that is used by jmldoc. Options from javadoc consist of a single hyphen and the name of the option; if there is an argument to the option it is separated from the name of the option by whitespace. Options contributed by the mjc parser have both a long and short form. The short forms consist of a single hypen and a single letter. The long forms consist of one or two hyphens and a word. To avoid duplica- tion, we only show the long forms with two hyphens, since these are unambiguous; however one can use the forms with a single hyphen if desired. To avoid ambiguity between multiple short form options and the long form with a single hyphen, one should give each option sepa- rately. In the synopsis below, the long form is separated from the short form by a comma (,), but in actual usage, you would pick one of these forms and not use the comma. Note that options given on the command line are case sensitive. 1m--ImplicitPromotion, -i0m This disables implicit promotion (to \bigint). This promotion only occurs within specifications and in specification expres- sions, and does not affect Java code. The default is to have such implicit promotions to \bigint. 1m--Quiet, -Q, -quiet0m Shuts off all type checking informational messages. The default is to produce these messages. (The jmldoc --Quiet is now equiv- alent to the javadoc -quiet, but not to the jmldoc option --quiet). 1m--admissibility 0m Checks the admissibility of invariants and represents clauses in accordance with a certain proof technique. For more details about admissibility see "Modular Invariants for Layered Object Structures" by P. Mueller, A. Poetzsch-Heffter and G. Leavens, 2004. Statics (static invariants, static represents clauses and static fields appearing in one of the former) and method calls (in an invariant or a represents clause) are not yet supported. Available option strings: "none" No admissibility checks are performed. This is the default. "classical" Admissibility checks of invariants and represents clauses are done in accordance with the classical modular proof technique. See the above mentioned paper for details. "ownership" Admissibility checks of invariants and represents clauses are done in accordance with the ownership proof technique, using the UTS information. Therefore this option only makes sense if the UTS is enabled at least for parsing and typechecking. Additionally fields and methods are checked to ensure subclass separation. For further details see the above mentioned paper. 1m--Assignable, -A0m Turn off errors that are otherwise given when a method with an "assignable" clause calls methods that do not have "assignable" clauses. The default is to produce such messages. 1m--assignable, -a0m Turn off caution messages for heavyweight specification cases of non-pure methods that have no "assignable" clause. A heavyweight specification case is a specification case that starts with one of the keywords "behavior", "normal_behavior", or "excep- tional_behavior". A pure method is a method annotated with the JML modifier "pure". The default is to produce such caution messages. 1m--classpath , -C 0m Use the given string as the CLASSPATH. By default the value of the environment variable CLASSPATH is used instead. 1m--debug, -c0m Produces (copious) debugging information. The default is not to produce this information. 1m--deprecation0m Test for deprecated members. The default is not to test for deprecated members. (Not applicable to jmldoc) 1m--destination , -d 0m Writes HTML files in a subdirectory corresponding to the file's package name, relative to the named destination directory. The default is the current working directory. 1m--docpath 0m A path (directory list separated by the path separator charac- ter) that tells where to find javadoc files. Using this option is equivalent to a series of -link options each specifying one directory from the directory list. 1m--excludefiles 0m A pattern (regular expression) for file names to exclude from processing. By default this is the pattern _JML_Test[\044.] which means that file names that contain the strings _JML_Test. or _JML_Test$ are not processed (044 is the octal code for a dollar sign), unless they are referred to by other files that are processed. The regular expressions that can be used are described in the javadocs for the type java.util.regexp.Pattern. For example, when building the JML documentation, we use the pattern _JML_Test[\044.]|TestSuite\.[^.]+ which excludes files with names like TestSuite.java, as well as the _JML_Test files. This was necessary for us, becuase the TestSuite.java files reference the types named _JML_Test. 1m--fcns