Features

Problem: Each assembly language for the Java VM defines its own syntax to represent the Java bytecode. The main technical problem of the other assembly languages for the Java VM is the way their syntax is defined. They are syntactically designed like assembly languages which were in use twenty or thirty years ago. The syntactical advancements which have been reached by XML in the meantime, are totally ignored by them. Parsers and generators for them, not to speak of transformers, are rather rarities. Therefore the future development of automated tool chains which use them is severely limited.

Problem: The class-files of Java contain an explicit pool to collect constants like strings, numbers, and names, which are used in the definition of the class and its members. This makes the class-files compact because these constants are stored only once in the pool, and referred to by indices from the outside. But handling with indices and following their indirection makes programming unnecessarily complex and error-prone.

Problem: The "Code" attributes represent the executable instructions of methods inside the Java bytecode. These attributes have fields called "max-stack". These fields give the maximum depth of the operand stack at any point during execution of the corresponding methods. These fields are checked by the bytecode verifier of the Java VM. The values of "max-stack" mustn't be too low, which would yield incorrect code, and shouldn't be too high, which would result in inefficient code. It is therefore crucial for the assembler to generate correct and optimal values.

Problem: The local variables of a method as defined by the Java Virtual Machine Specification are identified by their index into an array of integers. Values of type long and double need two consecutive integers to be stored, invalidating the index of the second integer for storing and identifying other locals. Therefore no direct one-to-one mapping from the number of a "local" to its index exists. Beyond that the name "local variables" is somewhat misleading, because they not only contain the local variables as they are called in the context of Java source-code, but also the values of the parameters of the method. This makes the programming of Java bytecode overly complex and error-prone.

Problem: Manually calculating instruction offsets for branch-instructions is tedious and error-prone. An assembler should define labels and prevent the programmer from making unnecessary mistakes.

Problem: The Java Virtual Machine Specification defines the structure of the class-files and the contained instructions. Some sub-sets of instructions in the Java bytecode form families, i.e. the have the same function, but differ in their concrete representation. As an example take the function to push an integer value onto the operand stack. It has the following concrete physical representation as opcodes: "iconst_m1", "iconst_0", "iconst_1", "iconst_2", "iconst_3", "iconst_4", "iconst_5", "bipush", "sipush", "ldc", and "ldc_w". To handle them explicitly is complex and error-prone.

Problem: Java uses Unicode to encode characters. Each string in Java bytecode therefore contains Unicode characters, most of them valid, but some of them invalid.

Problem: Modification of Java bytecode requires the identification of the items to modify. There has to be a selection mechanism that defines the context in which the modification has to take place. This is especially necessary for automated transformations.

Problem: The Java bytecode mainly consists of attributes which define it's contents. The most important attributes are predefined by Sun Microsystems and understood by the Java-complying VMs, like the "Method"-attribute or the "Code"-attribute. The Java Virtual Machine Specification also allows users to define their own attributes as long as they don't conflict with the predefined attributes. This is useful for carrying some additional information with the bytecode, especially for tools that like to store metadata in it, say specific debugging information, the time and date of the construction of the class, additional design-data for round-trip engineering, and so on. Injection and extraction of these additional information has been painful or sometimes impossible to do in the past, because it was necessary to write special generators and parsers corresponding to the injected and extracted data. These generators and parsers were dependent on the APIs of the used libraries and therefore not portable.

Problem: Tools need to be available as an API to be embeddable into applications, and on the command-line to be easily callable in scripting scenarios.