Women in Technology

Hear us Roar



Subject:   Byte Code Enhancement vs. Class Mutilation
Date:   2002-12-10 17:15:09
From:   anonymous2
Response to: Byte Code Enhancement vs. Class Mutilation

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.
Full Threads Oldest First

Showing messages 1 through 2 of 2.

  • Byte Code Enhancement vs. Class Mutilation
    2002-12-11 08:23:55  robin@ogilviepartners.com [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
    www.OgilviePartners.com
    • 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.

      /Markus