You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jdo-dev@db.apache.org by Craig L Russell <Cr...@Sun.COM> on 2007/10/13 02:50:42 UTC
VOTE: change signatures for Java5; deprecate uncooperative APIs
This is from the discussion in https://issues.apache.org/jira/browse/
JDO-538
It turns out that there are some uncooperative methods (those that
have a boolean parameter as the second parameter) that don't easily
migrate to Java 5 syntax.
Please vote:
+1 add new methods that move the boolean parameter to be first and
change the Object[ ] to Object...; deprecate the uncooperative methods
-1 keep the uncooperative methods as they are
This vote will end on Monday. Here's the discussion.
The compiler only autoboxes if the signature is one of the new
variable-arity signatures. I took a closer look and found these
signatures that can be changed to autobox, simply by changing the
signature from [ ] to ...
The implementation would need to change the signature of the
implementing class but no other changes would be needed (the type of
the argument inside the method remains e.g. Object[ ]).
In PersistenceManager, these methods can be redefined to use variable-
arity:
void deletePersistentAll (Object[] pcs);
<T> T[] detachCopyAll (T[] pcs);
void evictAll (Object[] pcs);
Object[] getObjectsById (Object[] oids, boolean validate);
void makeNontransactionalAll (Object[] pcs);
<T> T[] makePersistentAll (T[] pcs);
void makeTransactionalAll (Object[] pcs);
void makeTransientAll (Object[] pcs);
void makeTransientAll (Object[] pcs, boolean useFetchPlan);
void retrieveAll (Object[] pcs, boolean useFetchPlan);
void retrieveAll (Object[] pcs);
In Query:
long deletePersistentAll (Object[] parameters);
Object executeWithArray (Object[] parameters);
One more issue. Variable-arity only works if the variable part is the
last argument. So we either have to reorder the arguments or just not
modify the signature for the methods with extra arguments. So we either:
1. Add new signatures, e.g.
void makeTransientAll (boolean useFetchPlan, Object... pcs);
void makeTransientAll (boolean useFetchPlan, Object... pcs);
void retrieveAll (boolean useFetchPlan, Object... pcs);
2. Don't change the signatures for these methods:
Object[] getObjectsById (Object[] oids, boolean validate);
void makeTransientAll (Object[] pcs, boolean useFetchPlan);
void retrieveAll (Object[] pcs, boolean useFetchPlan);
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: change signatures for Java5; deprecate uncooperative APIs
Posted by cbeams <cb...@gmail.com>.
+1.
On Oct 14, 2007, at 8:41 AM, Matthew Adams wrote:
> +1. Make sure we deprecate the old when adding the new methods.
>
> On Oct 14, 2007, at 3:35 AM, Ilan Kirsh wrote:
>
>> +1 add new methods that move the boolean parameter to be first
>> and change the Object[ ] to Object...; deprecate the
>> uncooperative methods
>>
>> Ilan
>>
>> ----- Original Message ----- From: "Craig L Russell"
>> <Cr...@Sun.COM>
>> To: "Apache JDO project" <jd...@db.apache.org>
>> Sent: Saturday, October 13, 2007 2:50 AM
>> Subject: VOTE: change signatures for Java5; deprecate
>> uncooperative APIs
>>
>>
>>> This is from the discussion in https://issues.apache.org/jira/
>>> browse/ JDO-538
>>> It turns out that there are some uncooperative methods (those
>>> that have a boolean parameter as the second parameter) that
>>> don't easily migrate to Java 5 syntax.
>>> Please vote:
>>> +1 add new methods that move the boolean parameter to be first
>>> and change the Object[ ] to Object...; deprecate the
>>> uncooperative methods
>>> -1 keep the uncooperative methods as they are
>>> This vote will end on Monday. Here's the discussion.
>>> The compiler only autoboxes if the signature is one of the new
>>> variable-arity signatures. I took a closer look and found these
>>> signatures that can be changed to autobox, simply by changing
>>> the signature from [ ] to ...
>>> The implementation would need to change the signature of the
>>> implementing class but no other changes would be needed (the type
>>> of the argument inside the method remains e.g. Object[ ]).
>>> In PersistenceManager, these methods can be redefined to use
>>> variable- arity:
>>> void deletePersistentAll (Object[] pcs);
>>> <T> T[] detachCopyAll (T[] pcs);
>>> void evictAll (Object[] pcs);
>>> Object[] getObjectsById (Object[] oids, boolean validate);
>>> void makeNontransactionalAll (Object[] pcs);
>>> <T> T[] makePersistentAll (T[] pcs);
>>> void makeTransactionalAll (Object[] pcs);
>>> void makeTransientAll (Object[] pcs);
>>> void makeTransientAll (Object[] pcs, boolean useFetchPlan);
>>> void retrieveAll (Object[] pcs, boolean useFetchPlan);
>>> void retrieveAll (Object[] pcs);
>>> In Query:
>>> long deletePersistentAll (Object[] parameters);
>>> Object executeWithArray (Object[] parameters);
>>> One more issue. Variable-arity only works if the variable part is
>>> the last argument. So we either have to reorder the arguments or
>>> just not modify the signature for the methods with extra
>>> arguments. So we either:
>>> 1. Add new signatures, e.g.
>>> void makeTransientAll (boolean useFetchPlan, Object... pcs);
>>> void makeTransientAll (boolean useFetchPlan, Object... pcs);
>>> void retrieveAll (boolean useFetchPlan, Object... pcs);
>>> 2. Don't change the signatures for these methods:
>>> Object[] getObjectsById (Object[] oids, boolean validate);
>>> void makeTransientAll (Object[] pcs, boolean useFetchPlan);
>>> void retrieveAll (Object[] pcs, boolean useFetchPlan);
>>> Craig Russell
>>> Architect, Sun Java Enterprise System http://java.sun.com/
>>> products/jdo
>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>> P.S. A good JDO? O, Gasp!
>>>
>>
>
Re: change signatures for Java5; deprecate uncooperative APIs
Posted by Matthew Adams <ma...@matthewadams.org>.
+1. Make sure we deprecate the old when adding the new methods.
On Oct 14, 2007, at 3:35 AM, Ilan Kirsh wrote:
> +1 add new methods that move the boolean parameter to be first and
> change the Object[ ] to Object...; deprecate the uncooperative methods
>
> Ilan
>
> ----- Original Message ----- From: "Craig L Russell"
> <Cr...@Sun.COM>
> To: "Apache JDO project" <jd...@db.apache.org>
> Sent: Saturday, October 13, 2007 2:50 AM
> Subject: VOTE: change signatures for Java5; deprecate uncooperative
> APIs
>
>
>> This is from the discussion in https://issues.apache.org/jira/
>> browse/ JDO-538
>> It turns out that there are some uncooperative methods (those
>> that have a boolean parameter as the second parameter) that don't
>> easily migrate to Java 5 syntax.
>> Please vote:
>> +1 add new methods that move the boolean parameter to be first
>> and change the Object[ ] to Object...; deprecate the
>> uncooperative methods
>> -1 keep the uncooperative methods as they are
>> This vote will end on Monday. Here's the discussion.
>> The compiler only autoboxes if the signature is one of the new
>> variable-arity signatures. I took a closer look and found these
>> signatures that can be changed to autobox, simply by changing the
>> signature from [ ] to ...
>> The implementation would need to change the signature of the
>> implementing class but no other changes would be needed (the type
>> of the argument inside the method remains e.g. Object[ ]).
>> In PersistenceManager, these methods can be redefined to use
>> variable- arity:
>> void deletePersistentAll (Object[] pcs);
>> <T> T[] detachCopyAll (T[] pcs);
>> void evictAll (Object[] pcs);
>> Object[] getObjectsById (Object[] oids, boolean validate);
>> void makeNontransactionalAll (Object[] pcs);
>> <T> T[] makePersistentAll (T[] pcs);
>> void makeTransactionalAll (Object[] pcs);
>> void makeTransientAll (Object[] pcs);
>> void makeTransientAll (Object[] pcs, boolean useFetchPlan);
>> void retrieveAll (Object[] pcs, boolean useFetchPlan);
>> void retrieveAll (Object[] pcs);
>> In Query:
>> long deletePersistentAll (Object[] parameters);
>> Object executeWithArray (Object[] parameters);
>> One more issue. Variable-arity only works if the variable part is
>> the last argument. So we either have to reorder the arguments or
>> just not modify the signature for the methods with extra
>> arguments. So we either:
>> 1. Add new signatures, e.g.
>> void makeTransientAll (boolean useFetchPlan, Object... pcs);
>> void makeTransientAll (boolean useFetchPlan, Object... pcs);
>> void retrieveAll (boolean useFetchPlan, Object... pcs);
>> 2. Don't change the signatures for these methods:
>> Object[] getObjectsById (Object[] oids, boolean validate);
>> void makeTransientAll (Object[] pcs, boolean useFetchPlan);
>> void retrieveAll (Object[] pcs, boolean useFetchPlan);
>> Craig Russell
>> Architect, Sun Java Enterprise System http://java.sun.com/products/
>> jdo
>> 408 276-5638 mailto:Craig.Russell@sun.com
>> P.S. A good JDO? O, Gasp!
>>
>
Re: change signatures for Java5; deprecate uncooperative APIs
Posted by Ilan Kirsh <ki...@objectdb.com>.
+1 add new methods that move the boolean parameter to be first and
change the Object[ ] to Object...; deprecate the uncooperative methods
Ilan
----- Original Message -----
From: "Craig L Russell" <Cr...@Sun.COM>
To: "Apache JDO project" <jd...@db.apache.org>
Sent: Saturday, October 13, 2007 2:50 AM
Subject: VOTE: change signatures for Java5; deprecate uncooperative APIs
> This is from the discussion in https://issues.apache.org/jira/browse/
> JDO-538
>
> It turns out that there are some uncooperative methods (those that
> have a boolean parameter as the second parameter) that don't easily
> migrate to Java 5 syntax.
>
> Please vote:
>
> +1 add new methods that move the boolean parameter to be first and
> change the Object[ ] to Object...; deprecate the uncooperative methods
>
> -1 keep the uncooperative methods as they are
>
> This vote will end on Monday. Here's the discussion.
>
> The compiler only autoboxes if the signature is one of the new
> variable-arity signatures. I took a closer look and found these
> signatures that can be changed to autobox, simply by changing the
> signature from [ ] to ...
>
> The implementation would need to change the signature of the
> implementing class but no other changes would be needed (the type of
> the argument inside the method remains e.g. Object[ ]).
>
> In PersistenceManager, these methods can be redefined to use variable-
> arity:
>
> void deletePersistentAll (Object[] pcs);
> <T> T[] detachCopyAll (T[] pcs);
> void evictAll (Object[] pcs);
> Object[] getObjectsById (Object[] oids, boolean validate);
> void makeNontransactionalAll (Object[] pcs);
> <T> T[] makePersistentAll (T[] pcs);
> void makeTransactionalAll (Object[] pcs);
> void makeTransientAll (Object[] pcs);
> void makeTransientAll (Object[] pcs, boolean useFetchPlan);
> void retrieveAll (Object[] pcs, boolean useFetchPlan);
> void retrieveAll (Object[] pcs);
>
> In Query:
> long deletePersistentAll (Object[] parameters);
> Object executeWithArray (Object[] parameters);
>
> One more issue. Variable-arity only works if the variable part is the
> last argument. So we either have to reorder the arguments or just not
> modify the signature for the methods with extra arguments. So we either:
>
> 1. Add new signatures, e.g.
> void makeTransientAll (boolean useFetchPlan, Object... pcs);
> void makeTransientAll (boolean useFetchPlan, Object... pcs);
> void retrieveAll (boolean useFetchPlan, Object... pcs);
> 2. Don't change the signatures for these methods:
> Object[] getObjectsById (Object[] oids, boolean validate);
> void makeTransientAll (Object[] pcs, boolean useFetchPlan);
> void retrieveAll (Object[] pcs, boolean useFetchPlan);
>
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
>
Re: VOTE: change signatures for Java5; deprecate uncooperative APIs
Posted by Michael Bouschen <mb...@spree.de>.
Hi Craig,
it might be too late now, but here is my +1.
Regards Michael
> This is from the discussion in
> https://issues.apache.org/jira/browse/JDO-538
>
> It turns out that there are some uncooperative methods (those that
> have a boolean parameter as the second parameter) that don't easily
> migrate to Java 5 syntax.
>
> Please vote:
>
> +1 add new methods that move the boolean parameter to be first and
> change the Object[ ] to Object...; deprecate the uncooperative methods
>
> -1 keep the uncooperative methods as they are
>
> This vote will end on Monday. Here's the discussion.
>
> The compiler only autoboxes if the signature is one of the new
> variable-arity signatures. I took a closer look and found these
> signatures that can be changed to autobox, simply by changing the
> signature from [ ] to ...
>
> The implementation would need to change the signature of the
> implementing class but no other changes would be needed (the type of
> the argument inside the method remains e.g. Object[ ]).
>
> In PersistenceManager, these methods can be redefined to use
> variable-arity:
>
> void deletePersistentAll (Object[] pcs);
> <T> T[] detachCopyAll (T[] pcs);
> void evictAll (Object[] pcs);
> Object[] getObjectsById (Object[] oids, boolean validate);
> void makeNontransactionalAll (Object[] pcs);
> <T> T[] makePersistentAll (T[] pcs);
> void makeTransactionalAll (Object[] pcs);
> void makeTransientAll (Object[] pcs);
> void makeTransientAll (Object[] pcs, boolean useFetchPlan);
> void retrieveAll (Object[] pcs, boolean useFetchPlan);
> void retrieveAll (Object[] pcs);
>
> In Query:
> long deletePersistentAll (Object[] parameters);
> Object executeWithArray (Object[] parameters);
>
> One more issue. Variable-arity only works if the variable part is the
> last argument. So we either have to reorder the arguments or just not
> modify the signature for the methods with extra arguments. So we either:
>
> 1. Add new signatures, e.g.
> void makeTransientAll (boolean useFetchPlan, Object... pcs);
> void makeTransientAll (boolean useFetchPlan, Object... pcs);
> void retrieveAll (boolean useFetchPlan, Object... pcs);
> 2. Don't change the signatures for these methods:
> Object[] getObjectsById (Object[] oids, boolean validate);
> void makeTransientAll (Object[] pcs, boolean useFetchPlan);
> void retrieveAll (Object[] pcs, boolean useFetchPlan);
>
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
--
Tech@Spree Engineering GmbH Tel.: +49/(0)30/235 520-33
Buelowstr. 66 Fax.: +49/(0)30/217 520-12
10783 Berlin mailto:mbo.tech@spree.de
Geschaeftsfuehrung: Anna-Kristin Proefrock
Sitz Berlin, Amtsgericht Charlottenburg, HRB 564 52