Better Faster Lighter Java [Electronic resources] نسخه متنی

اینجــــا یک کتابخانه دیجیتالی است

با بیش از 100000 منبع الکترونیکی رایگان به زبان فارسی ، عربی و انگلیسی

Better Faster Lighter Java [Electronic resources] - نسخه متنی

Justin Gehtland; Bruce A. Tate

| نمايش فراداده ، افزودن یک نقد و بررسی
افزودن به کتابخانه شخصی
ارسال به دوستان
جستجو در متن کتاب
بیشتر
تنظیمات قلم

فونت

اندازه قلم

+ - پیش فرض

حالت نمایش

روز نیمروز شب
جستجو در لغت نامه
بیشتر
لیست موضوعات
توضیحات
افزودن یادداشت جدید








4.5 Injecting Code


To get better transparency, you

can always automatically generate code and
add it to the model. To date, most frameworks use this approach. Of
course, since most Java developers use Ant to build their projects,
adding a simple code enhancer to your applications is relatively easy
to do with little intrusion on your build process. You can use code
enhancement in two ways:





Source code enhancement


This technique uses a

program to read through your
source code and make additions in the necessary places. For example,
to make code transparent with respect to a performance tool that does
performance profiling, you might run a precompiler program that
injects code that takes a timestamp any time you enter or exit a
method you want to measure.


Byte code enhancement


Since Java programs compile

to a standard compiled form
called byte code, you can inject byte code to add services and still
maintain transparency. For example, most JDO implementations use a
byte code enhancer.



Often, when you inject code, you're actually
injecting methods that perform the work of your intended service, as
with the source code enhancer in Figure 4-6. Source
code enhancement takes a class as an input and then generates code,
typically method calls, to inject service capabilities into code,
completely preserving transparency in the original class.



Figure 4-6. This source code enhancer addslogging to MyClass

JDO enhancers work this way: you create a class
that's transparent with respect to persistence. The
job of the JDO enhancer is to


implement the
PersistenceCapible interface. In order to make the
class persistent, let your build process run it through a JDO
enhancer. (Some of these use source code enhancement but most use
byte code enhancement.) The enhanced class then calls the JDO
framework to actually implement persistence. Some aspect-oriented
programming frameworks use byte code enhancement, as well. The
technique has many benefits:

You don't have to make any changes to source code.

You don't impose any restrictions on your class, so
you completely preserve transparency.

Code injection is fast at runtime. The additional steps occur at
build time, so you pay any performance penalty once, at build time.

This is a build-time technique. If you're using Ant
or something similar, after a one-time change to your build scripts,
you will not need to make other changes to your build process.


For the most part, source code injection works well for techniques
that are easy to parse and inject with simple code. Tasks such as
adding logging, instrumenting code for performance analysis, or
intercepting method calls all work well with a simple code injector.


4.5.1 Byte code enhancement frameworks


Byte code enhancement

is a little more difficult to
pull off. You'll need a strong knowledge of
compilers, the Java byte code specification, and finer issues like
threading. For this reason, most people use byte code enhancement
through other frameworks.

Some developers frown on byte code enhancement. It's
been my experience that fear of the unknown drives this attitude more
than practical experience. Knowledgeable teams can and do build byte
code enhancers for commercial applications. Still, some perceive
disadvantages:

Some fear that byte code enhancement may be difficult to debug. If
you're the type of programmer who needs to see the
Java source for every line of code in your system, byte code
enhancement is not for you. I've generally found
that enhancements are little more than method calls into a services
layer, so it's usually not an issue.

Theoretically, two byte code enhancers applied to one class could
possibly collide, causing some breakage. I haven't
seen this happen in practice. In fact, not many byte code enhancers
exist.


The framework you choose depends on the services you need. JDO uses
code enhancement to add transparent persistence. Some tools that make
understanding decompiled code more
difficult, called
obfuscators, also use byte code enhancement to
help you protect your intellectual property. In addition, some AOP
frameworks enhance byte code at runtime when they load classes.
You'll probably wind up using byte code enhancement
solely through one of these.


/ 111