[hibernate-dev] JPA Compliance

Part of 5.2 was merging the JPA contracts into the corresponding Hibernate ones. So, e.g., we no longer "wrap" a SessionFactory in an impl of EntityManagerFactory - instead, SessionFactory now extends EntityManagerFactory. This caused a few problems that we handled as they came up. In working on the JPA 2.2 compatibility testing, I see that there are a few more still that we need to resolve. Mostly they relate to JPA expecting exceptions in certain cases where Hibernate has historically been lenient. E.g., JPA says that calling EntityManagerFactory#close on an EMF that is already closed should result in an exception. Historically, calling SessionFactory#close on a SF that is already closed is simply ignored. Philosophical debates aside[1], we need to decide how we want to handle this situation such that we can throw the JPA-expected exceptions when needed. Do we simply change SF#close to match the JPA expectation? Or do we somehow make SF#close aware of JPA versus "native" use? This latter option was the intent of `SessionFactoryOptions#isJpaBootstrap` and we can certainly continue to use that as the basis of the solution here for other cases. This `#isJpaBootstrap` flag is controlled by the JPA bootstrap code. So if the EMF is created in either of the 2 JPA-defined bootstrap mechanisms, that flag is set to true. It's an ok solution, but it does have some limitations - mainly, there was previously a distinction between SF#close being called versus EMF#close being called (they were different classes, so they could react differently). Therefore, regardless of bootstrap mechanism, if the user unwrapped the EMF to a SF, they would always get the legacy SF behavior. So long story short, so we want to consider an alternative approach to deciding what to do in "some"[2] of these cases? Again, we clearly need these to throw the spec-mandated exceptions in certain "strict compliance" situations. The question really is how to do that. Should we: 1. just completely change the behavior to align with the spec? 2. change the behavior to match the spec *conditionally*, where that condition could be: 1. `#isJpaBootstrap` 2. some setting 3. some extension contract 4. something else? Thoughts? [1] It's not relevant e.g. that I think JPA is wrong here. We need to comply with the spec, at least in certain cases ;) [2] I say "some" here, because I think the spec is correct in some cases - for example, I think its clearly correct that a closed EMF throws an exception when `#createEntityManager` is called. Personally I think its questionable whether closing an already closed EMF should be an exception.