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