Hello All,
Rick's suggestion of adding <? extends Object> to the List
parameter on the commonj.sdo.DataObject.setList method seems to have
done the trick. Attached is the updated version of the public API
source code. There are no known issues with the source code at this
time.
void setList(Property property, List<? extends Object> value);
-Blaise
Blaise Doughan wrote:
4BE84C66.7090708@oracle.com" type="cite">
Hello All,
I believe the binary compatibility issue has been solved. The problem
appears to boil down to the setList method that takes a property on
DataObject
- commonj.sdo.DataObject - void setList(commonj.sdo.Property
property, List value);
- org.oasisopen.sdo.DataObject - void
setList(org.oasisopen.sdo.Property property, List<? extends
Object> value)
With this configuration you get the following error when you try to
call setList: "The method setList(Property, List) is ambiguous for the
type DataObject".
The fix is to remove the <? extends Object> from the List
parameter on org.oasisopen.sdo.DataObject:
- org.oasisopen.sdo.DataObject - void
setList(org.oasisopen.sdo.Property property, List value)
To make things look more consistent I have removed <? extends
Object> from the other two setList methods as well.
Note that this problem does not appear to occur on methods that just
take a list parameter such as:
- commonj.sdo.helper.TypeHelper - List /*Type*/ define(List
/*DataObject*/ types);
- org.oasisopen.sdo.helper.TypeHelper -
List<org.oasisopen.sdo.Type>
define(List<org.oasisopen.sdo.DataObject>
types);
-Blaise
Blaise Doughan wrote:
Latest version of the API refactor.
-Blaise
Blaise Doughan wrote:
Hi Frank,
I believe the attached version of the API addresses your points. I
don't remember the group deciding to remove getRootObject() so I have
put that back in.
-Blaise
Frank Budinsky wrote:
Hi Blaise,
It looks like the other 2 missing methods from
org.oasisopen.sdo.DataObject are:
Sequence getSequence();
DataObject getRootObject();
I think we did decide to remove getRootObject() as part of the
orphanHolder issue, but I think getSequence() should be there. So, if
you add getSequence() and setList(int, List), then
org.oasisopen.sdo.DataObject will have 39 methods total, which I think
is what we should expect.
Thanks,
Frank.
Blaise Doughan
---04/09/2010 11:04:34 AM---Hi Frank, I'll look into void setList(int
propertyIndex, List<? extends Object>
Hi Frank,
I'll look into void setList(int propertyIndex, List<? extends
Object> value);.
For the other missing methods, the commonj.sdo.* classes extend the
org.oasisopen.sdo.* classes, so where possible I have removed the
commonj methods where they can be inherited from oasisopen. Including
inheritance the SDO 3.0 commonj classes should have more methods than
the SDO 2.1.1 commonj classes.
-Blaise
Frank Budinsky wrote:
Hi Blaise,
I think this method is missing from org.oasisopen.sdo.DataObject:
void setList(int propertyIndex, List<? extends Object> value);
I'm also not sure if there are more missing methods, since here is
understanding:
1. JSR235 DataObject had 123 methods.
2. 5 deprecated should be removed.
3. 84 getXXX/setXXX methods are being removed.
4. 6 new generic get/set methods are being added.
So this implies that org.oasisopen.sdo.DataObject should have:
123 - 5 - 84 + 6 = 40 methods.
But, I count only 37. If you add the setList() method, above, that's
38, but still 2 short of the 40 that I expected. Am I missing something?
Also, I noticed that the version of commonj.sdo.DataObject in your zip
only has 109 methods, instead of the original 123 from JSR235. I
thought it was supposed to be essentially the JSR 235 version, only
deprecated. Did you need to remove some methods to get it to compile?
Thanks,
Frank.
Blaise Doughan
---04/09/2010 09:53:40 AM---Hello All, Attached is the third pass at
the API refactor. The commonj.sdo.* files
Hello All,
Attached is the third pass at the API refactor. The commonj.sdo.* files
are now marked deprecated (in both the javadoc comment and @Deprecated
annotation). Also the javadoc comment problem in DataObject has been
fixed.
-Blaise
Blaise Doughan wrote:
Hello All,
Attached is the second pass at the API refactor. The commonj.sdo.*
files are based on SDO 2.1.1 (JSR 235), and the org.oasisopen.sdo.*
files are based on the files sent out by Ron on Feburary 18th with the
subject "[sdo] SDO-27: Proposed API with generics and deprecated typed
accessors.".
-Blaise
Blaise Doughan wrote:
Hello All,
Attached is a first stab at the API refactor discussed last week
(introducing org.oasisopen.sdo.*). It is still a work in progress and
will not completely compile. I have also attached a skeleton impl to
ensure that an implementation could implement both sets of interfaces.
To satisfy the compiler I was required to remove the generics from all
list return types on the commonj.sdo.* classes as apparently
This is valid:
Super Class: org.oasisopen.sdo.DataObject foo();
Sub Class: commonj.sdo.DataObject foo();
This is not:
Super Class: List<org.oasisopen.sdo.DataObject bar();
Sub Class: List<commonj.sdo.DataObject> bar();
Decisions to be made:
1. Is
this worth doing?
2. Is there any reason for the commonj.sdo.* API
to be different from SDO 2.1.1 (add new API only to
org.oasisopen.sdo.*)?
3. Are there any other API fixes we should make?
-Blaise
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php (See attached file:
SdoApiRefactorV3.zip)---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
|