@LazyLoading is too lazy, always creates new object

I considered whether something like a WeakHashMap might be useful, but I think in most cases people are expecting a "strong" reference level with a list, such as in the following example:

// Double the size of every value
for(int i = 0; i < theList.size(); i++){
    theList.get(i).value *= 2;
}

Patch to fix PREON-29, adds a basic HashMap to avoid object re-creation. Creating sublists will cause those lists to use the same map.

Still trying to get GIT+SSH working on my Windows laptop. And I typo'ed the patch filename. Oh well.

@LazyLoading currently applies to the field on which it has been set. So, the Codec that is responsible for populating the field will insert a proxy instead of the actual object. That proxy will load the actual data when it's needed. (And then hold on to it.)

@LazyLoading doesn't percolate down the chain of responsibility automatically, and I am not even sure if that would be a good thing. Also, changing EvenlyDistributedLazyList to always hold on to the elements it loaded would not necessarily be great in all circumstances.

So, using just one annotation (@LazyLoading) to indicate both that the object value to populate the field should be decoded lazily and that elements of a list (if the field's value happens to be a list) need to be cached is something that I think we should avoid.

Perhaps, instead, there should be an annotation indicating that the collection's elements should be cached (@CachingCollection) once decoded, and implement a CodecDecorator to wrap the Codec constructed by the ListCodecFactory into a Codec that creates a caching List wrapper around the List returned by the latter.

@LazyLoading doesn't percolate down the chain of responsibility automatically

Well, it looks like it is. I mean, if I specified:

@LazyLoading
@BoundObject(type=Foo.class)
public Foo data;

Then if @LazyLoading was a "first-level-only" modifier, I'd expect that there'd be a lazy-proxy around an instance of Foo.

Similarly:

@LazyLoading
@BoundList(size = "length", type = ItemStruct.class)
public List<ItemStruct> data;

Suggests a lazy-proxy that instantiates and delegates a non-lazy List implementation, perhaps even ArrayList<ItemStruct>.

Perhaps forgetful-lazy/caching-lazy/normal should instead be a setting on @BoundList?

So then you'd have:

// Lazy-loaded object
// May or may not have lazy-bound properties of its own
@LazyLoading
@BoundObject(type=Foo.class)
public Foo alpha;

// Lazy-loaded list, but each entry is immediately
// created when the list is instantiated
@LazyLoading
@BoundList(size="10",type="Byte.class")
public List<Byte> beta;

// List which is immediately instantiated, but each
// entry is lazily-instantiated just once.
@BoundList(size="10",type="Byte.class",lazy=true)
public List<Byte> gamma;

// List which is lazily-instantiated, 
// lazily-loads its contents, and never caches,
// so each get() call creates a new item.
@LazyLoading
@BoundList(size="10",type="Byte.class",lazy=true,caching=false)
public List<Byte> delta;

Suggests a lazy-proxy that instantiates and delegates a non-lazy List implementation, perhaps even ArrayList<ItemStruct>.

If you are saying that the List implementation currently getting generated is lazy-loading it's elements (but not caching it) even if you don't specify @LazyLoading, then you are right. Preon tries to be smart (perhaps a little too smart for your taste) and if it notices it would be possible to lazy-load elements from the list, it will do so.

So what I expect you will get when using:

@LazyLoading
@BoundList(...)
private List<FooBar>

is a List that is not getting instantiated before you access one of its methods, and when you access one its methods, it will (most likely) create an implementation of Evenly...List that will still only dive into the BitBuffer to decode elements if you access them.

If it currently is not working like that, I would consider that a bug. If you need something else, I would consider that a feature request.

I think the use-case that is a problem is where I'm not just reading a bunch of data, but modifying things with the plan to save or otherwise re-use the data structure. I means I can't loop through and make changes since the objects are always garbage-collected once I'm done with them.

There's this conceptual disconnect between "lazily loaded (once, when needed)" versus "a fresh copy is created every time you call the getter." The simplest resolution for this ticket is just to add a warning in the documentation.