[DISCUSS] Evicting dirty instances

[Craig L Russell]

This topic was raised by Christiaan http://mail-archives.apache.org/ 
mod_mbox/db-jdo-user/200708.mbox/%3c12232225.post@...%3e

Before the JDO spec introduced the concept of application-defined  
flush(), the evict method could be used to make an instance hollow  
and therefore subject to garbage collection.

When we introduced flush(), it became possible for all of the  
application state in the cache to be erased from the cache, leaving  
only the life-cycle state of the instance in memory for future  
reference.

My proposal is to require that the JDO implementation treat flushed  
dirty instances the same as hollow and persistent-nontransactional  
instances, allowing them to be garbage collected. The uniqueness  
guarantee only applies if the application itself holds a strong  
reference to the instance.

This proposal would allow a well-designed program that creates or  
updates a large transaction set of persistent instances to flush  
periodically and not run out of memory.

If an application constructs a large number of instances and flushes  
them, the only artifact remaining in the cache would be the memory  
that the instance was new. That is, if the instance were subsequently  
queried or obtained by id, the instance would still be persistent-new  
although the instance retrieved might be a different Java instance  
from the instance created and flushed.

We could still use the evict method to remove even the memory of the  
life cycle state of the instance. So if the persistent-new instance  
were flushed, it would still be persistent-new, but if it were then  
evicted, it would be subsequently retrieved as a hollow or persistent-
nontransactional instance.

Please comment.

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@...
P.S. A good JDO? O, Gasp!

[Ilan Kirsh]

Hi,

The JDO 2 TCK 2.0 package that is available for download at:
    http://db.apache.org/jdo/releases/release-2.0.cgi
contains many invalid tests that have been fixed since that release.

In order to claim compliance with JDO 2 should I use the tests at:
    http://svn.apache.org/viewvc/db/jdo/trunk/tck2-legacy/ ?

Should I fill CHALLENGE against tests in that set that IMO are invalid?

Thanks,

Ilan Kirsh
ObjectDB Software

[Craig L Russell]

Hi Ilan,

On Sep 25, 2007, at 10:18 AM, Ilan Kirsh wrote:

Hi,

 

The JDO 2 TCK 2.0 package that is available for download at:

    http://db.apache.org/jdo/releases/release-2.0.cgi

contains many invalid tests that have been fixed since that release.

Correct. The latest trunk has updated tests.

 

In order to claim compliance with JDO 2 should I use the tests at:

    http://svn.apache.org/viewvc/db/jdo/trunk/tck2-legacy/ ?

Well, there's no official release of the JDO 2.1 test suite, so probably to claim compliance with JDO 2.0, you should update the exclude list and run the original tests. And you should take a look at the tck2 project as well.

 

Should I fill CHALLENGE against tests in that set that IMO are invalid?

Yes. We still have time to fix these before official release.

 

Thanks,

 

Thank you for your continued support.

Craig

Ilan Kirsh

ObjectDB Software

Craig Russell

Architect, Sun Java Enterprise System http://java.sun.com/products/jdo

408 276-5638 Craig.Russell@...

P.S. A good JDO? O, Gasp!

[Ilan Kirsh]

Is there an approved exclude list for the original JDO 2 TCK 2.0
that is more realistic than the bundled list of 2 enhancement tests?

If not, when ready, I can publish my exclude list as a suggestion.

Regards, Ilan

  ----- Original Message -----
  From: Craig L Russell
  To: JDO Expert Group
  Cc: Apache JDO project
  Sent: Tuesday, September 25, 2007 7:32 PM
  Subject: Re: JDO TCK 2.0 - Which set of tests to use?


  Hi Ilan,




  On Sep 25, 2007, at 10:18 AM, Ilan Kirsh wrote:


    Hi,

    The JDO 2 TCK 2.0 package that is available for download at:
        http://db.apache.org/jdo/releases/release-2.0.cgi
    contains many invalid tests that have been fixed since that release.


  Correct. The latest trunk has updated tests.


    In order to claim compliance with JDO 2 should I use the tests at:
        http://svn.apache.org/viewvc/db/jdo/trunk/tck2-legacy/ ?


  Well, there's no official release of the JDO 2.1 test suite, so probably to claim compliance with JDO 2.0, you should update the exclude list and run the original tests. And you should take a look at the tck2 project as well.


    Should I fill CHALLENGE against tests in that set that IMO are invalid?


  Yes. We still have time to fix these before official release.



    Thanks,



  Thank you for your continued support.


  Craig


    Ilan Kirsh
    ObjectDB Software




  Craig Russell

  Architect, Sun Java Enterprise System http://java.sun.com/products/jdo

  408 276-5638 mailto:Craig.Russell@...

  P.S. A good JDO? O, Gasp!

[Michelle Caisse]

Hi Ilan,

There is a source branch 2.01 with changes responsive to some earlier
challenges. There's a wiki page documenting the issues
http://wiki.apache.org/jdo/TCKChallenges. Please get this branch from
svn and let us know if there are remaining issues.

Thanks,
Michelle

Ilan Kirsh wrote:

> Is there an approved exclude list for the original JDO 2 TCK 2.0
> that is more realistic than the bundled list of 2 enhancement tests?
>
> If not, when ready, I can publish my exclude list as a suggestion.
>
> Regards, Ilan
>
>   ----- Original Message -----
>   From: Craig L Russell
>   To: JDO Expert Group
>   Cc: Apache JDO project
>   Sent: Tuesday, September 25, 2007 7:32 PM
>   Subject: Re: JDO TCK 2.0 - Which set of tests to use?
>
>
>   Hi Ilan,
>
>
>
>
>   On Sep 25, 2007, at 10:18 AM, Ilan Kirsh wrote:
>
>
>     Hi,
>
>     The JDO 2 TCK 2.0 package that is available for download at:
>         http://db.apache.org/jdo/releases/release-2.0.cgi
>     contains many invalid tests that have been fixed since that release.
>
>
>   Correct. The latest trunk has updated tests.
>
>
>     In order to claim compliance with JDO 2 should I use the tests at:
>         http://svn.apache.org/viewvc/db/jdo/trunk/tck2-legacy/ ?
>
>
>   Well, there's no official release of the JDO 2.1 test suite, so probably to claim compliance with JDO 2.0, you should update the exclude list and run the original tests. And you should take a look at the tck2 project as well.
>
>
>     Should I fill CHALLENGE against tests in that set that IMO are invalid?
>
>
>   Yes. We still have time to fix these before official release.
>
>
>
>     Thanks,
>
>
>
>   Thank you for your continued support.
>
>
>   Craig
>
>
>     Ilan Kirsh
>     ObjectDB Software
>
>
>
>
>   Craig Russell
>
>   Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
>
>   408 276-5638 mailto:Craig.Russell@...
>
>   P.S. A good JDO? O, Gasp!
>
>
>
>  

