Re: [JIRA] Commented: (CAY-922) Convert non-type-safe enums to Java 5 enums

From: Andrus Adamchik (
Date: Tue Nov 27 2007 - 12:58:17 EST

  • Next message: Malcolm Edgar (JIRA): "[JIRA] Created: (CAY-925) Support Entity/Table scope caching"

    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

    This archive was generated by hypermail 2.0.0 : Tue Nov 27 2007 - 12:58:53 EST