Ok, then everyone seems to be on board with the simple approach. Awesome!
FWIW I'd have to imagine this is close to what the VM does for annotations
anyway. So that's an extra win in my book.
On Thu, May 28, 2015 at 5:08 AM, Sanne Grinovero <sanne(a)hibernate.org>
wrote:
With that TCCL trick in place it seems it was possible to have the
module actually use a set of annotations provided by the user, to
override those (with same name) already provided by ORM. If that was
meant as a "feature" I'd be glad to see it killed.
I think the "intent" was just non-intent tbh. It just used TCCL rather
than allowing for specifying which ClassLoader to use because it was
"easier". Any expectation beyond that *should* break imho.
The above approach seems nicer as you already have the Class,
otherwise I'd prefer to see such helpers to always allow an
explicit
ClassLoader.
I don't think you have to worry about ORM requiring new versions of
HCANN occasionally, we all have to make changes to keep up anyway and
a version upgrade is easy enough.
Well especially if we are bumping the release family from 4.0 to 4.1
We did have a problem with recent "planet alignment"
efforts of
versions on other platforms though, which was caused by a significant
semantic change of a similar classloader improvement, and some people
had upgraded the micro version of HCANN without enough testing. As far
as I remember the dangerous upgrade was the upgrade from HCANN
4.0.1.Final to 4.0.5.Final, which breaks Hibernate ORM 4.2 within the
app server.
In retrospective we should have increased the minor version of HCANN,
so maybe you could do that now when fixing the TCCL issue?
Yep, I probably should have done that back when. I will do it now. 4.1?