[Ilan Kirsh]

Hi Michelle,

That was very helpful. Running this branch looks much better.

Still I have problems with the following tests:

    1. FetchPlanInterface.testGroups (fixed in JDO-402, after 2.0.1?)
    2. ResultClassRequirements.testNegative  (fixed in JDO-524)
    3. ChangeQuery.testPositive (fixed in JDO-529)
    4. ImplicitParameters.testGrouping (fixed in JDO-530)
    5. StateTransitionsReturnedObjects (JDO-513, JDO-514).

Please advise.

Thanks, Ilan


----- Original Message -----
From: "Michelle Caisse" <Michelle.Caisse@...>
To: <jdo-dev@...>
Cc: "JDO Expert Group" <jdo-experts-ext@...>
Sent: Tuesday, September 25, 2007 8:46 PM
Subject: Re: JDO TCK 2.0 - Which set of tests to use?

> Hi Ilan,
>
> There is a source branch 2.01 with changes responsive to some earlier
> challenges. There's a wiki page documenting the issues
> http://wiki.apache.org/jdo/TCKChallenges. Please get this branch from svn
> and let us know if there are remaining issues.
>
> Thanks,
> Michelle
>
> Ilan Kirsh wrote:
>> Is there an approved exclude list for the original JDO 2 TCK 2.0
>> that is more realistic than the bundled list of 2 enhancement tests?
>>
>> If not, when ready, I can publish my exclude list as a suggestion.
>>
>> Regards, Ilan
>>
>>   ----- Original Message -----
>>   From: Craig L Russell To: JDO Expert Group Cc: Apache JDO project Sent:
>> Tuesday, September 25, 2007 7:32 PM
>>   Subject: Re: JDO TCK 2.0 - Which set of tests to use?
>>
>>
>>   Hi Ilan,
>>
>>
>>
>>
>>   On Sep 25, 2007, at 10:18 AM, Ilan Kirsh wrote:
>>
>>
>>     Hi,
>>
>>     The JDO 2 TCK 2.0 package that is available for download at:
>>         http://db.apache.org/jdo/releases/release-2.0.cgi
>>     contains many invalid tests that have been fixed since that release.
>>
>>
>>   Correct. The latest trunk has updated tests.
>>
>>
>>     In order to claim compliance with JDO 2 should I use the tests at:
>>         http://svn.apache.org/viewvc/db/jdo/trunk/tck2-legacy/ ?
>>
>>
>>   Well, there's no official release of the JDO 2.1 test suite, so
>> probably to claim compliance with JDO 2.0, you should update the exclude
>> list and run the original tests. And you should take a look at the tck2
>> project as well.
>>
>>
>>     Should I fill CHALLENGE against tests in that set that IMO are
>> invalid?
>>
>>
>>   Yes. We still have time to fix these before official release.
>>
>>
>>
>>     Thanks,
>>
>>
>>
>>   Thank you for your continued support.
>>
>>
>>   Craig
>>
>>
>>     Ilan Kirsh
>>     ObjectDB Software
>>
>>
>>
>>
>>   Craig Russell
>>
>>   Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
>>
>>   408 276-5638 mailto:Craig.Russell@...
>>
>>   P.S. A good JDO? O, Gasp!
>>
>>
>>
>>
>

[Michelle Caisse]

You'll have to enter a challenge on those and we'll back port the
changes to a 2.0.x branch or add the test to the exclude list.
To initiate a challenge "send email to: jdo-dev@...
<mailto:jdo-dev@...> with a subject line containing
"CHALLENGE" and the name of the test program, e.g.
org.apache.jdo.tck.api.persistencemanager.ThreadSafe.java; and the body
of the email containing the details of the challenge." You can just
reference the JIRAs for the details.

Thanks,
Michelle

Ilan Kirsh wrote:

