bmj command-line make

This is a feature of JBuilder Professional and Enterprise.

Syntax

bmj [options] rootClasses

Description

Borland Make for Java (bmj) compiles Java source code into Java bytecodes from the command line and checks for dependencies to determine which files actually need to be recompiled. bmj produces the Java program in the form of .class files containing bytecodes that are the machine code for the Java virtual machine. Compiling a source file produces a separate .class file for each class declaration or interface declaration. When you run the resulting Java program on a particular platform such as Windows NT, the Java interpreter for that platform runs the bytecodes contained in the .class files.

bmj looks for dependency files on the classpath. If you specify a set of sources, some or all of those sources might not be recompiled. For example, the class files might be determined to be up to date if they have been saved but not edited since the last compile. You can force recompilation using the -rebuild option.

To check a set (or graph) of interdependent classes, it is sufficient to call bmj on the root class (or multiple root classes, if one is not under the other). You can specify root classes using class names, package names, names of sources that declare classes, or a combination.

To see the syntax and list of options at the command line, enter the bmj command with no arguments.

You might need to set the CLASSPATH environment variable for the command line, so the required classes are found.

See also:
"Smart Dependencies Checking"
"Compiling from the command line"
"Setting the CLASSPATH environment variable for command-line tools" in "Using the command-line tools"
"Setting the classpath" in the Java Tools documentation
"bcj command-line compiler"

Options

Note: Directories listed in paths are separated by colons on the UNIX platform and by semicolons on the Windows platform. The following examples represent the UNIX platform.

-classpath path
The path used to find classes and dependency files. Overrides the default or the CLASSPATH environment variable. You should always include the outpath at the beginning of the path. The classpath is also used to search for sources if no sourcepath is specified.

For example:

bmj -classpath jbproject/testing/classes/test3:
jbproject/project1/classes tester.java 

-d directory
The root directory of the class (destination) file hierarchy. Also referred to as the "outpath".

For example, the following statement:

bmj -d jbproject/project1/classes tester.java
causes the class files for the classes defined in the tester.java source file to be saved in the directory jbproject/project1/classes/test/test3, assuming that tester.java contains the following package statement: package test.test3;

The updated dependency file, test.test3.dependency, is saved in jbproject/project1/classes/dependency cache.

Files are read from the class path and written to the destination directory. The destination directory must be part of the class path. The default destination for class files matches the package structure in the source files and starts from the root directory of the source. The default destination for dependency files matches the package structure and starts in the current directory.

-deprecation
Displays all deprecated classes, methods, properties, events, and variables used in the API.

If a warning is displayed when compiling, indicating that some deprecated APIs were used, you can turn this option on to see all deprecated APIs.

-encoding name
You can specify a file-encoding name (or codepage name) to control how the compiler interprets characters beyond the ASCII character set. The default is to use the default native-encoding converter for the platform. For more information, see the topic called "Specifying a native encoding for the compiler" in the Internationalizing programs with JBuilder chapter.

For example, the following statement:

bmj -encoding EUC_JP tester.java
compiles tester.java and any directly imported .java files that do not have .class files. All source files are interpreted as being encoded in the EUC_JP character set, which is the character set typically used for Japanese UNIX environments. You can specify any encoding that is supported by the Java 2 platform. A list of the valid encodings is available at http://java.sun.com/j2se/1.3/docs/tooldocs/tools.html#intl.

-g
Generates debugging information in the class file, such as line numbers and local variables.

-nocheckstable
Does not check files in the packages that are marked stable to see whether they and their imported classes need to be recompiled. This option shortens the edit/recompile cycle by skipping re-checking stable packages.

With this option, a given branch of the checking process halts when it reaches a package marked stable; it does not look for unstable packages imported by the stable packages. Therefore, with this option, you might need to specify a greater number of modules to compile. Suppose unstable package A uses stable package B, which uses unstable package C. If you want to skip rechecking the stable package B, then you need to specify compiling package C in addition to package A; otherwise, package C will not be checked (unless A depends directly on C).

By default, bmj checks packages marked stable as well as packages marked unstable, to determine whether they and their imported classes need to be recompiled. For more information, see the topic called "Selectively compiling stable packages" in the "Compiling Java Programs" chapter of Building Applications with JBuilder.

