You should contribute to
http://www.jcp.org/en/jsr/detail?id=305 ;-p
Steve Ebersole wrote:
Then we need @bad... ;)
-----Original Message-----
From: hibernate-dev-bounces(a)lists.jboss.org
[mailto:hibernate-dev-bounces@lists.jboss.org] On Behalf Of Max Rydahl
Andersen
Sent: Wednesday, August 30, 2006 3:01 PM
To: Christian Bauer; hibernate-dev(a)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.