Compiling Java programs

The JBuilder compiler has full support for the Java language, including inner classes and JAR files. You can compile from within the integrated development environment (IDE).

bmj and bcj are features of JBuilder Professional and Enterprise.

With JBuilder Professional and Enterprise, you can also compile from the command line using bmj (Borland Make for Java) or bcj (Borland Compiler for Java).

A Java compiler reads Java source files, determines which additional files need to be compiled, and produces the Java program in the form of .class files containing bytecodes that are the machine code for the Java Virtual Machine (VM).

Compiling produces a separate .class file for each class declaration and interface declaration in a source file. 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.

For additional general information about compiling in Java, see the overview of the compiler that comes with the Java Development Kit (JDK), "javac - The Java programming language compiler."

Smart Dependencies Checking

JBuilder provides fast yet complete compiling by using Smart Dependencies Checking, which results in fewer unnecessary compiles of interdependent source files, and thus accelerates the edit/recompile cycle. When compiling, instead of deciding whether to recompile a source file based only on the time stamp of the file, JBuilder analyzes the nature of the changes you make to source files.

When you compile source files for the first time, a dependency file is automatically created for each package and is placed in the output directory along with the class files. The dependency file contains detailed information about which class uses which for all the classes in that package. This file has an extension of .dependency.

Dependency files must be located in the Class Path so the compiler can find them. When you compile from within the IDE, the Class Path is correctly set by default. For information on how the Class Path is constructed, see the "Class Path" section in the "Creating and managing projects" chapter.

If you compile from the command line, you might need to set the CLASSPATH environment variable. For more information, see "Setting the CLASSPATH environment variable for command-line tools."

Smart Dependencies Checking is used by the compiler in the IDE and by the bmj command-line make but not by the bcj command-line compiler. (bmj and bcj are available in JBuilder Professional and Enterprise.)

Important: Archives are considered "stable" and are not checked by the Dependency Checker.

See also: "JBuilder Dependency Checker" on Blake Stone's home page at http://homepages.borland.com/bstone/articles/depchecker.html


Types of compiling

The commands for compiling from within the IDE include:

The following parts of a program can be compiled:

To understand how JBuilder locates files to compile the program, see "How JBuilder constructs paths" and "Where are my files?"

The Make command

Project|Make compiles any .java files within the selected node that have outdated or nonexistent .class files. The Make command also compiles any files imported by the node that have outdated or nonexistent .class files.

The selected node can be a project, package, or .java file. Making a package or project includes all the .java files within the package or project, including those within nested packages.

An "outdated" .class file is one that was not generated by compiling the current version of its .java source file.

The imported files that are checked and compiled include all recursively imported files (that is, imported files of imported files) except for files that are not in packages in the current project, such as files in packages that are marked "stable."

Make is faster than Rebuild, once you have done the initial compiling. The Make command is generally preferred over Rebuild.

To Make a node, select the node in the project pane, and choose Make <node name>.

Issuing File|Save and then Make on a file won't necessarily cause the file to be recompiled, because the date-time stamp reflects the last edit action, not the last save. To force a recompile, either use Rebuild <node name>, or make a change to the file in the editor before saving it. For example, type a space and then a backspace.

The Rebuild command

Rebuild <node name> compiles all .java files within the selected node, regardless of whether their .class files are outdated. The Rebuild command also compiles the imported files, regardless of whether their .class files are outdated. Compiler options, such as Obfuscate, are applied to all files as they are compiled.

The selected node can be a project, package, or .java file. Rebuilding a package or project includes all the .java files within the package or project, including those within nested packages.

The imported files that are compiled include all recursively imported files (that is, imported files of imported files) except for files in the stable packages that are not part of the project.

To Rebuild a node, select the node in the project pane, and choose Project|Rebuild <node name>.

The Run command

The Run command (Run|Run Project) and the Run button Run button  compile and run your application without debugging it (if the option is set to Compile Before Debugging on the Run page of the Project Properties dialog box).

See also: Running Java programs


Automatic source packages

This is a feature of JBuilder Professional and Enterprise.
When the Enable Source Package Discovery And Compilation option is enabled, all packages in the project's source path automatically appear in the project pane. When compiling with this option on, any packages that contain Java files are automatically compiled and resources in these packages are automatically copied to the project's out path. Packages that contain only resources are also copied to the out path.

To minimize the number of package nodes listed, JBuilder automatically displays a subset of the packages in your project. Even though some source packages may not be listed at the top level of your project, JBuilder still compiles them and copies their resources.

Important: After adding new source files to the project, select the refresh button on the project toolbar to update the automatic source package list.

This option is found on the General page of the Project Properties dialog box and is on by default. You can also control the level of packages displayed in the project pane by changing the value of Deepest Package Exposed. For more information on this feature, press the Help button on the General page.

