cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevin Menard <>
Subject Re: [JIRA] Commented: (CAY-922) Convert non-type-safe enums to Java 5 enums
Date Thu, 29 Nov 2007 16:18:14 GMT
That sounds like a reasonable compromise to me.  In that case, a couple API
additions that return/set the enum type may be nice.  I'd have to see what
it would do to the API overall though.


On 11/27/07 12:58 PM, "Andrus Adamchik" <> wrote:

> 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
> period.
> 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.
> Andrus
> 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

Kevin Menard
Servprise International, Inc.
Remote reboot & power control for network equipment              +1 508.892.3823 x308

View raw message