| 失效链接处理 |
|
asm4-guide PDF 下载
本站整理下载：
提取码：193r
相关截图：
主要内容：
1. Introduction
1.1. Motivations
Program analysis, generation and transformation are useful techniques that
can be used in many situations:
• Program analysis, which can range from a simple syntaxic parsing to a
full semantic analysis, can be used to find potential bugs in applications,
to detect unused code, to reverse engineer code, etc.
• Program generation is used in compilers. This include traditional compilers, but also stub or skeleton compilers used for distributed programming, Just in Time compilers, etc.
• Program transformation can be used to optimize or obfuscate programs,
to insert debugging or performance monitoring code into applications,
for aspect oriented programming, etc.
All these techniques can be used for any programming language, but this is
more or less easy to do, depending on the language. In the case of Java
they can be used on Java source code or on compiled Java classes. One of
the advantages of working on compiled classes is that, obviously, the source
code is not needed. Program transformations can therefore be used on any
applications, including closed source and commercial ones. Another advantage
of working on compiled code is that it becomes possible to analyze, generate or
transform classes at runtime, just before they are loaded into the Java Virtual
Machine (generating and compiling source code at runtime is possible, but
this is really slow and requires a full Java compiler). The advantage is that
tools such as stub compilers or aspect weavers become transparent to users.
Due to the many possible usages of program analysis, generation and transformation techniques, many tools to analyze, generate and transform programs
have been implemented, for many languages, Java included. ASM is one of
these tools for the Java language, designed for runtime – but also offline – class
1
1. Introduction
generation and transformation. The ASM1
library was therefore designed to
work on compiled Java classes. It was also designed to be as fast and as small
as possible. Being as fast as possible is important in order not to slow down
too much the applications that use ASM at runtime, for dynamic class generation or transformation. And being as small as possible is important in order
to be used in memory constrained environments, and to avoid bloating the
size of small applications or libraries using ASM.
ASM is not the only tool for generating and transforming compiled Java
classes, but it is one of the most recent and efficient. It can be downloaded
from http://asm.objectweb.org. Its main advantages are the following:
• It has a simple, well designed and modular API that is easy to use.
• It is well documented and has an associated Eclipse plugin.
• It provides support for the latest Java version, Java 7.
• It is small, fast, and very robust.
• Its large user community can provide support for new users.
• Its open source license allows you to use it in almost any way you want.
1.2. Overview
1.2.1. Scope
The goal of the ASM library is to generate, transform and analyze compiled
Java classes, represented as byte arrays (as they are stored on disk and loaded
in the Java Virtual Machine). For this purpose ASM provides tools to read,
write and transform such byte arrays by using higher level concepts than bytes,
such as numeric constants, strings, Java identifiers, Java types, Java class
structure elements, etc. Note that the scope of the ASM library is strictly
limited to reading, writing, transforming and analyzing classes. In particular
the class loading process is out of scope.
1
the ASM name does not mean anything: it is just a reference to the __asm__ keyword in
C, which allows some functions to be implemented in assembly language.
2
1.2. Overview
1.2.2. Model
The ASM library provides two APIs for generating and transforming compiled
classes: the core API provides an event based representation of classes, while
the tree API provides an object based representation.
With the event based model a class is represented with a sequence of events,
each event representing an element of the class, such as its header, a field, a
method declaration, an instruction, etc. The event based API defines the set
of possible events and the order in which they must occur, and provides a class
parser that generates one event per element that is parsed, as well as a class
writer that generates compiled classes from sequences of such events.
With the object based model a class is represented with a tree of objects, each
object representing a part of the class, such as the class itself, a field, a method,
an instruction, etc. and each object having references to the objects that
represent its constituents. The object based API provides a way to convert
a sequence of events representing a class to the object tree representing the
same class and, vice versa, to convert an object tree to the equivalent event
sequence. In other words the object based API is built on top of the event
based API.
These two APIs can be compared to the Simple API for XML (SAX) and
Document Object Model (DOM) APIs for XML documents: the event based
API is similar to SAX, while the object based API is similar to DOM. The
object based API is built on top of the event based one, like DOM can be
provided on top of SAX.
ASM provides both APIs because there is no best API. Indeed each API has
its own advantages and drawbacks:
• The event based API is faster and requires less memory than the object
based API, since there is no need to create and store in memory a tree
of objects representing the class (the same difference also exists between
SAX and DOM).
• However implementing class transformations can be more difficult with
the event based API, since only one element of the class is available
at any given time (the element that corresponds to the current event),
while the whole class is available in memory with the object based API.
Note that the two APIs manage only one class at a time, and independently
of the others: no information about the class hierarchy is maintained, and if a
3
1. Introduction
class transformation affects other classes, it is up to the user to modify these
other classes.
1.2.3. Architecture
ASM applications have a strong architectural aspect. Indeed the event based
API is organized around event producers (the class parser), event consumers
(the class writer) and various predefined event filters, to which user defined
producers, consumers and filters can be added. Using this API is therefore a
two step process:
• assembling event producer, filter and consumer components into possibly
complex architectures,
• and then starting the event producers to run the generation or transformation process.
The object based API also has an architectural aspect: indeed class generator
or transformer components that operate on object trees can be composed, the
links between them representing the order of transformations.
Although most component architectures in typical ASM applications are quite
simple, it is possible to imagine complex architectures like the following, where
arrows represent event based or object based communications between class
parsers, writers or transformers, with possible conversions between the event
based and object based representations anywhere in the chain:
|
| Java1234官方群25： | 
|
| Java1234官方群25： | 838462530 |
苏公网安备 32061202001004号
