[hibernate-dev] BlobProxy, Reducing the amount of Proxies we rely on at runtime

[Sanne Grinovero]

Hi Steve,

thanks for confirming all that.

There's of course some risk that future JDBC drivers will break
things, but there's no breaking change in any version 9,10,11,12 ; I
believe it's unlikely and even if there's need for working around a
breaking change, we could evaluate various options. We might want to
re-introduce the usage of Proxy, but I suppose we'll also evaluate
alternatives which didn't exist 10y ago - like you mentioned one would
hope that the JDBC maintainer might introduce default method
implementations, or we could use Multi-Release-Jars to workaround JDK
specific defects. This is assuming the JDBC module isn't spin-off from
the JDK altogether.

It's all wild speculation today, so let's see.. either way I'm
confident that such challenges won't stop us; removing the proxy today
will help with both runtime efficiency and my prototypes with ahead of
time compilation.

I've pushed replacement code for the BlobProxy, will soon work on the
other ones you mentioned too.

Thanks,
Sanne

On Wed, 15 Aug 2018 at 21:28, Steve Ebersole <steve at hibernate.org> wrote:
>
> (Blob | Clob | NClob)Proxy are intended to do exactly what you said which is exactly what the comment says.  They were developed when we still base-lined on Java 4 or 5.  Java 6 added NClob and IIRC added methods to Blob and Clob.
>
> Hopefully if they add methods moving forward, they simply use default impls.  If not we'd potentially be in the same boat sometime down the road.  I'm not against removing them though if you wish.
>
> If we go this route of statically implementing JDBC contracts, then another one to consider is ResultSetWrapperProxy..
>
> On Wed, Aug 15, 2018 at 2:26 PM Sanne Grinovero <sanne at hibernate.org> wrote:
>>
>> I'm trying to understand if we could remove some of the usages of
>> `java.lang.reflect.Proxy`.
>>
>> Clearly it's a long journey and maybe we will never be able to remove
>> them all, but I would at least want to try avoiding most of their neet
>> at runtime - limiting their usage at bootstrap/configuration or other
>> similar "one time" contexts.
>>
>> We're all aware that these proxies have not been introduced lightly:
>> most are necessary or very useful; at least useful enough to prefer
>> having them to not having them; surely the tradeoffs have been
>> considered.
>>
>> So what I'm trying to understand now is if all the tradeoffs made in
>> the past are still actual; some of the related code is > 10 years old;
>> I could use some help with evaluating what could be safely removed.
>>
>> One example: org.hibernate.engine.jdbc.BlobProxy has the following comment:
>> "We use proxies here solely to avoid JDBC version incompatibilities."
>>
>> Today we require Java8 as baseline, and the `java.sql.Blob` did not
>> change in any more recent JDK (I just thouroughly diff-ed the
>> JDK8,9,10,11,12 on this package using Gunnar's jdk-api-diff tool).
>>
>> Would that be a reasonable candidate to replace the Proxy usage with a
>> plain implementation of the relevant interfaces? Clearly this implies
>> I'm betting that future JDKs will not break this again, still I'd
>> rather cleanup this usage today.
>>
>> 1 - Could I go ahead with that?
>>
>> 2 - Any more such cleanups come to mind?
>>
>> Thanks,
>> Sanne
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev