objectbridge-jdo-dev

[Objectbridge-jdo-dev] ojb suitable for jdo implementation

[Sebastian K. <seb...@mu...>]

Hi,

I'm strongly interested in (working on) open-source jdo implementations and 
noticed your project. I took a first look at ojb and wondered about the 
following problem:

If I understood the source code correctly, ojb uses reflection to read/write 
member variables of persistence capable classes. On the other hand, jdo uses 
an explicit interface (PersistenceCapable) implemented automatically by the 
enhancer. My question is: Do you want to keep the "reflection-based" approach 
for your jdo implementation? This would probably lead to problems when 
working with enhanced classes, as they expect a state-manager providing them 
their fields via the the methods defined in the PersistenceCapable (and 
StateManager) interfaces. However, the spec requires binary compatibility 
between jdo implementations, e.g. it has to work with classes enhanced by the 
reference enhancer.

Of course there are other tradeoffs between the reflection-based approach and 
an enhancer-based approach:

- Reflection should be somewhat slower than enhanced classes
- Enhancement is another step in the build process and can make debugging 
difficult
- Enhancement does not require Proxy-generated classes as stubs to load 
objects from the datastore on-demand.

So, to summarize my question: Do you want to keep the reflectio-based 
approach or is a solution possible, where data read from the data store is 
passed to a StateManager instead of directly into the PersistenceCapable 
instance?

ciao Sebastian

-- 
Sebastian Kanthak    |    seb...@mu...

Re: [Objectbridge-jdo-dev] ojb suitable for jdo implementation

[Christian S. <chr...@ne...>]

> - Enhancement is another step in the build process and can make debugging
> difficult

slightly off-topic, but this is one of the statements that one always gets
to hear when the disadvantages of enhancement are discussed. Yet I do not
understand why this should be so. The Java Bytecode and debugger interface
are all well documented, so it should be rather trivial to make the enhanced
bytecode completely transparent with regard to debugging.

regards,
Christian

Re: [Objectbridge-jdo-dev] ojb suitable for jdo implementation

[Sebastian K. <seb...@mu...>]

On Sunday 12 May 2002 16:00, Christian Sell wrote:
> > - Enhancement is another step in the build process and can make debugging
> > difficult
>
> slightly off-topic, but this is one of the statements that one always gets
> to hear when the disadvantages of enhancement are discussed. Yet I do not
> understand why this should be so. The Java Bytecode and debugger interface
> are all well documented, so it should be rather trivial to make the
> enhanced bytecode completely transparent with regard to debugging.

well, of course, the enhancer has to take care, that line-information isn't 
lost, but I guess, that some debuggers have problems when the command to be 
executed is a method call (for example to jdoGetXXX), but the source code is 
a "localVariable = this.persistentMemberVariable". If you now give the normal 
"step" command the debugger will step into a method where he does not expect 
one and that does not exist in the source code. Perhaps "simple debuggers", 
that only rely on the line-numbers work better here, that debuggers that 
analyze the source-code.

However, the jdo spec seems to make pretty clear, that debugging should not 
be a big problem, I only wanted to mention it.

ciao Sebastian

-- 
Sebastian Kanthak    |    seb...@mu...

Re: [Objectbridge-jdo-dev] ojb suitable for jdo implementation

[Thomas M. <tho...@ho...>]

Hi Sebastian,

Sebastian Kanthak wrote:

> Hi,
> 
> I'm strongly interested in (working on) open-source jdo implementations and 
> noticed your project. I took a first look at ojb and wondered about the 
> following problem:
> 
> If I understood the source code correctly, ojb uses reflection to read/write 
> member variables of persistence capable classes. 


OJB provides an Interface PersistentField to encapsulate the field 
access. Currently we provide two implementations, one based on 
reflection, one based on Javabeans property access.
The used implementation is configured in OJB.properties.

> On the other hand, jdo uses 
> an explicit interface (PersistenceCapable) implemented automatically by the 
> enhancer. My question is: Do you want to keep the "reflection-based" approach 
> for your jdo implementation? 


No we will stick 100% to the JDO spec!

> This would probably lead to problems when 
> working with enhanced classes, as they expect a state-manager providing them 
> their fields via the the methods defined in the PersistenceCapable (and 
> StateManager) interfaces. However, the spec requires binary compatibility 
> between jdo implementations, e.g. it has to work with classes enhanced by the 
> reference enhancer.
> 


That's why we have to stick to the spec! Otherwise we won't be JDO 
compliant and won't be able to work with classes enhanced by different 
tools.


> Of course there are other tradeoffs between the reflection-based approach and 
> an enhancer-based approach:
> 
> - Reflection should be somewhat slower than enhanced classes


Right its also slower than the Javabeans compliant approach.


> - Enhancement is another step in the build process and can make debugging 
> difficult
> - Enhancement does not require Proxy-generated classes as stubs to load 
> objects from the datastore on-demand.


Yes, all those infrastructure-stuff can be hidden by the enhancement 
process.


> 
> So, to summarize my question: Do you want to keep the reflectio-based 
> approach 


No! (In fact OJB is already open in this respect)

> or is a solution possible, where data read from the data store is 
> passed to a StateManager instead of directly into the PersistenceCapable 
> instance?
> 


Sure!

cu,

Thomas


> ciao Sebastian
> 
>