SOAR Output Files
When building a Standalone Application, multiple files are generated next to the ELF executable file.
Launch Output Folder
Using a MicroEJ Application Launch, the files are generated in a folder which is named like the main type and which is located in the output folder specified in the run configuration.
Published Module Files
After building the Standalone Application, the published module contains the following main files:
[name]-[version].out
: Firmware (ELF Executable)[name]-[version].zip
: Virtual Device[name]-[version]-workingEnv.zip
: Build intermediate files, including the content of the launch output Folder
The SOAR Map File
The .map
file lists every embedded symbol of the application (section, Java class or method, etc.) and its size in ROM or RAM.
Since Architecture 8.x
, this file is called <main class>.map
. It was formerly named SOAR.map
for Architecture 7.x
.
This file can be opened using the Memory Map Analyzer.
The embedded symbols are grouped into multiple categories. For example, the Object
class and its methods are grouped in the LibFoundationEDC
category.
For each symbol or each category, you can see its size in ROM (Image Size
) and RAM (Runtime Size
).
The SOAR groups all the Java strings in the same section, which appears in the ApplicationStrings
category.
The same applies to the static fields (Statics
category), the types (Types
category), and the class names (ClassNames
category).
The SOAR Information File
The SOAR information file contains details on the embedded elements of an application.
Since Architecture 8.x
, information are dispatched in separate files which are related to SOAR build phases:
soar/<main class>.loadermap
: generated by the SOAR Resolver. It provides details on files and resources that have been loaded from the Application Classpath.soar/<main class>.selectormap
: generated by the SOAR Resolver. It provides details about the elements that have been included in the application.soar/<main class>.optimizermap
: generated by the SOAR Optimizer. It provides details about the elements that have been linked in the application.
Each of these files can be opened with an XML editor. The following table describes the information that can be retrieved with their file location.
Information |
XML Location (tag > subtag [attribute=value]) |
File Location |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
N/A |
N/A |
|
Interned strings |
|
|
|
|
|
Types |
|
|
Number of types |
|
|
Number of concrete classes |
|
|
Number of abstract classes |
|
|
Number of interfaces |
|
|
Number of arrays |
|
|
Class instance size (in bytes) |
|
|
Type embeds its name |
|
|
|
|
|
Number of reference fields in a class |
|
|
Methods |
|
|
Method code size (in bytes) |
|
|
Method is inlined |
|
|
Method is exposed as Kernel API |
|
|
Statics fields |
|
|
Information |
XML tag>subtag[attribute=value] |
File |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Interned strings |
|
|
|
|
|
Types |
|
|
Number of types |
|
|
Number of concrete classes |
|
|
Number of abstract classes |
|
|
Number of interfaces |
|
|
Number of arrays |
|
|
Class instance size (in bytes) |
|
|
Type embeds its name |
|
|
|
|
|
Number of reference fields in a class |
|
|
Methods |
|
|
Method code size (in bytes) |
|
|
Method is inlined |
|
|
Method is exposed as Kernel API |
|
|
Statics fields |
|
|