cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrus Adamchik <>
Subject Re: [JIRA] Commented: (CAY-922) Convert non-type-safe enums to Java 5 enums
Date Tue, 27 Nov 2007 17:58:17 GMT
Also the users expect things to (mostly) work without code changes  
after upgrading a Cayenne jar. And this has been one of the strong  
points of Cayenne for many years. We received many praises about the  
ease of upgrade between major versions, and I don't want us to turn  
into ... ok, I won't be calling names of specific projects that  
completely rewrite their API from release to release, we all know them  
well :-) Now I am guilty myself of removing/changing stable API on a  
short notice occasionally, but generally we've been pretty good at  
keeping things backwards compatible and setting up proper deprecation  

So how about this - we can change internal implementation of  
CayenneDataObject and PersistentObject to actually store an enum field  
for state, but we still preserve the int methods with deprecated tag,  
returning enum ordinal? I think that's reasonable and addresses your  
concern about debugging.


On Nov 27, 2007, at 7:37 PM, Kevin Menard wrote:
> I'm not sure that our users are looking for more time.  While  
> certainly
> there are benefits by Cayenne's internals switching to Java 5, such  
> as the
> use of the new concurrent API, I'd imagine for a lot of users the  
> benefit of
> the move is the use of generics, enums, etc.  Taking the  
> PersistenceState
> for example . . . As an enum, this would save me a lot of  
> development time.
> I can't count how many times I've looked at an object in a debugger  
> and
> wasn't clear on the static int value for the persistence state and  
> didn't
> want to have to keep typing persistenceStateName() to find out.
> I've also run across code where things get casted to the wrong type  
> and the
> modified newObject() takes care of that problem.
> Anyway, the picture I'm trying to paint is that the code modifications
> necessary are minimal in comparison to the time that could be saved by
> making them.  This is the feeling I was getting off the user list as  
> well.
> Without going too far out on a limb, either, I'd imagine many are  
> using the
> milestones as a migratory period as well.
> On 11/27/07 12:20 PM, "Andrus Adamchik" <>  
> wrote:
>> On Nov 27, 2007, at 7:05 PM, Kevin Menard wrote:
>>> While we could use enums internally and preserve the int based API  
>>> for
>>> client use, it seems to be of dubious value.  We could deprecate it
>>> now I
>>> suppose, but introducing a new alternative to PersistenceState, that
>>> encodes
>>> the same info, just in a nicer manner, doesn't appear to gain us  
>>> much.
>> It gives the users more time (maybe a year, maybe more) to migrate
>> their code and a clear indication of what will be changed.
>>> FWIW, the change to performQuery to return List<?> broke more of my
>>> code
>>> than the enum changes would.
>> That's a good one... Impact of generics conversion on backwards
>> compatibility is not fully clear to me just yet. There is a
>> possibility that we may need to undo some of what we've done with it.
>> Andrus
> -- 
> Kevin Menard
> Servprise International, Inc.
> Remote reboot & power control for network equipment
>              +1 508.892.3823 x308

View raw message