> Thanks for the explanation, but the types might be a red herring. I'm
> less concerned about that than the fact that Tapestry seems to be
> assigning one of my variables to a different variable.
You did assign them to the same thing, you just didn't know it. You
told tapestry to store the value of type List pulled from the session
into your attribute, twice.
Imagine you put in your constructor:
list1 = getFieldFromSession("List")
list2 = getFieldFromSession("List")
the name of the attribute is based on the type.
On Thu, Jan 6, 2011 at 7:09 AM, Michael Gentry <mgen...@masslight.net> wrote:
>
> Hi Donny,
>
> Thanks for the explanation, but the types might be a red herring. I'm
> less concerned about that than the fact that Tapestry seems to be
> assigning one of my variables to a different variable. It doesn't
> matter if the types are the same or different. I could've had:
>
> @SessionState(create=false)
> private List<String> list1;
> @SessionState(create=false)
> private List<String> list2;
>
> And I'd still expect to have two separate/distinct variables and
> lists, not two variables pointing to the same list (unless I
> specifically assigned them to the same list myself).
>
> Thanks,
>
> mrg
>
>
> On Thu, Jan 6, 2011 at 9:57 AM, Donny Nadolny <donny.nado...@gmail.com> wrote:
> > Your two lists are the same - they're both of type List so they both get
> > assigned to the same thing. See below for why.
> >
> > The solution is to make two classes, one that holds the booleans, and one
> > that holds the strings. Technically you would only need to do that for one,
> > but it's probably a good idea to do it for both anyway.
> >
> > The reason why they're both considered the same: this has to do with how
> > generics work in Java. It's called type erasure - after the class is
> > compiled, the generic type is erased, so at runtime it doesn't care what the
> > type is. Generics are a compile time check.
> >
> > For example, you could do:
> > List<String> strings = new ArrayList<String>();
> > List strings2 = strings;
> > strings2.add(new Object()); //this line is fine
> > String string = strings.get(0); //throws ClassCastException
> >
> > You might think that the strings2.add(new Object()) would have a problem
> > because strings2 is pointing to strings which is an ArrayList<String>, but
> > it doesn't because at runtime it doesn't do any checks, or even know that
> > you put <String> there (well, there's certain ways of figuring it out, but
> > generally just accept that it doesn't know). All it can do is give a warning
> > at "List strings2 = strings" because you're doing some potentially type
> > unsafe things.
> >
> >
> > On Thu, Jan 6, 2011 at 9:38 AM, Michael Gentry <mgen...@masslight.net>wrote:
> >
> >> Hi everyone,
> >>
> >> Given the following page class:
> >>
> >>
> >> public class Bug
> >> {
> >> �...@inject
> >> private Logger log;
> >>
> >> �...@sessionstate(create=false)
> >> private List<Boolean> booleans;
> >>
> >> �...@sessionstate(create=false)
> >> private List<String> strings;
> >>
> >> void onActivate()
> >> {
> >> log.debug("booleans = " + booleans);
> >> log.debug("strings = " + strings);
> >>
> >> if (booleans == null)
> >> booleans = new ArrayList<Boolean>();
> >>
> >> booleans.add(Boolean.TRUE);
> >>
> >> log.debug("booleans: " + booleans);
> >> log.debug("strings: " + strings);
> >> log.debug("equal? " + booleans.equals(strings));
> >> }
> >> }
> >>
> >> I get this output:
> >>
> >> DEBUG 2011-01-06 09:35:24,014 booleans = null
> >> DEBUG 2011-01-06 09:35:24,014 strings = null
> >> DEBUG 2011-01-06 09:35:24,014 booleans: [true]
> >> DEBUG 2011-01-06 09:35:24,014 strings: [true]
> >> DEBUG 2011-01-06 09:35:24,015 equal? true
> >>
> >>
> >> Even though I don't add anything to the strings list or even allocate
> >> the strings list, it seems to be pointing to the booleans list, which
> >> is, of course, incorrect. This seems to be happening on both 5.1 and
> >> 5.2. Am I missing something?
> >>
> >> Thanks,
> >>
> >> mrg
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> >> For additional commands, e-mail: users-h...@tapestry.apache.org
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
