1 2 Previous Next 22 Replies Latest reply: Sep 9, 2010 7:45 PM by 843798 Go to original post RSS
      • 15. Re: Runtime type of Collection contents?
        843798
        Seems the early award of "Correct" was premature. Maybe marking unanswered will let me back it out...


        Edited by: DMF. on Sep 9, 2010 8:43 PM

        Nope, can't change it. Guess I was too quick on the trigger. Hopefully browsers will read past the first couple posts...
        • 16. Re: Runtime type of Collection contents?
          843798
          DMF. wrote:
          It works, but don't ask me why (yet).
          It works because there's no type parameter, but a concrete type at play here. Replace <AConcreteClass> with <T> and it won't work.
          • 17. Re: Runtime type of Collection contents?
            jtahlborn
            ejp wrote:
            I initially thought that this post was referring to an array of a Generic type
            There is no such thing in Java.
            maybe i was using bad terminology, but i was referring something like:
                public class Foo<T>
                {
                    T[] somet;
                }
            
                public class Bar
                {
                    List<String>[] somelist;
                }
            • 18. Re: Runtime type of Collection contents?
              jtahlborn
              JoachimSauer wrote:
              DMF. wrote:
              It works, but don't ask me why (yet).
              It works because there's no type parameter, but a concrete type at play here. Replace <AConcreteClass> with <T> and it won't work.
              right. like i said, you should be able to get the bounds of the collection. if T has no (useful) upper bound (e.g. java.lang.Object), then you won't get anything meaningful.
              • 19. Re: Runtime type of Collection contents?
                843798
                Fortunately most if not all of our properties use concrete types. Now I'm determining the element type using three algorithms:
                - Aniruddha's algorithm on the PropertyDescriptor readMethod (not all have them)
                - a Class object set as an attribute on PropertyDescriptor
                - sampling an element

                The 1 and 3 aren't universal, but the attribute can cover the exceptions. Maps should yield to a similar analysis.


                One problematic case is where the property is declared to return an interface type, e.g. List<String>, but actually returns an unmodifiable collection:
                    private List<String> strings = new ArrayList<String>();
                
                    public final List<String> getStrings() {
                        synchronized( this.strings )  {
                            return Collections.unmodifiableList( this.strings );
                        }
                    }  
                The runtime type of the property is Collections$UnmodifiableList<String> or similar, which is not visible.
                • 20. Re: Runtime type of Collection contents?
                  jtahlborn
                  DMF. wrote:
                  private List<String> strings = new ArrayList<String>();
                  
                  public final List<String> getStrings() {
                  synchronized( this.strings )  {
                  return Collections.unmodifiableList( this.strings );
                  }
                  }  
                  on an unrelated note, this construct does not provide thread-safety for the "strings" collection. making the returned collection unmodifiable does not stop problems from being caused by one thread updating the underlying collection (e.g. this.strings) while another is reading the "unmodifiable" one.
                  • 21. Re: Runtime type of Collection contents?
                    843798
                    The 'unmodifiable' bit isn't intended to enhance thread safety - just to keep users from dicking with the underlying collection at all. (Modification is done through non-public accessors available through an unbundled helper.) A deep copy would have worked as well I suppose. But while part of this graph has to be Cloneable I want to keep that part as small as possible.
                    • 22. Re: Runtime type of Collection contents?
                      jtahlborn
                      DMF. wrote:
                      The 'unmodifiable' bit isn't intended to enhance thread safety - just to keep users from dicking with the underlying collection at all. (Modification is done through non-public accessors available through an unbundled helper.)
                      since there is a "synchronized" block in the method, i assume that the underlying collection is still mutable. so my point remains. the publicly available list is not thread-safe. (i've seen others make the mistake of thinking that passing out an unmodifiable reference to a collection some how makes usage of the collection thread-safe, that's why i assumed you were attempting the same.)
                      A deep copy would have worked as well I suppose.
                      a deep copy would be thread-safe.
                      But while part of this graph has to be Cloneable I want to keep that part as small as possible.
                      not sure how that's related (probably related to a bigger picture than shown here).
                      1 2 Previous Next