gunnarmorling/hibernate-validator — comment on commit ecf1e6145171b0cae8e296a6645745cfd7f61960
File:  line 0
By hferentschik:

> Personally I don't really like the approach of storing the class name as string and instantiating it via reflection. While it does remove the hard
> coupling via the import statement the type of the implementation would still be known in the API class, thus actually leaving the dependency, at
> least from a semantical perspective.

I see your point. However, in this case it will always be our own known implementation. I am happy to have a "semantic" dependency in exchange for less code and avoidance of potential risks.

> Regarding the service loader approach, I wasn't aware of any problems under OSGi, as long as the resources to be loaded and the client using > the loader are contained in the same bundle. Do you have a link or some other information regarding the META-INF issue? I'll try to found out
> more on that.

It was TCK related - https://hibernate.onjira.com/browse/BVTCK-11
I think the easiest is to stay away from this. The less use of resource loading the better

> I'm starting to wish that we could base HV on CDI which would solve that kind of issues for us ;-)

:-)

> Another idea might be to demand Java 6 as runtime for HV which would give us the service loader for free from the JDK (without the qualifier
> functionality, though).

Sure, but as long as we don't have to enforce Java 6, I think we should try to avoid it.