You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cayenne.apache.org by "Kevin Menard (JIRA)" <de...@cayenne.apache.org> on 2007/11/19 15:49:45 UTC
[JIRA] Created: (CAY-922) Convert non-type-safe enums to Java 5
enums
Convert non-type-safe enums to Java 5 enums
-------------------------------------------
Key: CAY-922
URL: https://issues.apache.org/cayenne/browse/CAY-922
Project: Cayenne
Issue Type: Task
Components: Cayenne Core Library
Affects Versions: 3.0
Reporter: Kevin Menard
Assignee: Andrus Adamchik
Fix For: 3.0
There are a few of these in the codebase. The most prominent one that comes to mind is PersistenceState.
I had messed around with this before we actually converted to Java 5 and it's actually not all that bad. As long as end users used the public static fields for comparisons (instead of integers), things should generally work. Of course, it would affect method parameters and return types as well, but those are quite easily fixed and probably par for a pre-release software course.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [JIRA] Commented: (CAY-922) Convert non-type-safe enums to
Java 5 enums
Posted by Kevin Menard <km...@servprise.com>.
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.
--
Kevin
On 11/27/07 12:58 PM, "Andrus Adamchik" <an...@objectstyle.org> 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" <an...@objectstyle.org>
>> 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
>> www.servprise.com +1 508.892.3823 x308
>>
>>
>
--
Kevin Menard
Servprise International, Inc.
Remote reboot & power control for network equipment
www.servprise.com +1 508.892.3823 x308
Re: [JIRA] Commented: (CAY-922) Convert non-type-safe enums to Java 5 enums
Posted by Andrus Adamchik <an...@objectstyle.org>.
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" <an...@objectstyle.org>
> 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
> www.servprise.com +1 508.892.3823 x308
>
>
Re: [JIRA] Commented: (CAY-922) Convert non-type-safe enums to
Java 5 enums
Posted by Kevin Menard <km...@servprise.com>.
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" <an...@objectstyle.org> 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
www.servprise.com +1 508.892.3823 x308
Re: [JIRA] Commented: (CAY-922) Convert non-type-safe enums to Java 5 enums
Posted by Andrus Adamchik <an...@objectstyle.org>.
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
Re: [JIRA] Commented: (CAY-922) Convert non-type-safe enums to
Java 5 enums
Posted by Kevin Menard <km...@servprise.com>.
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. This
strikes me as needing to be all-or-nothing to me.
I also think it's something that's going to have to be dealt with sooner or
later and is going to invariably break things for people somewhere. I'm
personally of the mindset that if I'm going to upgrade my code for 3.0, I
may as well do it all at once.
FWIW, the change to performQuery to return List<?> broke more of my code
than the enum changes would. I don't know how representative that is,
however.
On 11/27/07 4:53 AM, "Andrus Adamchik" <an...@objectstyle.org> wrote:
> I think converting PersistenceState to enum would result in a too
> serious breakage of backwards compatibility, so I am not so sure we
> should be changing this now. Maybe in 3.0 we just start by deprecating
> the "int" based API, and introducing enum based alternative without
> removing the old methods or changing the ivars?
>
> Andrus
--
Kevin Menard
Servprise International, Inc.
Remote reboot & power control for network equipment
www.servprise.com +1 508.892.3823 x308
Re: [JIRA] Commented: (CAY-922) Convert non-type-safe enums to Java 5 enums
Posted by Andrus Adamchik <an...@objectstyle.org>.
I think converting PersistenceState to enum would result in a too
serious breakage of backwards compatibility, so I am not so sure we
should be changing this now. Maybe in 3.0 we just start by deprecating
the "int" based API, and introducing enum based alternative without
removing the old methods or changing the ivars?
Andrus
On Nov 27, 2007, at 2:49 AM, Kevin Menard wrote:
> How do you want to handle this one? I can pitch in, but I don't
> want to be
> duplicating work that you're already doing. At the same time, I
> don't want
> to put the whole thing on you.
>
> --
> Kevin
>
> On 11/21/07 3:38 AM, "Andrus Adamchik (JIRA)" <de...@cayenne.apache.org>
> wrote:
>
>>
>> [
>> https://issues.apache.org/cayenne/browse/CAY-922?page=com.atlassian.jira.plugi
>> n.system.issuetabpanels:comment-tabpanel#action_12604 ]
>>
>> Andrus Adamchik commented on CAY-922:
>> -------------------------------------
>>
>> Converted lifecycle events to an enum. Hopefully with Modeler
>> support for
>> callbacks this shouldn't cause to much trouble for the existing
>> users.
>>
>>> Convert non-type-safe enums to Java 5 enums
>>> -------------------------------------------
>>>
>>> Key: CAY-922
>>> URL: https://issues.apache.org/cayenne/browse/CAY-922
>>> Project: Cayenne
>>> Issue Type: Task
>>> Components: Cayenne Core Library
>>> Affects Versions: 3.0
>>> Reporter: Kevin Menard
>>> Assignee: Andrus Adamchik
>>> Fix For: 3.0
>>>
>>>
>>> There are a few of these in the codebase. The most prominent one
>>> that comes
>>> to mind is PersistenceState.
>>> I had messed around with this before we actually converted to Java
>>> 5 and it's
>>> actually not all that bad. As long as end users used the public
>>> static
>>> fields for comparisons (instead of integers), things should
>>> generally work.
>>> Of course, it would affect method parameters and return types as
>>> well, but
>>> those are quite easily fixed and probably par for a pre-release
>>> software
>>> course.
>
> --
> Kevin Menard
> Servprise International, Inc.
> Remote reboot & power control for network equipment
> www.servprise.com +1 508.892.3823 x308
>
>
Re: [JIRA] Commented: (CAY-922) Convert non-type-safe enums to
Java 5 enums
Posted by Kevin Menard <km...@servprise.com>.
How do you want to handle this one? I can pitch in, but I don't want to be
duplicating work that you're already doing. At the same time, I don't want
to put the whole thing on you.
--
Kevin
On 11/21/07 3:38 AM, "Andrus Adamchik (JIRA)" <de...@cayenne.apache.org>
wrote:
>
> [
> https://issues.apache.org/cayenne/browse/CAY-922?page=com.atlassian.jira.plugi
> n.system.issuetabpanels:comment-tabpanel#action_12604 ]
>
> Andrus Adamchik commented on CAY-922:
> -------------------------------------
>
> Converted lifecycle events to an enum. Hopefully with Modeler support for
> callbacks this shouldn't cause to much trouble for the existing users.
>
>> Convert non-type-safe enums to Java 5 enums
>> -------------------------------------------
>>
>> Key: CAY-922
>> URL: https://issues.apache.org/cayenne/browse/CAY-922
>> Project: Cayenne
>> Issue Type: Task
>> Components: Cayenne Core Library
>> Affects Versions: 3.0
>> Reporter: Kevin Menard
>> Assignee: Andrus Adamchik
>> Fix For: 3.0
>>
>>
>> There are a few of these in the codebase. The most prominent one that comes
>> to mind is PersistenceState.
>> I had messed around with this before we actually converted to Java 5 and it's
>> actually not all that bad. As long as end users used the public static
>> fields for comparisons (instead of integers), things should generally work.
>> Of course, it would affect method parameters and return types as well, but
>> those are quite easily fixed and probably par for a pre-release software
>> course.
--
Kevin Menard
Servprise International, Inc.
Remote reboot & power control for network equipment
www.servprise.com +1 508.892.3823 x308
[JIRA] Commented: (CAY-922) Convert non-type-safe enums to Java 5
enums
Posted by "Andrus Adamchik (JIRA)" <de...@cayenne.apache.org>.
[ https://issues.apache.org/cayenne/browse/CAY-922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12604 ]
Andrus Adamchik commented on CAY-922:
-------------------------------------
Converted lifecycle events to an enum. Hopefully with Modeler support for callbacks this shouldn't cause to much trouble for the existing users.
> Convert non-type-safe enums to Java 5 enums
> -------------------------------------------
>
> Key: CAY-922
> URL: https://issues.apache.org/cayenne/browse/CAY-922
> Project: Cayenne
> Issue Type: Task
> Components: Cayenne Core Library
> Affects Versions: 3.0
> Reporter: Kevin Menard
> Assignee: Andrus Adamchik
> Fix For: 3.0
>
>
> There are a few of these in the codebase. The most prominent one that comes to mind is PersistenceState.
> I had messed around with this before we actually converted to Java 5 and it's actually not all that bad. As long as end users used the public static fields for comparisons (instead of integers), things should generally work. Of course, it would affect method parameters and return types as well, but those are quite easily fixed and probably par for a pre-release software course.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[JIRA] Commented: (CAY-922) Convert non-type-safe enums to Java 5
enums
Posted by "Andrus Adamchik (JIRA)" <de...@cayenne.apache.org>.
[ https://issues.apache.org/cayenne/browse/CAY-922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12605 ]
Andrus Adamchik commented on CAY-922:
-------------------------------------
Here is a list of candidates for conversion (with deprecation):
* PersistenceState
* QueryMetadata cache policies
* DeleteRule
> Convert non-type-safe enums to Java 5 enums
> -------------------------------------------
>
> Key: CAY-922
> URL: https://issues.apache.org/cayenne/browse/CAY-922
> Project: Cayenne
> Issue Type: Task
> Components: Cayenne Core Library
> Affects Versions: 3.0
> Reporter: Kevin Menard
> Assignee: Andrus Adamchik
> Fix For: 3.0
>
>
> There are a few of these in the codebase. The most prominent one that comes to mind is PersistenceState.
> I had messed around with this before we actually converted to Java 5 and it's actually not all that bad. As long as end users used the public static fields for comparisons (instead of integers), things should generally work. Of course, it would affect method parameters and return types as well, but those are quite easily fixed and probably par for a pre-release software course.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.