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

[Steve Ebersole]

(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
>