Maybe I'm simply misunderstanding what you meant by "actually ignoring it in runtime".
To me, that sounded like you were going to change the behavior rather than just mark the method as @deprecated. On 5/5/08, Andrus Adamchik <[EMAIL PROTECTED]> wrote: > @deprecated is the way we always do it. That's sort of implied. > > Andrus > > > On May 5, 2008, at 8:26 PM, Mike Kienenberger wrote: > > > > I don't have any opinion on the actual method involved, but when you > > remove it, don't have it silently ignore the setting. Either get rid > > of it completely (so compilation/runtime breaks) or have it continue > > to function (@deprecated with BIG warnings in the logs). > > > > I'd hate to be a developer who misses this in the release notes after > > upgrading some application, and then tries to figure out why things > > don't work as expected any more... > > > > On 5/3/08, Andrus Adamchik <[EMAIL PROTECTED]> wrote: > > > > > > > > On May 3, 2008, at 6:57 PM, Andrus Adamchik wrote: > > > > > > > > > > > > > a set of queries with a large # of combinations of parameters, but all > > > > > > > searching the same underlying data set that rarely changes > > > > > > > > > > > > > > > > > On the other hand, even this example is better served by using query > cache. > > > For a marginal increase in memory use, it should give much better access > > > speed and refresh manageability. So I am out of examples of why > > > "setRefreshingObjects(false)" is good, but I'll wait for the comments > before > > > removing it. > > > > > > Andrus > > > > > > > > > > > >