> Hi Michelle,
>
> That was very helpful. Running this branch looks much better.
>
> Still I have problems with the following tests:
>
>    1. FetchPlanInterface.testGroups (fixed in JDO-402, after 2.0.1?)
>    2. ResultClassRequirements.testNegative  (fixed in JDO-524)
>    3. ChangeQuery.testPositive (fixed in JDO-529)
>    4. ImplicitParameters.testGrouping (fixed in JDO-530)
>    5. StateTransitionsReturnedObjects (JDO-513, JDO-514).
>
> Please advise.
>
> Thanks, Ilan
>
>
> ----- Original Message ----- From: "Michelle Caisse"
> <Michelle.Caisse@...>
> To: <jdo-dev@...>
> Cc: "JDO Expert Group" <jdo-experts-ext@...>
> Sent: Tuesday, September 25, 2007 8:46 PM
> Subject: Re: JDO TCK 2.0 - Which set of tests to use?
>
>
>> Hi Ilan,
>>
>> There is a source branch 2.01 with changes responsive to some earlier
>> challenges. There's a wiki page documenting the issues
>> http://wiki.apache.org/jdo/TCKChallenges. Please get this branch from
>> svn
>> and let us know if there are remaining issues.
>>
>> Thanks,
>> Michelle
>>
>> Ilan Kirsh wrote:
>>> Is there an approved exclude list for the original JDO 2 TCK 2.0
>>> that is more realistic than the bundled list of 2 enhancement tests?
>>>
>>> If not, when ready, I can publish my exclude list as a suggestion.
>>>
>>> Regards, Ilan
>>>
>>>   ----- Original Message -----   From: Craig L Russell To: JDO
>>> Expert Group Cc: Apache JDO project Sent:
>>> Tuesday, September 25, 2007 7:32 PM
>>>   Subject: Re: JDO TCK 2.0 - Which set of tests to use?
>>>
>>>
>>>   Hi Ilan,
>>>
>>>
>>>
>>>
>>>   On Sep 25, 2007, at 10:18 AM, Ilan Kirsh wrote:
>>>
>>>
>>>     Hi,
>>>
>>>     The JDO 2 TCK 2.0 package that is available for download at:
>>>         http://db.apache.org/jdo/releases/release-2.0.cgi
>>>     contains many invalid tests that have been fixed since that
>>> release.
>>>
>>>
>>>   Correct. The latest trunk has updated tests.
>>>
>>>
>>>     In order to claim compliance with JDO 2 should I use the tests at:
>>>         http://svn.apache.org/viewvc/db/jdo/trunk/tck2-legacy/ ?
>>>
>>>
>>>   Well, there's no official release of the JDO 2.1 test suite, so
>>> probably to claim compliance with JDO 2.0, you should update the
>>> exclude
>>> list and run the original tests. And you should take a look at the tck2
>>> project as well.
>>>
>>>
>>>     Should I fill CHALLENGE against tests in that set that IMO are
>>> invalid?
>>>
>>>
>>>   Yes. We still have time to fix these before official release.
>>>
>>>
>>>
>>>     Thanks,
>>>
>>>
>>>
>>>   Thank you for your continued support.
>>>
>>>
>>>   Craig
>>>
>>>
>>>     Ilan Kirsh
>>>     ObjectDB Software
>>>
>>>
>>>
>>>
>>>   Craig Russell
>>>
>>>   Architect, Sun Java Enterprise System
>>> http://java.sun.com/products/jdo
>>>
>>>   408 276-5638 mailto:Craig.Russell@...
>>>
>>>   P.S. A good JDO? O, Gasp!
>>>
>>>
>>>
>>>
>>
>
>

[Ilan Kirsh]

I wonder where in the spec persistence capable interfaces and persistence capable abstract classes are discussed.
I have the Java Data Objects 2.1 specification draft from 13 June 2007, and it seems that relevant sections (e.g. chapter 6)  ignore this issue.

Ilan

[Craig L Russell]

Hi Ilan,

You could start with the pm.newInstance method in 12.6.6 that is the way to instantiate the instances, and then look at the metadata descriptions in 18.5.

Craig

On Sep 26, 2007, at 2:46 AM, Ilan Kirsh wrote:

I wonder where in the spec persistence capable interfaces and persistence capable abstract classes are discussed.

I have the Java Data Objects 2.1 specification draft from 13 June 2007, and it seems that relevant sections (e.g. chapter 6)  ignore this issue.

 

Ilan

 

Craig Russell

Architect, Sun Java Enterprise System http://java.sun.com/products/jdo

408 276-5638 Craig.Russell@...

P.S. A good JDO? O, Gasp!

[Michelle Caisse]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Hi Ilan,

It looks like there are 49 cases in which this test is not finding the expected method signature in your implementation. Within this group, there are three cases.

- There are 26 instances in which the impl declares a method abstract and the test expects a concrete method.

- There are 21 cases where the test finds a fully qualified method name and is expecting an unqualified name, as in:
--- missing constructor:
    expected: public  .JDOCanRetryException(java.lang.String, java.lang.Throwable[], java.lang.Object)
    class:    public class javax.jdo.JDOCanRetryException extends javax.jdo.JDOException
--- non-standard, public member;
    found:    public javax.jdo.JDOCanRetryException(java.lang.String, java.lang.Throwable[], java.lang.Object)
    class:    public class javax.jdo.JDOCanRetryException extends javax.jdo.JDOException

- There are 2 cases involving the static keyword where there is no difference between the expected and found.
--- missing method:
    expected: public static java.lang.Object[] getObjectIds(java.lang.Object[])
    class:    public class javax.jdo.JDOHelper extends java.lang.Object
--- non-standard, public member;
    found:    public static java.lang.Object[] getObjectIds(java.lang.Object[])
    class:    public class javax.jdo.JDOHelper extends java.lang.Object

The first case looks like an implementation issue, the last a test issue. There are also 6 different ClassNotFoundExceptions that look like a test issue. Perhaps Martin or Craig could take a look at the test.  I've attached some output files that are easier to read than the original.

-- Michelle

Ilan Kirsh wrote:

Hi Michelle,

 

I also need help with test app-runonce. Probably something in my test environment is not configured well to pass this test, but I have no idea what is it.

Attached the jdo jar file that I am using and the output of that test. Any clue?

 

