As far as I understand the frameworks, Black box are known for their ease of use since it is not necessary to understand what goes on inside it to use, and the white box > otherwise, a knowledge of the framework's internal framework is required for use.
In the case of Hibernate, which category is it in?
Well, I doubt that any purely black box framework exists for two simple reasons. The first one is due to leaky abstracts law and the second is that to use the framework, it is necessary to know at least some minimal of the classes or methods that exist in it so that you have some public API. Therefore, something completely black box is simply not usable.
But the question is how deeply this public (or even non-public) API gets in the way and how much the programmer should venture into it so the framework can be used. If the public API of a framework is relatively simple, cohesive, intuitive, provides a low coupling, and does not require in-depth knowledge about the framework's working details, then it is probably the most black that could be. There may even be deeper details of the public API for on-the-spot hackers to do tuning or in-house customizations for whatever reason, but we may disregard the case for internal public APIs for specific cases. The problem is when access to internal details or nuances of the framework's operation becomes essential for its use.
In any case, I consider it Hibernate relatively black box , since it is quite possible to program using Hibernate only JPA interfaces (ex: EntityManager ) and annotations. Obviously, you have to know how to use the JPA public API and know the meaning of annotations, and sometimes they can be a bit tricky. Also, from time to time some sordid detail of @ManyToMany relations, caches, fetching constraints of multiple entities related to a single record, or specific properties that you will need in persistence.xml appear as leaky abstractions or as details white box , and sometimes some internal details of Hibernate need to be used or at least understood. So I would classify it as mostly black box , something like a dark gray box .
A counterexample would be the case of Swing . There are a lot of methods to do all sorts of things, often in a non-intuitive, redundant way or with very complex interactions with each other. This results in super-heavy classes that accumulate multiple levels of inheritance by collecting hundreds of methods along the way. In addition, there are a number of complex details about Event Dispatch Thread, drawing design of components using Java2D, differences between heavyweight and lightweight components, complex ways to get and focus between elements, and a whole bunch of things that make using this API a difficult thing to be able to work with efficiently (and probably one of the main reasons why it never really took off, lagging behind its competitors and reduced to certain niches). So, Swing is mostly white box .
White box. After all you have access to the sources if you want to test in a totally transparent way. Black box for example are components of which you can not access or modify their behavior.
If your question was related to the General Theory of Systems or Tests, this is the correct answer.
