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

[Gail Badner]

Just an FYI, I had to fix a bug recently to support a JDK6 version of JDBC.
I believe it was Oracle JDBC.

On Thu, Aug 16, 2018 at 3:06 AM, Sanne Grinovero <sanne at hibernate.org>
wrote:

> 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
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>