[
https://issues.apache.org/jira/browse/JDO-538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12532304
]
Craig Russell commented on JDO-538:
-----------------------------------
> But given that the compiler will autobox Object[ ] anyway, is there a need to
> change the signatures to get the desired effect?
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 also need to change the signature but no other changes
would be needed (the type of the argument inside the method remains e.g.
Object[ ]).
In PersistenceManager:
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);
Any objections?
> Make more JDO APIs generic
> --------------------------
>
> Key: JDO-538
> URL: https://issues.apache.org/jira/browse/JDO-538
> Project: JDO
> Issue Type: Improvement
> Components: api2
> Affects Versions: JDO 2 final
> Reporter: Chris Beams
> Assignee: Craig Russell
> Fix For: JDO 2 maintenance release 1
>
> Attachments: jdo-538.patch
>
>
> Several suggestions relating to evolving the API in support of Java5 features:
> 11.6, "Optional Feature Support":
> The current draft specifies the signature
> Collection supportedOptions();
> then continues to read
> "This method returns a Collection of String [...]"
> This suggests that the signature should be
> Collection<String> supportedOptions();
> 14.6.1, "Query Execution"
> I suggest we eliminate
> Object execute(Object p1);
> Object execute(Object p1, Object p2);
> Object execute(Object p1, Object p2, Object p3);
> and deprecate
> Object executeWithArray(Object[] parameters);
> in favor of a newly added
> Object execute(Object... parameters);
> This new method would seamlessly support any existing calls to the three
> eliminated methods, and is a proper replacement for executeWithArray().
> This would would leave us with three (non-deprecated) execution methods off
> the Query interface:
> Object execute();
> Object execute(Object... parameters);
> Object executeWithMap(Map parameters);
> A slightly more radical approach to this evolution would have us also
> eliminate
> Object execute();
> because the new varargs method can by definition support calls without
> arguments,
> and deprecate
> Object executeWithMap(Map params);
> in favor of a new
> Object execute(Map params);
> because Java can disambiguate between calls to execute(Object... params) and
> execute(Map params) just fine. This is predecated by the assumption that it
> would never be valid to pass a Map instance as a first-class query parameter.
> That might be a faulty assumption, it might also just be confusing.
> If all these changes were made, we'd be left with an execution API consisting
> of just two methods:
> Object execute(Object... params);
> Object execute(Map params);
> This is, I believe, technically favorable and cleaner, but technical
> considerations are not the only valid ones. Leaving the no-arg execute()
> might be friendly to folks that don't understand varargs, etc.
> 14.8, "Deletion by Query":
> The rationale used above for paring down Query's execute methods could also
> be applied to Query's deletePersistentAll methods. It would be legal and
> Java5-ish to eliminate the no-arg deletePersistentAll method and reduce the
> API down to:
> long deletePersistentAll(Object... params);
> long deletePersistentAll(Map params);
> ...
> There's a number of other places in the spec changes like the ones mentioned
> here could be made, but I might be getting ahead of myself :-) I'll await
> comments before touching on anything else.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