Regards, Ilan

 

    expected: public void evictAll(java.lang.Object[])
    expected: public void pinAll(java.lang.Object[])
    expected: public void unpinAll(java.lang.Object[])
    expected: public javax.jdo.FetchPlan setGroups(java.lang.String[])
    expected: public javax.jdo.FetchPlan setDetachmentRootClasses(java.lang.Class[])
    expected: public  .JDOCanRetryException(java.lang.String, java.lang.Throwable[])
    expected: public  .JDOCanRetryException(java.lang.String, java.lang.Throwable[], java.lang.Object)
    expected: public  .JDODataStoreException(java.lang.String, java.lang.Throwable[])
    expected: public  .JDODataStoreException(java.lang.String, java.lang.Throwable[], java.lang.Object)
    expected: public  .JDODetachedFieldAccessException(java.lang.String, java.lang.Throwable[])
    expected: public  .JDOException(java.lang.String, java.lang.Throwable[])
    expected: public  .JDOException(java.lang.String, java.lang.Throwable[], java.lang.Object)
    expected: public  .JDOFatalDataStoreException(java.lang.String, java.lang.Throwable[])
    expected: public  .JDOFatalException(java.lang.String, java.lang.Throwable[])
    expected: public  .JDOFatalException(java.lang.String, java.lang.Throwable[], java.lang.Object)
    expected: public  .JDOFatalInternalException(java.lang.String, java.lang.Throwable[])
    expected: public  .JDOFatalUserException(java.lang.String, java.lang.Throwable[])
    expected: public  .JDOFatalUserException(java.lang.String, java.lang.Throwable[], java.lang.Object)
    expected: public static java.lang.Object[] getObjectIds(java.lang.Object[])
    expected: public  .JDONullIdentityException(java.lang.String, java.lang.Throwable[])
    expected: public  .JDOObjectNotFoundException(java.lang.String, java.lang.Throwable[])
    expected: public  .JDOOptimisticVerificationException(java.lang.String, java.lang.Throwable[])
    expected: public  .JDOUnsupportedOptionException(java.lang.String, java.lang.Throwable[])
    expected: public  .JDOUserCallbackException(java.lang.String, java.lang.Throwable[])
    expected: public  .JDOUserException(java.lang.String, java.lang.Throwable[])
    expected: public  .JDOUserException(java.lang.String, java.lang.Throwable[], java.lang.Object)
    expected: public void evictAll(java.lang.Object[])
    expected: public void refreshAll(java.lang.Object[])
    expected: public java.lang.Object[] getObjectsById(java.lang.Object[], boolean)
    expected: public java.lang.Object[] getObjectsById(java.lang.Object[])
    expected: public java.lang.Object[] makePersistentAll(java.lang.Object[])
    expected: public void deletePersistentAll(java.lang.Object[])
    expected: public void makeTransientAll(java.lang.Object[])
    expected: public void makeTransientAll(java.lang.Object[], boolean)
    expected: public void makeTransactionalAll(java.lang.Object[])
    expected: public void makeNontransactionalAll(java.lang.Object[])
    expected: public void retrieveAll(java.lang.Object[])
    expected: public void retrieveAll(java.lang.Object[], boolean)
    expected: public java.lang.Object[] detachCopyAll(java.lang.Object[])
    expected: public void addInstanceLifecycleListener(javax.jdo.listener.InstanceLifecycleListener, java.lang.Class[])
    expected: public void addInstanceLifecycleListener(javax.jdo.listener.InstanceLifecycleListener, java.lang.Class[])
    expected: public java.lang.Object executeWithArray(java.lang.Object[])
    expected: public long deletePersistentAll(java.lang.Object[])
    expected: public static void registerClass(java.lang.Class, java.lang.String[], java.lang.Class[], byte[], java.lang.Class, javax.jdo.spi.PersistenceCapable)
    expected: public void jdoProvideFields(int[])
    expected: public void jdoReplaceFields(int[])
    expected: public void jdoCopyFields(java.lang.Object, int[])
    expected: public  .RegisterClassEvent(javax.jdo.spi.JDOImplHelper, java.lang.Class, java.lang.String[], java.lang.Class[], byte[], java.lang.Class)
    expected: public java.lang.Object[] replacingDetachedState(javax.jdo.spi.Detachable, java.lang.Object[])

    found:    public abstract void evictAll(java.lang.Object[])
    found:    public abstract void pinAll(java.lang.Object[])
    found:    public abstract void unpinAll(java.lang.Object[])
    found:    public abstract javax.jdo.FetchPlan setGroups(java.lang.String[])
    found:    public abstract javax.jdo.FetchPlan setDetachmentRootClasses(java.lang.Class[])
    found:    public javax.jdo.JDOCanRetryException(java.lang.String, java.lang.Throwable[], java.lang.Object)
    found:    public javax.jdo.JDOCanRetryException(java.lang.String, java.lang.Throwable[])
    found:    public javax.jdo.JDODataStoreException(java.lang.String, java.lang.Throwable[], java.lang.Object)
    found:    public javax.jdo.JDODataStoreException(java.lang.String, java.lang.Throwable[])
    found:    public javax.jdo.JDODetachedFieldAccessException(java.lang.String, java.lang.Throwable[])
    found:    public javax.jdo.JDOException(java.lang.String, java.lang.Throwable[], java.lang.Object)
    found:    public javax.jdo.JDOException(java.lang.String, java.lang.Throwable[])
    found:    public javax.jdo.JDOFatalDataStoreException(java.lang.String, java.lang.Throwable[])
    found:    public javax.jdo.JDOFatalException(java.lang.String, java.lang.Throwable[], java.lang.Object)
    found:    public javax.jdo.JDOFatalException(java.lang.String, java.lang.Throwable[])
    found:    public javax.jdo.JDOFatalInternalException(java.lang.String, java.lang.Throwable[])
    found:    public javax.jdo.JDOFatalUserException(java.lang.String, java.lang.Throwable[], java.lang.Object)
    found:    public javax.jdo.JDOFatalUserException(java.lang.String, java.lang.Throwable[])
    found:    public static java.lang.Object[] getObjectIds(java.lang.Object[])
    found:    public javax.jdo.JDONullIdentityException(java.lang.String, java.lang.Throwable[])
    found:    public javax.jdo.JDOObjectNotFoundException(java.lang.String, java.lang.Throwable[])
    found:    public javax.jdo.JDOOptimisticVerificationException(java.lang.String, java.lang.Throwable[])
    found:    public javax.jdo.JDOUnsupportedOptionException(java.lang.String, java.lang.Throwable[])
    found:    public javax.jdo.JDOUserCallbackException(java.lang.String, java.lang.Throwable[])
    found:    public javax.jdo.JDOUserException(java.lang.String, java.lang.Throwable[], java.lang.Object)
    found:    public javax.jdo.JDOUserException(java.lang.String, java.lang.Throwable[])
    found:    public abstract void makeTransactionalAll(java.lang.Object[])
    found:    public abstract java.lang.Object[] detachCopyAll(java.lang.Object[])
    found:    public abstract void deletePersistentAll(java.lang.Object[])
    found:    public abstract void refreshAll(java.lang.Object[])
    found:    public abstract java.lang.Object[] makePersistentAll(java.lang.Object[])
    found:    public abstract void addInstanceLifecycleListener(javax.jdo.listener.InstanceLifecycleListener, java.lang.Class[])
    found:    public abstract void makeNontransactionalAll(java.lang.Object[])
    found:    public abstract java.lang.Object[] getObjectsById(java.lang.Object[])
    found:    public abstract java.lang.Object[] getObjectsById(java.lang.Object[], boolean)
    found:    public abstract void evictAll(java.lang.Object[])
    found:    public abstract void makeTransientAll(java.lang.Object[], boolean)
    found:    public abstract void makeTransientAll(java.lang.Object[])
    found:    public abstract void retrieveAll(java.lang.Object[])
    found:    public abstract void retrieveAll(java.lang.Object[], boolean)
    found:    public abstract void addInstanceLifecycleListener(javax.jdo.listener.InstanceLifecycleListener, java.lang.Class[])
    found:    public abstract long deletePersistentAll(java.lang.Object[])
    found:    public abstract java.lang.Object executeWithArray(java.lang.Object[])
    found:    public static void registerClass(java.lang.Class, java.lang.String[], java.lang.Class[], byte[], java.lang.Class, javax.jdo.spi.PersistenceCapable)
    found:    public abstract void jdoReplaceFields(int[])
    found:    public abstract void jdoCopyFields(java.lang.Object, int[])
    found:    public abstract void jdoProvideFields(int[])
    found:    public javax.jdo.spi.RegisterClassEvent(javax.jdo.spi.JDOImplHelper, java.lang.Class, java.lang.String[], java.lang.Class[], byte[], java.lang.Class)
    found:    public abstract java.lang.Object[] replacingDetachedState(javax.jdo.spi.Detachable, java.lang.Object[])

    caught: java.lang.ClassNotFoundException: [B
    caught: java.lang.ClassNotFoundException: [I
    caught: java.lang.ClassNotFoundException: [Ljava.lang.Class;
    caught: java.lang.ClassNotFoundException: [Ljava.lang.Object;
    caught: java.lang.ClassNotFoundException: [Ljava.lang.String;
    caught: java.lang.ClassNotFoundException: [Ljava.lang.Throwable;

[Ilan Kirsh]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Thanks. It might be appropriate to mention persistent interfaces also in chapter 6.

 

Ilan

----- Original Message -----

From: Craig.Russell@...

To: kirsh@...

Cc: jdo-dev@... ; jdo-experts-ext@...

Sent: Wednesday, September 26, 2007 6:00 PM

Subject: Re: Persistence Capable Interfaces and Abstract Classes

Hi Ilan,

You could start with the pm.newInstance method in 12.6.6 that is the way to instantiate the instances, and then look at the metadata descriptions in 18.5.

Craig

On Sep 26, 2007, at 2:46 AM, Ilan Kirsh wrote:

I wonder where in the spec persistence capable interfaces and persistence capable abstract classes are discussed.

I have the Java Data Objects 2.1 specification draft from 13 June 2007, and it seems that relevant sections (e.g. chapter 6)  ignore this issue.

 

Ilan

 

Craig Russell

Architect, Sun Java Enterprise System http://java.sun.com/products/jdo

408 276-5638 Craig.Russell@...

P.S. A good JDO? O, Gasp!

[Craig L Russell]

Hi Ilan,

Good point. Persistent interfaces is on my list to discuss in the spec, and I'll add Abstract Classes as a topic in the same light.

Craig

On Sep 27, 2007, at 2:55 PM, Ilan Kirsh wrote:

Thanks. It might be appropriate to mention persistent interfaces also in chapter 6.

 

Ilan

----- Original Message -----

From: Craig.Russell@...

To: kirsh@...

Cc: jdo-dev@... ; jdo-experts-ext@...

Sent: Wednesday, September 26, 2007 6:00 PM

Subject: Re: Persistence Capable Interfaces and Abstract Classes

Hi Ilan,

You could start with the pm.newInstance method in 12.6.6 that is the way to instantiate the instances, and then look at the metadata descriptions in 18.5.

Craig

On Sep 26, 2007, at 2:46 AM, Ilan Kirsh wrote:

I wonder where in the spec persistence capable interfaces and persistence capable abstract classes are discussed.

I have the Java Data Objects 2.1 specification draft from 13 June 2007, and it seems that relevant sections (e.g. chapter 6)  ignore this issue.

 

Ilan

 

Craig Russell

Architect, Sun Java Enterprise System http://java.sun.com/products/jdo

408 276-5638 Craig.Russell@...

P.S. A good JDO? O, Gasp!

Craig Russell

Architect, Sun Java Enterprise System http://java.sun.com/products/jdo

408 276-5638 Craig.Russell@...

P.S. A good JDO? O, Gasp!

[cbeams]

As we continue considering what Persistent Interfaces are really all  
about in the 2.1 timeline, let me reiterate my original need /  
expectation with this:

If I have a PC class MyPerson that implements persistent interface  
Person:

        public class Person {}
        public class MyPerson implements Person {}


I expect that I should be able to query by the person interface and  
retrieve all persistent instances of objects assignable to that  
interface:

        List<Person> people = (List<Person>) pm.newQuery
(Person.class).execute();

Note here that I'm not using an Extent.  Typically, to return  
subtypes, we would need to do something like:

        pm.newQuery(new Extent(Person.class, true)); //...

However, this makes no sense when the type in question is an  
interface.  Thus I propose that queries taking interfaces as  
parameters implicitly return all implementing persistent instances.

I believe that this scenario represents the most basic, intuitive  
kind of use case possible when dealing with interfaces.  And, it is  
currently not supported.

Note that what I'm talking about here does not take into account any  
of the support for implementation generation (pm.newInstance()),  
etc..  I consider all that functionality, while perhaps useful, to be  
much more advanced.

Thanks,

- Chris

Chris Beams


On Sep 27, 2007, at 2:55 PM, Ilan Kirsh wrote:

> Thanks. It might be appropriate to mention persistent interfaces  
> also in chapter 6.
>
> Ilan
> ----- Original Message -----
> From: Craig L Russell
> To: Ilan Kirsh
> Cc: jdo-dev@... ; JDO Expert Group
> Sent: Wednesday, September 26, 2007 6:00 PM
> Subject: Re: Persistence Capable Interfaces and Abstract Classes
>
> Hi Ilan,
>
> You could start with the pm.newInstance method in 12.6.6 that is  
> the way to instantiate the instances, and then look at the metadata  
> descriptions in 18.5.
>
> Craig
>
> On Sep 26, 2007, at 2:46 AM, Ilan Kirsh wrote:
>
>> I wonder where in the spec persistence capable interfaces and  
>> persistence capable abstract classes are discussed.
>> I have the Java Data Objects 2.1 specification draft from 13 June  
>> 2007, and it seems that relevant sections (e.g. chapter 6)  ignore  
>> this issue.
>>
>> Ilan
>>
>>
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@...
> P.S. A good JDO? O, Gasp!
>
>

[Ilan Kirsh]

Hi Chris,

Actually you need to use Extent to exclude subclasses. To include subclasses
you can use a candidate class, as described in section 14.6:

If the candidates are not specified explicitly by newQuery,
setCandidates(Collection), or setCandidates(Extent), then the candidate
extent is the extent of instances of the candidate class in the datastore
including subclasses. That is, the candidates are the result of
getPersistenceManager().getExtent(candidateClass, true).

Regards, Ilan

----- Original Message -----
From: "cbeams" <cbeams@...>
To: <jdo-dev@...>
Cc: "Craig L Russell" <Craig.Russell@...>; "JDO Expert Group"
<jdo-experts-ext@...>
Sent: Friday, September 28, 2007 1:35 AM
Subject: Re: Persistence Capable Interfaces and Abstract Classes

> As we continue considering what Persistent Interfaces are really all
> about in the 2.1 timeline, let me reiterate my original need /
> expectation with this:
>
> If I have a PC class MyPerson that implements persistent interface
> Person:
>
> public class Person {}
> public class MyPerson implements Person {}
>
>
> I expect that I should be able to query by the person interface and
> retrieve all persistent instances of objects assignable to that
> interface:
>
> List<Person> people = (List<Person>) pm.newQuery
> (Person.class).execute();
>
> Note here that I'm not using an Extent.  Typically, to return
> subtypes, we would need to do something like:
>
> pm.newQuery(new Extent(Person.class, true)); //...
>
> However, this makes no sense when the type in question is an
> interface.  Thus I propose that queries taking interfaces as
> parameters implicitly return all implementing persistent instances.
>
> I believe that this scenario represents the most basic, intuitive
> kind of use case possible when dealing with interfaces.  And, it is
> currently not supported.
>
> Note that what I'm talking about here does not take into account any
> of the support for implementation generation (pm.newInstance()),
> etc..  I consider all that functionality, while perhaps useful, to be
> much more advanced.
>
> Thanks,
>
> - Chris
>
> Chris Beams
>
>
> On Sep 27, 2007, at 2:55 PM, Ilan Kirsh wrote:
>
>> Thanks. It might be appropriate to mention persistent interfaces
>> also in chapter 6.
>>
>> Ilan
>> ----- Original Message -----
>> From: Craig L Russell
>> To: Ilan Kirsh
>> Cc: jdo-dev@... ; JDO Expert Group
>> Sent: Wednesday, September 26, 2007 6:00 PM
>> Subject: Re: Persistence Capable Interfaces and Abstract Classes
>>
>> Hi Ilan,
>>
>> You could start with the pm.newInstance method in 12.6.6 that is
>> the way to instantiate the instances, and then look at the metadata
>> descriptions in 18.5.
>>
>> Craig
>>
>> On Sep 26, 2007, at 2:46 AM, Ilan Kirsh wrote:
>>
>>> I wonder where in the spec persistence capable interfaces and
>>> persistence capable abstract classes are discussed.
>>> I have the Java Data Objects 2.1 specification draft from 13 June
>>> 2007, and it seems that relevant sections (e.g. chapter 6)  ignore
>>> this issue.
>>>
>>> Ilan
>>>
>>>
>>
>> Craig Russell
>> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
>> 408 276-5638 mailto:Craig.Russell@...
>> P.S. A good JDO? O, Gasp!
>>
>>
>
>

[cbeams]

Okay, thanks.  At any rate, I want this simple functionality from  
newQuery(Type.class) where Type is a PC interface.  Hope this makes  
sense.

- Chris

On Sep 27, 2007, at 5:19 PM, Ilan Kirsh wrote:

> Hi Chris,
>
> Actually you need to use Extent to exclude subclasses. To include  
> subclasses
> you can use a candidate class, as described in section 14.6:
>
> If the candidates are not specified explicitly by newQuery,
> setCandidates(Collection), or setCandidates(Extent), then the  
> candidate
> extent is the extent of instances of the candidate class in the  
> datastore
> including subclasses. That is, the candidates are the result of
> getPersistenceManager().getExtent(candidateClass, true).
>
> Regards, Ilan
>
> ----- Original Message ----- From: "cbeams" <cbeams@...>
> To: <jdo-dev@...>
> Cc: "Craig L Russell" <Craig.Russell@...>; "JDO Expert Group"
> <jdo-experts-ext@...>
> Sent: Friday, September 28, 2007 1:35 AM
> Subject: Re: Persistence Capable Interfaces and Abstract Classes
>
>
>> As we continue considering what Persistent Interfaces are really all
>> about in the 2.1 timeline, let me reiterate my original need /
>> expectation with this:
>>
>> If I have a PC class MyPerson that implements persistent interface
>> Person:
>>
>> public class Person {}
>> public class MyPerson implements Person {}
>>
>>
>> I expect that I should be able to query by the person interface and
>> retrieve all persistent instances of objects assignable to that
>> interface:
>>
>> List<Person> people = (List<Person>) pm.newQuery
>> (Person.class).execute();
>>
>> Note here that I'm not using an Extent.  Typically, to return
>> subtypes, we would need to do something like:
>>
>> pm.newQuery(new Extent(Person.class, true)); //...
>>
>> However, this makes no sense when the type in question is an
>> interface.  Thus I propose that queries taking interfaces as
>> parameters implicitly return all implementing persistent instances.
>>
>> I believe that this scenario represents the most basic, intuitive
>> kind of use case possible when dealing with interfaces.  And, it is
>> currently not supported.
>>
>> Note that what I'm talking about here does not take into account any
>> of the support for implementation generation (pm.newInstance()),
>> etc..  I consider all that functionality, while perhaps useful, to be
>> much more advanced.
>>
>> Thanks,
>>
>> - Chris
>>
>> Chris Beams
>>
>>
>> On Sep 27, 2007, at 2:55 PM, Ilan Kirsh wrote:
>>
>>> Thanks. It might be appropriate to mention persistent interfaces
>>> also in chapter 6.
>>>
>>> Ilan
>>> ----- Original Message -----
>>> From: Craig L Russell
>>> To: Ilan Kirsh
>>> Cc: jdo-dev@... ; JDO Expert Group
>>> Sent: Wednesday, September 26, 2007 6:00 PM
>>> Subject: Re: Persistence Capable Interfaces and Abstract Classes
>>>
>>> Hi Ilan,
>>>
>>> You could start with the pm.newInstance method in 12.6.6 that is
>>> the way to instantiate the instances, and then look at the metadata
>>> descriptions in 18.5.
>>>
>>> Craig
>>>
>>> On Sep 26, 2007, at 2:46 AM, Ilan Kirsh wrote:
>>>
>>>> I wonder where in the spec persistence capable interfaces and
>>>> persistence capable abstract classes are discussed.
>>>> I have the Java Data Objects 2.1 specification draft from 13 June
>>>> 2007, and it seems that relevant sections (e.g. chapter 6)  ignore
>>>> this issue.
>>>>
>>>> Ilan
>>>>
>>>>
>>>
>>> Craig Russell
>>> Architect, Sun Java Enterprise System http://java.sun.com/ 
>>> products/jdo
>>> 408 276-5638 mailto:Craig.Russell@...
>>> P.S. A good JDO? O, Gasp!
>>>
>>>
>>
>>
>
>

[Ilan Kirsh]

Hi,

The 'Implements' annotation (and the equivalent XML element) remind me
the 'persistence-capable-superclass' XML attribute that is deprecated now.

If persistence capable interfaces are marked as such by annotations
(or in the XML metadata), why should we have this duplication?

Implementations should be able to find implemented persistence capable
interfaces as they find a super persistence capable class.

Ilan Kirsh
ObjectDB Software
http://www.objectdb.com

[Ilan Kirsh]

Hi Erik,

You are right that without the Implements annotation / element, a few more
interfaces will have to be loaded by the implementation (at least during
enhancement), but is it really an issue? By the way, with
'persistence-capable-superclass' you could also avoid loading the non
persistence capable super class going directly to the first persistence
capable super class.

However, because duplication in development is very bad, and the extra
processing time is negligible - I suggest to deprecate Implements.

Craig, should I update the JIRA?

Ilan

----- Original Message -----
From: "Erik Bengtson" <erik@...>
To: "Ilan Kirsh" <kirsh@...>
Sent: Saturday, October 06, 2007 8:05 PM
Subject: Re: 'Implements' annotation and XML element

>I mean in super pc you have a 1-1 association, and by the moment you need
>to know the super pc class, you have already loaded the pc class, while
>implements has a 1-N, where N is not a fixed number
> --   BlackBerry® from Mobistar    ---
>
> -----Original Message-----
> From: "Erik Bengtson" <erik@...>
>
> Date: Sat, 6 Oct 2007 17:53:12
> To:"Ilan Kirsh" <kirsh@...>
> Subject: Re: 'Implements' annotation and XML element
>
>
> I think the utility is go cases where classes have not been loaded.
> Example: schema creation does not need to load all pc classes to discover
> which ones implements the interface, but only those declared.
>
> While super pc class is used for discovery in bottom-up(child pc->super),
> implements is top-down (interface->classes)
> --   BlackBerry® from Mobistar    ---
>
> -----Original Message-----
> From: Ilan Kirsh <kirsh@...>
>
> Date: Sat, 06 Oct 2007 19:17:42
> To:JDO Expert Group <jdo-experts-ext@...>
> Subject: Fw: 'Implements' annotation and XML element
>
>
> Sent again, now to jdo-experts-ext@...
>
> ----- Original Message -----
> From: "Ilan Kirsh" <kirsh@...>
> To: <jdo-dev@...>
> Sent: Friday, October 05, 2007 1:15 AM
> Subject: 'Implements' annotation and XML element
>
>
> Hi,
>
> The 'Implements' annotation (and the equivalent XML element) remind me
> the 'persistence-capable-superclass' XML attribute that is deprecated now.
>
> If persistence capable interfaces are marked as such by annotations
> (or in the XML metadata), why should we have this duplication?
>
> Implementations should be able to find implemented persistence capable
> interfaces as they find a super persistence capable class.
>
> Ilan Kirsh
> ObjectDB Software
> http://www.objectdb.com
>
>
>
>
>

[Ilan Kirsh]

But the same problem exists also when querying a persistent class. In
ObjectDB only classes that already have persistent instances in the database
are checked. I assume that ORM implementations also check only classes that
are already in use rather than scanning the entire classpath.

Also, we can restrict the automatic search to one level, i.e. if a
persistent interface is implemented by a non persistent class or extended by
a non persistent interface - it will not be considered by JDO as implemented
by subclasses and sub interfaces of these classes and interfaces, unless
implements is specified explicitly again at their level.


----- Original Message -----
From: "Erik Bengtson" <erik@...>
To: "Ilan Kirsh" <kirsh@...>
Sent: Saturday, October 06, 2007 8:49 PM
Subject: Re: 'Implements' annotation and XML element

> Not only cpu, but also memory costly solution if implements gets
> deprecated, since you have to identify the implementations of a pc
> interface by analysing all classes in jdo search path. Also not only
> before enhancement but at runtime, like before evaluating a jdoql
> --   BlackBerry® from Mobistar    ---
>
> -----Original Message-----
> From: Ilan Kirsh <kirsh@...>
>
> Date: Sat, 06 Oct 2007 20:22:06
> To:JDO Expert Group <jdo-experts-ext@...>, jdo-dev@...
> Cc:erik@...
> Subject: Re: 'Implements' annotation and XML element
>
>
> Hi Erik,
>
> You are right that without the Implements annotation / element, a few more
> interfaces will have to be loaded by the implementation (at least during
> enhancement), but is it really an issue? By the way, with
> 'persistence-capable-superclass' you could also avoid loading the non
> persistence capable super class going directly to the first persistence
> capable super class.
>
> However, because duplication in development is very bad, and the extra
> processing time is negligible - I suggest to deprecate Implements.
>
> Craig, should I update the JIRA?
>
> Ilan
>
> ----- Original Message -----
> From: "Erik Bengtson" <erik@...>
> To: "Ilan Kirsh" <kirsh@...>
> Sent: Saturday, October 06, 2007 8:05 PM
> Subject: Re: 'Implements' annotation and XML element
>
>
>>I mean in super pc you have a 1-1 association, and by the moment you need
>>to know the super pc class, you have already loaded the pc class, while
>>implements has a 1-N, where N is not a fixed number
>> --   BlackBerry® from Mobistar    ---
>>
>> -----Original Message-----
>> From: "Erik Bengtson" <erik@...>
>>
>> Date: Sat, 6 Oct 2007 17:53:12
>> To:"Ilan Kirsh" <kirsh@...>
>> Subject: Re: 'Implements' annotation and XML element
>>
>>
>> I think the utility is go cases where classes have not been loaded.
>> Example: schema creation does not need to load all pc classes to discover
>> which ones implements the interface, but only those declared.
>>
>> While super pc class is used for discovery in bottom-up(child pc->super),
>> implements is top-down (interface->classes)
>> --   BlackBerry® from Mobistar    ---
>>
>> -----Original Message-----
>> From: Ilan Kirsh <kirsh@...>
>>
>> Date: Sat, 06 Oct 2007 19:17:42
>> To:JDO Expert Group <jdo-experts-ext@...>
>> Subject: Fw: 'Implements' annotation and XML element
>>
>>
>> Sent again, now to jdo-experts-ext@...
>>
>> ----- Original Message -----
>> From: "Ilan Kirsh" <kirsh@...>
>> To: <jdo-dev@...>
>> Sent: Friday, October 05, 2007 1:15 AM
>> Subject: 'Implements' annotation and XML element
>>
>>
>> Hi,
>>
>> The 'Implements' annotation (and the equivalent XML element) remind me
>> the 'persistence-capable-superclass' XML attribute that is deprecated
>> now.
>>
>> If persistence capable interfaces are marked as such by annotations
>> (or in the XML metadata), why should we have this duplication?
>>
>> Implementations should be able to find implemented persistence capable
>> interfaces as they find a super persistence capable class.
>>
>> Ilan Kirsh
>> ObjectDB Software
>> http://www.objectdb.com
>>
>>
>>
>>
>>
>
>
>

[Craig L Russell]

Hi Ilan,

+1 to remove/deprecate the implements element and @Implements  
annotation.

If no adverse comments are received by Tuesday October 16, it's gone.

On Oct 4, 2007, at 4:15 PM, Ilan Kirsh wrote:

> Hi,
>
> The 'Implements' annotation (and the equivalent XML element) remind me
> the 'persistence-capable-superclass' XML attribute that is  
> deprecated now.

Yes, for JDO 1, we tried to have it possible to enhance classes when  
not all of its dependencies (superclasses and implemented interfaces)  
were available for loading and analysis. In this environment, it was  
necessary to explicitly declare which interfaces were implemented  
because you could not load all of the directly implemented interfaces  
to see which persistence-capable interfaces were indirectly inherited.

But now, enhancement requires access to the entire inheritance tree  
and it makes sense to also require the implements tree as well.
>
> If persistence capable interfaces are marked as such by annotations
> (or in the XML metadata), why should we have this duplication?
>
> Implementations should be able to find implemented persistence capable
> interfaces as they find a super persistence capable class.

True, and I support deprecating the xml attribute and removing the  
@Implements annotation.

Unless someone can justify why there would be any semantic difference  
between explicitly declaring the interfaces versus the enhancer  
finding them. The only thing I can think of is whether an explicitly  
named interface would have an extent managed, but I think that you  
can only query over the extent of classes/interfaces that themselves  
declare that an extent is managed.

Craig
>
> Ilan Kirsh
> ObjectDB Software
> http://www.objectdb.com
>
>

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@...
P.S. A good JDO? O, Gasp!

[cbeams]

I haven't fully reviewed this proposal, but I do know that using  
implements/@Implements only served to confuse me in the past.  I kept  
thinking: isn't this information superfluous?  Should the enhancer  
have been able to figure this stuff out by static analysis?

So if it is in fact not needed, I'm a big +1.

Thanks,

- Chris Beams

On Oct 12, 2007, at 8:45 AM, Craig L Russell wrote:

> Hi Ilan,
>
> +1 to remove/deprecate the implements element and @Implements  
> annotation.
>
> If no adverse comments are received by Tuesday October 16, it's gone.
>
> On Oct 4, 2007, at 4:15 PM, Ilan Kirsh wrote:
>
>> Hi,
>>
>> The 'Implements' annotation (and the equivalent XML element)  
>> remind me
>> the 'persistence-capable-superclass' XML attribute that is  
>> deprecated now.
>
> Yes, for JDO 1, we tried to have it possible to enhance classes  
> when not all of its dependencies (superclasses and implemented  
> interfaces) were available for loading and analysis. In this  
> environment, it was necessary to explicitly declare which  
> interfaces were implemented because you could not load all of the  
> directly implemented interfaces to see which persistence-capable  
> interfaces were indirectly inherited.
>
> But now, enhancement requires access to the entire inheritance tree  
> and it makes sense to also require the implements tree as well.
>>
>> If persistence capable interfaces are marked as such by annotations
>> (or in the XML metadata), why should we have this duplication?
>>
>> Implementations should be able to find implemented persistence  
>> capable
>> interfaces as they find a super persistence capable class.
>
> True, and I support deprecating the xml attribute and removing the  
> @Implements annotation.
>
> Unless someone can justify why there would be any semantic  
> difference between explicitly declaring the interfaces versus the  
> enhancer finding them. The only thing I can think of is whether an  
> explicitly named interface would have an extent managed, but I  
> think that you can only query over the extent of classes/interfaces  
> that themselves declare that an extent is managed.
>
> Craig
>>
>> Ilan Kirsh
>> ObjectDB Software
>> http://www.objectdb.com
>>
>>
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@...
> P.S. A good JDO? O, Gasp!
>