[jbosscache-dev] Let's make 3.0 backwards compatible

[Manik Surtani]

On 19 Aug 2008, at 15:22, Jason T. Greene wrote:

> Manik Surtani wrote:
>> On 19 Aug 2008, at 06:53, Bela Ban wrote:
>>> First of all: I don't think there's a need to make 1.x compatible  
>>> with 2.x and/or 3.x. The need is there to make 2.x compatible with  
>>> 3.x.
>> I don't know about that.  There are still a lot of people who are  
>> on AS 4.x and who won't switch to AS 5.0 for a while to come.   
>> Which means they will be stuck on 1.x APIs.  See the forum link  
>> that sparked off this thread
>
> Thinking about the 4.x problem, API BC is just part of the problem.  
> Behavioral differences in use by the AS clustering code and  
> hibernate (i.e. AS4 clustering was not written for 3.x), as well as  
> dependency differences (1.4.x uses a different jgroups).

Are there any API deps that hold back users upgrading JGroups in AS as  
well?  I'm sure I know the answer to this, but it's late, I'm tired  
and have a presentation to deliver first thing in the morning.  :-)

> The root of the problem here is that the AS is exposing it's  
> internally used APIs, and thereby forcing them on users. If this was  
> not the case (as it is on other container environments), then users  
> could happily deploy JBC 3 on AS4.2, and still use EJB/HTTP clustering
>
> The SPI that Brian is planning helps, but it requires that the user  
> change the AS clustering implementation, just to change the version  
> of JBC he/she is using. This could impact other components that  
> share deps (JBoss Messaging).
>
> The easiest way to fix this problem, which is done by everyone else,  
> is to put all of the classes used by AS internally under a new  
> namespace (package). It could also be done via a special classloader  
> design, although that would be a massive change, since everyone uses  
> the context loader for everything.

Jarjar, again.  I think this really makes sense for included libraries  
we don't want to expose.  BEA et al used to do this when including  
xerces, etc., and incompatible versions of xerces ran fine together as  
a result with no classloader gimmickery at all.

> We just might not have a simple solution to deploying on 4.2,  
> besides ripping out the clustering modules.
>
>> We could but that would mean some sort of package renaming or class  
>> renaming (e.g., o.j.c.Cache -> o.j.c.Cache3 or o.j.c.3.Cache) and  
>> o.j.c.Cache remains 2.x compatible.  Either way, very ugly for  
>> anyone who wants to use 3.x APIs directly.
>> Specifically, interfaces that have changed include:
>> - Cache
>> - Fqn
>> - EvictionConfig
>> - Region/RegionManager
>> - EvictionAlgorithm
>
> IMO, we can just make this stuff BC for the 3.x release.

Yep.  I need to double-check, but you are probably right.

Cheers
--
Manik Surtani
Lead, JBoss Cache
manik at jboss.org