castor
  1. castor
  2. CASTOR-1696

Source generator creates Vector reference setter from schema when types=j2

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 1.0.5
    • Fix Version/s: 1.1 M1
    • Component/s: XML code generator
    • Labels:
      None
    • Environment:
      Windows XP Pro
    • Number of attachments :
      2

      Description

      Upgraded to 1.0.5 from 1.0M4. Based on the following example snippet:

      <xs:complexType name="GenClass">
      <xs:complexContent>
      <xs:extension base="BaseGen">
      <xs:sequence>
      <xs:element name="widgets" type="Widget" minOccurs="0"
      maxOccurs="unbounded" />
      </xs:sequence>
      </xs:extension>
      </xs:complexContent>
      </xs:complexType>

      The following setters are generated (with Java 5 support turned on):

      public void setWidgets(Widget[] vWidgetsArray)
      public void setWidgets(java.util.List<Widget> vWidgetsList)
      public void setWidgetsList(java.util.Vector<Widget> WidgetsVector)

      whereas the following were generated in 1.0M4:

      public void setWidgets(Widget[] WidgetsArray)
      public void setWidgets(java.util.List widgetsCollection)
      public void setWidgetsList(java.util.List widgetsCollection)

        Activity

        Hide
        Edward Kuns added a comment -

        I now understand much better what your questions are. You are asking ONLY about the method

        setWidgetsAsReference(java.util.Vector WidgetsVector)

        correct? What is the value of this method to someone who is using Castor? It's more efficient than doing Collection.clear() then .addAll(), but other than this, is there value added by this method? (I imagine this is why Ralf suggests getting rid of this method altogether.)

        As long as we generate this method, we definitely want the method parameter type to be the same as the type of the collection used. (So we will not need type verification or casting and there'll be no risk of class cast exception.)

        Other than this, I cannot really think of a more meaningful name than setXXXXXXAsReference.

        Show
        Edward Kuns added a comment - I now understand much better what your questions are. You are asking ONLY about the method setWidgetsAsReference(java.util.Vector WidgetsVector) correct? What is the value of this method to someone who is using Castor? It's more efficient than doing Collection.clear() then .addAll(), but other than this, is there value added by this method? (I imagine this is why Ralf suggests getting rid of this method altogether.) As long as we generate this method, we definitely want the method parameter type to be the same as the type of the collection used. (So we will not need type verification or casting and there'll be no risk of class cast exception.) Other than this, I cannot really think of a more meaningful name than setXXXXXXAsReference.
        Hide
        Werner Guttmann added a comment -

        Fine by me. I'll add add the @deprecated comment, and make sure that the method is correctly typed, according to what the user specified either when calling the SourceGenerator or through the binding file (as per the recently added new collection type support).

        Show
        Werner Guttmann added a comment - Fine by me. I'll add add the @deprecated comment, and make sure that the method is correctly typed, according to what the user specified either when calling the SourceGenerator or through the binding file (as per the recently added new collection type support).
        Hide
        Werner Guttmann added a comment -

        Whilst we are actually talking about things related to collections, does anybody have a few what methods should be generated for Map-based collection types ?

        Show
        Werner Guttmann added a comment - Whilst we are actually talking about things related to collections, does anybody have a few what methods should be generated for Map-based collection types ?
        Hide
        Werner Guttmann added a comment -

        Edward, let me just make sure that I understand you correctly. Above, you state ...

        > As long as we generate this method, we definitely want the method parameter type to be the same as
        > the type of the collection used. (So we will not need type verification or casting and there'll be no risk of class cast exception.)

        My original idea was to bring this in line with the FieldInfoFactory used when creating the SourceGenerator instance ('j1', 'j2'). SO it could either be

        public void setWidgetsAsReference(java.util.Vector widgetsVector), or
        public void setWidgetsAsReference(java.util.List widgetsList)

        Having said that, you might have noted that users are now able to override the J2 collection type used for a collection member, by e.g. using java.util.Set, java.util.SortedSet et alias. How am I meant to be reading your statement (quoted above) with regards to this question ?

        Show
        Werner Guttmann added a comment - Edward, let me just make sure that I understand you correctly. Above, you state ... > As long as we generate this method, we definitely want the method parameter type to be the same as > the type of the collection used. (So we will not need type verification or casting and there'll be no risk of class cast exception.) My original idea was to bring this in line with the FieldInfoFactory used when creating the SourceGenerator instance ('j1', 'j2'). SO it could either be public void setWidgetsAsReference(java.util.Vector widgetsVector), or public void setWidgetsAsReference(java.util.List widgetsList) Having said that, you might have noted that users are now able to override the J2 collection type used for a collection member, by e.g. using java.util.Set, java.util.SortedSet et alias. How am I meant to be reading your statement (quoted above) with regards to this question ?
        Hide
        Edward Kuns added a comment -

        If users override the J2 collection type, then our best course of action is to use THAT type in the signature. That way we expose a clear API and we avoid the risk of incompatible types or of a class cast exception.

        Show
        Edward Kuns added a comment - If users override the J2 collection type, then our best course of action is to use THAT type in the signature. That way we expose a clear API and we avoid the risk of incompatible types or of a class cast exception.

          People

          • Assignee:
            Werner Guttmann
            Reporter:
            Dhruva Reddy
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Time Tracking

              Estimated:
              Original Estimate - 30 minutes
              30m
              Remaining:
              Remaining Estimate - 30 minutes
              30m
              Logged:
              Time Spent - Not Specified
              Not Specified