See also: "How JBuilder constructs paths"


Compiling a program

To compile the source files for an application or applet:
  1. Open the project containing the program, or open a single Java file.
  2. Select the .jpr or .jpx project node in the project pane.
  3. Then, do one of the following:

Syntax errors and error messages

Syntax errors are errors that violate the syntactical rules of the Java programming language. The editor catches these errors as they occur, before you compile. Syntax errors are displayed in a folder at the top of the structure pane.

To locate the line of code containing the error, expand the Errors folder in the structure pane and double-click the error. The line containing the error is highlighted in the editor.

Error messages also appear on the Compiler tab in the message pane during compiling. Select an error message and press F1 for Help. Use the arrow keys to navigate through compiler error messages. Click an error message to highlight the code in the open file.

Error messages

See also:
About error and warning messages
"Error Messages" where error messages are listed by number

Compile problems when opening projects

If you open a project and it won't compile, check the path settings on the Paths page of the Project Properties dialog box to make sure they are set correctly. JBuilder uses the path settings to construct the Class Path and Source Path, which is where the compiler looks for files.

Additionally, check the Required Libraries list on the Paths page. If one or more of the libraries is highlighted in red, it is not defined for your installation of JBuilder. Double-click the library name to define it. Then, try to recompile the project.

To set default paths for new projects (to avoid future potential problems), use the Default Project Properties dialog box (Project|Default Project Properties). See the "Setting project properties" and "How JBuilder constructs paths" topics in the "Creating and managing projects" chapter for more information.

Checking for package/directory correspondence

JBuilder provides protective checking for duplicate class definitions in a project and for package/directory correspondence. The bmj compiler (JBuilder Professional and Enterprise) and the IDE compiler verify that the package statement in a source file corresponds to the package directory, and verify that two source files do not define the same class.

The first time you build a project, all the available .java files in a package directory will be verified and compiled. If you have temporary sources that you do not want to compile, you should use another extension besides .java. For example, if the project contains an old version of a file you are working on and that file contains another definition of the same class, you'll get a "duplicate class definition" error. This checking prevents subtle problems that would be difficult to locate.

If you are using a class library that is partly inconsistent and you don't have the sources to rebuild the library, you can avoid verifying all classes of the package, and check only the classes that are actually used, by specifying the -nomakestable compiler option on the command line. In the IDE, check the Make Stable Packages option on the Build page of the Project Properties dialog box to accomplish the same result. See "Setting compiler options" for more information.

Selectively compiling stable packages

Packages of common libraries, such as java.lang,  or  sun.io, are rarely modified, so it is usually unnecessary to take the time to recheck them for consistency every time you compile. To prevent these libraries from being checked every time you compile, these packages are marked "stable." When all classes of a package have been successfully compiled, the package is considered "stable" and a flag is set in the dependency file. When only some classes of a package have been compiled or if an error occurred, then the package remains marked "unstable."

Stable packages won't be checked for consistency if you are compiling within the IDE and the Check Stable Packages option is off on the Build page of the Project Properties dialog box (Project|Project Properties) or if you specify the -nocheckstable option for the bmj command-line make (JBuilder Professional and Enterprise). As a result, stable packages are not checked for being up-to-date. However, if a package is included in your project, or if at least one source file in the package is included in your project, that package will be marked "unstable" and will be checked at every recompilation (that is, every time you do Project|Make Project).

In the IDE, if a package is marked stable but you are editing a file of that package outside of the IDE (using a different editor), it's best to include that package in the project so it is checked for recompiling. In the IDE, the compiler does not check packages marked stable to see if they are up-to-date, unless they are part of the project.

Important: Archives are considered "stable" and are not checked by the Dependency Checker.

Making stable packages

Within the IDE, check the Make Stable Packages option on the Build page of the Project Properties dialog box to make all the classes of a package the first time it is built and to mark the package as stable.

If this option is off or if the -nomakestable option is specified for the bmj compiler (JBuilder Professional and Enterprise), only the referenced classes of the package are made, and the package remains "unstable." This is useful when you are working with a library of classes for which you have no source code and some of the unused class files are not consistent.


Setting compiler options

You can specify compiler options for the current project. The options are applied to all files in the project tree. The options are also applied to files referenced by these files, stopping at packages that are marked stable and have no classes in the project tree.

