Subject:   Byte Code Enhancement vs. Class Mutilation
Date:   2002-12-10 13:36:53
From:   anonymous2
I had the same concerns when I looked at byte code enhancement via JDO for the first time. Then I educated myself.

Byte code is a language specified in the Java language spec. It a very clearly specified language with very specific rules.

Also, you compile your classes don't you? Is that mutilation of your code also?

The positives of byte code enhancement are clear. No line number issues when debugging, no problems using tools like CVS, etc. JDO is extremely lightweight relative to other proprietary and standardized persistence options. Part of this is because of enhancement.

Many of the enhancers used by JDO vendors are open sourced (RI and others). If you are uncomfortable with byte code manipulation see what they are doing.

Finally, JDO doesn't prescribe a byte code enhancer. I beleive there are vendors out there with source code enhancers. If you don't want the so called "mutilation", you can choose not to use a byte code enhancer.

I for one, will happily take the benefits of JDO (30% code reduction, much cleaner code) and byte code enhancement, over the other options.

Full Threads Oldest First

Showing messages 1 through 5 of 5.

  • Byte Code Enhancement vs. Class Mutilation
    2003-06-14 15:47:38  anonymous2 [View]

    Bytecode enhancement (manipulation)

    Open source libraries

    Jakarta Byte Code Engineering Library

    JBoss Javassist
  • Byte Code Enhancement vs. Class Mutilation
    2002-12-10 17:15:09  anonymous2 [View]

    Byte code enhancement, class mutliation, source code enhancement --- it all sounds like a hack job to me. A technically pure JDO implementation would not make any requirements regarding source code changes or class file changes. However, you are right, the benefits do outweigh the hack.
    • Byte Code Enhancement vs. Class Mutilation
      2002-12-11 08:23:55 [View]

      A "technically pure" JDO implementation, as you put it, would rely on JVM-level hooks into the transient object lifecycle which could be used to trigger corresponding events in a persistent object cache.

      When JDO was being scoped such design choices were discussed with the JVM team. The upshot was two-fold:

      1. In the timeframe for releasing JDO, the JVM would not be changed to provide these hooks.

      2. Implementing a custom JVM, which all JDO-based application would then be forced to use, would make JDO "undesirable".

      These were the basis for the current model with its PersistenceCapable interface.

      However, do bear the following in mind.... Neither the application objects (which invoke PersistenceManager services) nor the domain objects (which are persistence-capable) actually depend upon the PersistenceCapable interface. If you are coding against the PersistenceCapable interface then you are doing it wrong (or you're a vendor writing a JDO implementation). That's why PersistenceCapable is in the JDO SPI (javax.jdo.spi) and not the JDO API (javax.jdo).

      This means it is conceivable that, with sufficient direct support from some future JVM, the underpinning mechanism of JDO's transparent persistence could be changed. (There are no plans for this in hand, I'm merely hypothesizing about some futuristic environment.) At that point the current requirement for "bytecode mutilation", as you so objectively term, it would be removed. However, your application and domain object source code would not need to be altered to function correctly in this new environment.

      My point? PersistenceCapable, and the requirement for domain objects to implement it, is an implementation detail of the current internal JDO architecture, and is - at least conceivably - subject to change. Good encapsulation, as exhibited by JDO's external architecture, insulates your classes from any dependency on this implementation detail.

      Kind regards, Robin.
      Robin M. Roos
      • Byte Code Enhancement vs. Class Mutilation
        2002-12-17 05:38:21  markusp [View]

        As you all might be aware of, at least one such custom JVM exist already. Although it currently does not fully support JDO 1.0, GemStone Facets has a HotSpot-derived JVM that doesn't require byte code enhancement (but allows it) for transparent persistence. Drawbacks include that they still only support JDK 1.3.1_something, Win2k and Solaris.