git-afsantos / undo4j

Generic transaction support at application level for Java.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Generics

git-afsantos opened this issue · comments

I've been thinking about including generics in the project for a while now. Generics, as in dropping Resource, ResourceState and instanceof, in favor of Resource<T>, ResourceState<T>, etc. However, we've faced some roadblocks. For instance:

  • The current implementation stores managed resources in a Map<String, Resource>. With generics, the only viable option would be Map<ResourceKey, Resource<?>>, where ResourceKey would be a Super Type Token, and the map a typesafe heterogeneous map.
  • I think the above solution turns out to be complicated, and messes up the code more than it helps. So, the solution would be to manage the resources without storing them. However, this probably implies that the client must keep a reference to his resources all the time (in the current version he may store the resources in the map and forget about them, until a transaction requires the resources).
  • Managing resources without storing them would mean that each transaction may have to keep a reference to both the resource, and, when executing, the handle provided. This may be misleading to the user, and the user may feel tempted to use the (unmanaged) resource.directly.
  • Alternatively, the user could create resources through factory methods only, thus receiving a reference to the handle, and never seeing the actual resource. I don't know yet if this is feasible, or if it limits in any way the ability to customize resources.

I'm also considering dropping (from the interface) the use of Callable, in favor of a custom Callable. We could control the checked exceptions thrown, instead of Exception, and it would be fed a reference to the Handle provider, in its call method.

Any thoughts?

I think that using generics would help in creating resources, since one wouldn't have to implement a class for every type. But if that will make coding harder then I don't think it is worth it.
We should aim at making the life of the developer as easy as possible.

Let's try it out, in a branch, in see the impact on the client's code. The we can make a better decision.