[hibernate-dev] Connection proxying
Max Rydahl Andersen
max.andersen at jboss.com
Thu Aug 31 01:26:24 EDT 2006
> You should contribute to http://www.jcp.org/en/jsr/detail?id=305 ;-p
>
> Steve Ebersole wrote:
>> Then we need @bad... ;)
:)
but seriously @deprecate is not only "a going away" marker.
From
http://java.sun.com/j2se/1.4.2/docs/guide/misc/deprecation/deprecation.html:
"Valid reasons for wishing one's users to migrate to the new API include:
- the old API is insecure, buggy, or highly inefficient - the old API is
going away in a future release - the old API encourages very bad coding
practices Not all of these reasons are of equal weight, yet deprecation is
a reasonable (though not mandatory) choice in all these cases. Therefore,
the use of deprecated APIs can never be made a hard error by default.
Also, the deprecation comments need to help the user decide when to move
to the new API, and so should briefly mention the technical reasons for
deprecation."
I would say .connection() falls in some of those categories and should
only be used in very few cases (until we provide alternatives for the
important "patterns").
/max
>> -----Original Message-----
>> From: hibernate-dev-bounces at lists.jboss.org
>> [mailto:hibernate-dev-bounces at lists.jboss.org] On Behalf Of Max Rydahl
>> Andersen
>> Sent: Wednesday, August 30, 2006 3:01 PM
>> To: Christian Bauer; hibernate-dev at lists.jboss.org
>> Subject: Re: [hibernate-dev] Connection proxying
>>
>>
>>
>>>> The question was simply whether exposing the
>>>> Work/command APIs justify removal of the connection() method from the
>>>> perspective of using it for direct JDBC work. I do not know that
>>>>
>> answer
>>
>>>> to that. Unfortunately, I suspect it does not and that we will need
>>>>
>> to
>>
>>>> keep connection() around; but one can dream.
>>>>
>>> I'd keep connection() around and not deprecate it, no matter what
>>>
>> better
>>> solutions we find for the various use cases. We can hide it in the API
>>>
>>
>>
>>> documentation and like we do now, document the problems. It's just too
>>>
>>
>>
>>> useful to deprecate it. Also remember the public riots when JDO 1.0
>>> didn't have an easy way to get a JDBC connection.
>>>
>>
>> I agree this is also a reason/same reason to keep it, but I do think (at
>>
>> least for now ;) that
>> @deprecate would make sense.
>>
>> Not @deprecate as in "it will be removed", but @deprecate as how it is
>> done for e.g. Date and some of its constructors.
>>
>> Those constructors are still around because they are usable in some
>> contexts but with @deprecate it is made explicit and documented
>> that they are 'bad' and what the consequences are for using it.
>>
>>
--
--
Max Rydahl Andersen
callto://max.rydahl.andersen
Hibernate
max at hibernate.org
http://hibernate.org
JBoss a division of Red Hat
max.andersen at jboss.com
More information about the hibernate-dev
mailing list