Java Reference
In-Depth Information
Building CLDC/MIDP Applications
The NetBeans IDE uses the same Java compiler to build CLDC applications and other
applications; behind the scenes, it uses a special option (
-bootpathoption
) to redirect the
compiler to use different fundamental classes for the CLDC. This is important, because
as you remember from the first chapter (and learned in detail in the previous chapter),
not all classes and methods in the base hierarchy are provided as part of the CLDC.
Build options—especially optimization and obfuscation—play a big part in building
for Java ME devices, for two reasons. First, these are commercial applications, distributed
to a wide audience, so of course you want to keep your intellectual property away from
the prying eyes of a decompiler. Second, and more important, optimization and obfusca-
tion result in a smaller application, meaning that it takes less time to transfer to the target
hardware and uses less memory on the target hardware. This is because obfuscation
renames classes, member variables, and method names to shorter names, removing
unused classes, methods, and member variables in the process. The NetBeans IDE
includes the popular open source ProGuard obfuscator, which you can control using the
Obfuscating panel in the Project Properties window. When compiling, you might want to
test both optimized and nonoptimized builds for memory and time performance, too; go
to the “Compile with Optimization” item in the Compiling panel of your project's proper-
ties. Finally, get in the habit of shipping release builds with no debugging information;
doing so will lead to smaller binaries.
To manage all of this, the NetBeans SDK provides the notion of a
project configura-
tion
, which is a collection of project options that includes the target platform, the
application description and packaging (see the next section), and the build options.
You create new project configurations in the Project Properties window by clickin the
Manage Configurations button in the upper-right corner. Doing this brings you to a list
of configurations from which you can add and remove configurations; in turn, project
properties are keyed by the configuration you select in the Project Configuration window,
shown in Figure 3-9. As you can tell from the figure, I like to have three project configura-
tions: one for debugging, one for release, and one for a default configuration. More
complex projects may require additional configurations to manage specific builds for
particular hardware targets or other variables.
If you're familiar with the Java build process, you may have seen an additional step
during the build you performed in the previous section. Take a close look at the output
log, and you'll see lines after the obfuscation step labeled
pre-preverify
,
preverify
, and
post-preverify
.
As you recall from the first chapter, unlike the CDC or the standard JVM, the virtual
machine used by the CLDC delegates some of the more expensive bytecode verification
to the build process. This occurs
after
code obfuscation, and it's the last step prior to
packaging your application. The preverify tool inlines subroutines in each class file and
adds information to each stack frame to make it easier for the runtime virtual machine to
perform necessary type checking and other bytecode verification.