-nocompile
Checks whether the classes are up-to-date, but doesn't compile any classes. Useful for quickly checking whether a class or package is up to date. Stops at the first file needing recompilation, and reports "Class <class> needs recompiling because <reason>."

-nomakestable
If this option is not specified, bmj will make (compile or check) all the classes of a package on the first build and mark the package stable. With this option, only the referenced classes of this package will be made, and the package will not be marked stable.

This option is especially useful for working with a library of classes with no source available, when some of the class files are not consistent, but not used.

See also:
Building Applications with JBuilder, "Compiling Java Programs: The Make command"
Building Applications with JBuilder, "Compiling Java Programs: Selectively compiling stable packages"

-nowarn
Compiles without displaying warnings.

-obfuscate
Obfuscation makes your programs less vulnerable to reverse engineering. After decompiling your obfuscated code, the generated source code contains altered symbol names for private symbols.

-quiet
Compiles without displaying any messages.

-rebuild
The Rebuild command compiles the specified root classes and their imported files, regardless of whether they have changed.

See also:
Building Applications with JBuilder, "Compiling Java Programs: The Rebuild command"

-sourcepath path
The path used to find sources. If no source path is specified, the classpath is used to find the sources.

Similar to the classpath, the sourcepath must point to the root of the package directory tree, and not directly to the directory of the sources.

For example, to make tester.java, which contains the package statement package test.test3; and is located in jbproject/project1/src/test/test3, you must set the source path to jbproject/project1/src and not to jbproject/project1/src/test/test3.

You can then type the following:

bmj -sourcepath jbproject/project1/src
jbproject/project1/src/test/test3/tester.java
-d jbproject/project1/classes

-sync
Deletes class files on the out path that you don't have source files for before compiling. You have to specify the out path directory using the -d option.

This option can be helpful to avoid situations when the compiler might find a class file in the output directory, which cannot be compiled from source. (You may have deleted the source file or you have renamed one of the classes declared in a source file.)

-verbose
This option gives more information about compiling, such as which class files are loaded from where in the classpath. The following information is displayed:

Cross-compilation options

bcj supports cross-compilation, where classes are compiled against a bootstrap and extension classes of a different Java platform. Use -bootclasspath and -extdirs when cross-compiling.

-target version
Generates the class files to work on a specific VM version. The default is to generate class files that are compatible with versions 1.1 and 1.2. bcj supports:

-bootclasspath bootclasspath
Cross-compile against the specified boot classes. Entries can be directories, JAR archives, or ZIP archives.

-extdirs directories
Cross-compile against the specified extension directories. Each JAR file in the specified directories is searched for class files.

Specifiers for root classes

Root classes are specified in the following form:
{[-s] {source.java} | -p {package} | -c {class}}

-s sourcefilename
Indicates that the specified root classes are those defined in the given source files. This is the default interpretation.

For example, the following statement:

bmj -sourcepath jbproject/project1/src 
-s jbproject/project1/src/tester.java
is the same as
bmj -sourcepath jbproject/project1/src 
jbproject/project1/src/tester.java

If you list some packages with the -p option before listing sources, then you need to specify the -s option. If you list sources before packages and classes, the -s is assumed and is not necessary.

-p packagename
The name of packages to compile.

For example, the following statement:

bmj -sourcepath jbproject/project1/src -p test.test3
makes all classes of the test.test3 package and all imported classes.

-c classname
The names of the classes to make.

For example, the following statement:

bmj -sourcepath jbproject/project1/src
-c test.test3.tester
makes the class tester of package test.test3 and all imported classes.

As another example, the following statement:

bmj -sourcepath jbproject/project1/src tester.java -p package1 package2 
-s jbproject/project1/src/*.java
makes the source file tester.java, packages package1 and package2, and all the java files in the jbproject/project1/src directory.

Note that the first source name (tester.java) comes before the -p (package) option so does not need to explicitly specify the -s option, because -s is assumed. If you want to specify another source file name after the -p option is specified, you have to explicitly specify the -s option.

VM options

-Joption
Passes options to the java launcher called by bmj. For example, -J-Xms48m sets the startup memory to 48 megabytes. It is a common convention for -J to pass options to the underlying VM executing applications written in Java.

Note that CLASSPATH, -classpath, -bootclasspath, and -extdirs do not specify the classes used to run bmj. If you do need to do this, use the -J option to pass through options to the bmj launcher.