To set compiler options,

  1. Select the .jpr or .jpx project node in the project pane.

  2. Right-click and choose Properties. The Project Properties dialog box is displayed.

  3. Select the Build tab to display the Build page. Then select the Java tab.

    Build page

  4. Select from the following options:

    Option Description

    Include Debug Info Includes symbolic debug information in the .class file when you compile, make, or rebuild a node.
    Show Warnings Displays compiler warning messages.
    Show Deprecations Displays all deprecated classes, methods, properties, events, and variables used in the API. When a warning is displayed that deprecated APIs were used, turn this option on to see specifically what is deprecated.
    Synchronize Output Dir Deletes class files on the out path that you don't have source files for before compiling. The out path directory is specified in the Output Path field on the Paths page of the Project Properties. The location of source files are specified on the Source tab of the Project Properties Paths page.
    Check Stable Packages Checks 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 not re-checking stable packages.

    If this option is off, 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. With this option, you might need to specify a greater number of modules to compile.

    By default, the compiler checks packages marked stable as well as packages marked unstable to determine whether they and their imported classes need to be recompiled.

    Make Stable Packages If this option is on, the compiler will compile or check all the classes of a package on the first build and mark the package "stable." If this option is off, only the referenced classes of this package will be made and the package will not be marked stable.

    This option should be off when working with partial projects.

    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.

    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.
    Exclude Class Excludes the selected .class file from a compile.
    Autosave All Files Before Compiling Automatically saves all files in the project.
    Generate Source to Output Path Causes source code generated from an RMI or IDL file during a make to be saved in the out path. The out path is specified in the Output Path field of the Project Properties Paths page and defaults to the jbproject/project_directory_name/classes directory in the user's home directory.

  5. Select OK to close the Project Properties dialog box and save your settings.

Note: The options set on the Build page of the Default Project Properties dialog (Project|Default Project Properties) are used for new projects.

The scope of project-wide settings

If you change compiler options, you should fully rebuild your packages or your entire project and not just make them. The project options are applied to any class being rebuilt, outside the project tree as well as inside the project tree. For example, if you set obfuscation on some classes and compile them in one project, then in another project you reference those same files without obfuscation, but choose Project|Rebuild Project, you will unobfuscate them.

You cannot set compile options per file; however, a file can be used by two projects, both of which have different settings for compiling. Applying options on classes or packages individually is not supported, because there is no separate compilation of headers and modules in Java. If some import information is missing (such as a class file), the imported class is compiled at the same time as the importing class, using the same project-wide options.

Adding symbolic debug information

To add symbolic debug information at compile time, choose Project|Project Properties. Select the Java tab on the Build page and check the Include Debug Information option.

When you compile, make, or rebuild a node, symbolic debug information will be included in the .class file.


Setting the output path

You can set the output path for your compiled class files in the Project Properties dialog box.

To set the output path,

  1. Select Project|Project Properties
  2. Select the Paths tab to display the Paths page.

    Paths page

  3. Select the ellipsis button to the right of the Ouput Path field.
  4. Browse to the directory you want your compiled class files to be saved in and select it. If the directory does not exist, select the New Folder button and create one.
  5. Select OK.


Compiling from the command line

These are features of JBuilder Professional and Enterprise.
You can compile from the command line using the bmj or bcj commands. To see the syntax and list of options, type bmj or bcj at the command line. You can also build a project from the JBuilder command line.

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

bmj

This is a feature of JBuilder Professional and Enterprise.
The bmj compiler is the Borland Maker for Java. bmj compiles any .java files within the selected node that have outdated or nonexistent .class files. bmj also compiles any imported classes that have outdated or nonexistent .class files.

bmj looks for dependency files on the Class Path, and does dependencies checking. 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 modules, it is sufficient to call bmj on the root source (or multiple root sources if one is not under the other). You can specify this argument using source names, package names, class names, or a combination.

See also:
"The bmj command-line make"
"Setting the CLASSPATH environment variable for command-line tools"

bcj

This is a feature of JBuilder Professional and Enterprise.
The bcj compiler is the Borland Compiler for Java. bcj compiles the specified sources, whether or not their .class files are outdated. It also compiles any directly imported .java files that do not have .class files. Imported .java files that already have .class files will not be recompiled, even if their .class files are outdated; after using bcj, some imported classes might still have outdated .class files.

bcj does not do dependencies checking, and does not use or generate a dependency file. bcj only compiles the items you specify.

See also:
"The bcj command-line compiler"
"Setting the CLASSPATH environment variable for command-line tools"

Building a project from the command line

This is an option in JBuilder Professional and Enterprise.
You can build a project file from the JBuilder command line using the -build option from the jbuilder/bin directory:

jbuilder -build <ProjectName.jpr>

For example, to build test.test3.jpr which is located in the jbproject/project1 directory, enter the following at the command line from the jbuilder/bin directory:

jbuilder -build jbproject/project1/test.test3.jpr

See also: "JBuilder command-line arguments"

Switching between the command line and IDE

If you edit a file outside the IDE, be sure to include its package or at least one of that package's sources in your project, so that the package is considered "unstable" and is checked when you compile. Otherwise, the change will not be detected, and the source won't be recompiled.

The default setting at the command line is to check consistency for referenced classes, regardless of whether their packages are marked "stable" or "unstable." The option -nocheckstable is not specified by default on the command line.