[hibernate-dev] JDK 10 Early Access b33 and JDK 8u162 Early Access b03 are available on jdk.java.net

[Rory O'Donnell]

Hi Sanne,

*JDK 10 Early Access  build 33 is available at : - **jdk.java.net/10/*


Notable changes since previous email.

JDK-8180019 
 - *javadoc treats 
failure to access a URL as an error , not a warning.*
If javadoc cannot access the contents of a URL provided with the -link 
or -linkoffline options,the tool will now report an error.
Previously, the tool continued with a warning, producing incorrect 
documentation output.

JDK-8175094 *- **The 
java.security.acl APIs are deprecated, for removal
* The deprecated java.security.acl APIs are now marked with 
forRemoval=true and are subject to removal in a future version of Java SE.

JDK-8175091  *- The 
java.security.{Certificate,Identity,IdentityScope,Signer} APIs are 
deprecated, for removal*
The deprecated java.security.{Certificate, Identity, IdentityScope, 
Signer} classes are now marked with forRemoval=true and are subject to 
removal in a future version of Java SE.

JDK 10 Schedule, Status & Features are available [1]


  Notes

  * OpenJDK EA binaries will be available at a later date.
  * Oracle has proposed: Newer version-string scheme for the Java SE
Platform and the JDK
  o Please see Mark Reinhold's proposal [2]

*JDK 8u162 Early Access build 03 is available at :- http://jdk.java.net/8/*



*Feedback* - If you have suggestions or encounter bugs, please submit 
them using the usual Java SE bug-reporting channel.
Be sure to include complete version information from the output of the 
|java --version| command.

Regards,
Rory

[1] http://openjdk.java.net/projects/jdk/10/
[2] http://mail.openjdk.java.net/pipermail/jdk-dev/2017-November/89.html

-- 
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland

___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] JPA Compliance

[Steve Ebersole]

Wrt to bag versus list, it's more the inability to fetch multiple bags,
which is perfectly legal in JPA but is an exception in Hibernate.

If have to search for the exact section, but afair to JPA a List defined as
OneToMany or ManyToMany has an implicit OrderColumn if one is not
provided.  And in this configuration Hibernate has no problem with the
multiple fetches.

On Tue, Nov 28, 2017, 5:19 AM Vlad Mihalcea  wrote:

> Makes sense. I think it's reasonable to add this since this is what a
> many-to-many table relationship looks like.
>
> But, it's ok to postpone it until 6.0.
>
> Vlad
>
> On Tue, Nov 28, 2017 at 12:38 PM, andrea boriero 
> wrote:
>
>> It is not about the order but about duplicates.
>>
>> With the following
>> class A {
>>List bsl
>> @JoinTable(name = "A_B",
>> joinColumns = @JoinColumn(name = "A_ID"),
>> inverseJoinColumns = @JoinColumn(name = "B_ID"),
>> )
>> @ManyToMany
>> public List getBs() {
>> return b;
>> }
>> }
>>
>> class *B*{
>> List as;
>> 
>> @ManyToMany(mappedBy = "bs", cascade=CascadeType.ALL)
>> public List getAs() {
>> return as;
>>  }
>> }
>>
>> and it seems JPA expects the JoinTable A_B to have a PK (A_ID,B_ID).
>>
>> On 28 November 2017 at 05:44, Vlad Mihalcea 
>> wrote:
>>
>>> I don't understand what is the requirement for the @Bag annotation and
>>> the  `hibernate.jpa.compliance=list` setting.
>>>
>>> From the JPA spec, only if we provide @OredrBy or @OrderColumn we get an
>>> ordered List.
>>> Otherwise, the order is undefined.
>>> Is there anything I'm missing about handling Lists according to the JPA
>>> spec?
>>>
>>> Vlad
>>>
>>> On Mon, Nov 27, 2017 at 11:29 PM, Steve Ebersole 
>>> wrote:
>>>
 So then how about the following:


1. Add a multi-valued setting to define various categories of JPA
compliance.  E.g. `hibernate.jpa.compliance` with multi-selectable 
 values
such as:
1. query (strict jpql compliance)
   2. txn (transaction handling per spec)
   3. close (multiple calls to EMF and EM #close methods)
   4. list (no bags)
   5. others?
   6. all (there should be some form of specifying all)
2. Add @Bag as an explicit declaration of a bag, even if
`hibernate.jpa.compliance=list` is specified - that setting just 
 controls
how List with no @OrderColumn is interpreted.  I vote to delay adding 
 that
until 6.0
3. Retain current behavior for "double close" calls unless "close"
compliance has been specified.
4. Keep current behavior unless "txn" compliance has been specified



 On Mon, Nov 27, 2017 at 4:54 AM andrea boriero 
 wrote:

> On 24 November 2017 at 17:39, Steve Ebersole 
> wrote:
>
>> Andrea, SF is a EMF.  Unwrapping simply returns the same instance.
>>
>
> yes but has you pointed out due to the bootstrapping the behaviour of
> the SF will be strict JPA compliant.
>
>>
>> Another thing I was discussing with Andrea in chat is possibly making
>> these multi-valued, or having multiple values for this.  I can't imagine
>> the FQN case is really all that appealing to a user.  I'm fairly certain 
>> a
>> user would rather simply say "yeah, treat transactions according the JPA
>> spec" as opposed to "here is a class I will provide that will tell will
>> treat transactions according to the JPA spec".
>>
>> We have started to identify some cases where we deviate from the
>> spec[1], such as:
>> * Strict query compliance.  As I mentioned earlier we do have such a
>> setting already for this in particular
>> * List versus Bag determination from mappings.
>> * Closed EMF (SF) handling
>> * EntityTransaction status checking - JPA says we should throw
>> exceptions whereas we just ignore the call.
>>
>> We need to decide also which of these we want to just change outright
>> versus controlling via a setting.
>>
>> * Setting
>> * Setting, or introduce a new @Bag annotation - the annotation option
>> is actually pretty appealing since often times the bag behavior is so
>> unexpected from users...
>>
>
> @Bag seems really a good idea to me but that means changing the
> current default behaviour, forcing users to change the code, so not sure 
> if
> we need also a setting.
>
>
>> * I think we should just change the behavior of calling EMF#close on
>> a closed EMF.  Any application that happens to be relying on us no-op'ing
>> this call can easily change that to protect the call with an `#isOpen`
>> check.  In fact I think we should change all of these to match the JPA
>> expectations such that it is an error to call any of the following: 
>> #close,
>> #getCache, #getMetamodel, #getCriteriaBuilder, #getProperties,
>> #getPersistenceUnitUtil, #createEntityManager.  To me t

Re: [hibernate-dev] JPA Compliance

[Vlad Mihalcea]

Makes sense. I think it's reasonable to add this since this is what a
many-to-many table relationship looks like.

But, it's ok to postpone it until 6.0.

Vlad

On Tue, Nov 28, 2017 at 12:38 PM, andrea boriero 
wrote:

> It is not about the order but about duplicates.
>
> With the following
> class A {
>List bsl
> @JoinTable(name = "A_B",
> joinColumns = @JoinColumn(name = "A_ID"),
> inverseJoinColumns = @JoinColumn(name = "B_ID"),
> )
> @ManyToMany
> public List getBs() {
> return b;
> }
> }
>
> class *B*{
> List as;
> 
> @ManyToMany(mappedBy = "bs", cascade=CascadeType.ALL)
> public List getAs() {
> return as;
>  }
> }
>
> and it seems JPA expects the JoinTable A_B to have a PK (A_ID,B_ID).
>
> On 28 November 2017 at 05:44, Vlad Mihalcea 
> wrote:
>
>> I don't understand what is the requirement for the @Bag annotation and
>> the  `hibernate.jpa.compliance=list` setting.
>>
>> From the JPA spec, only if we provide @OredrBy or @OrderColumn we get an
>> ordered List.
>> Otherwise, the order is undefined.
>> Is there anything I'm missing about handling Lists according to the JPA
>> spec?
>>
>> Vlad
>>
>> On Mon, Nov 27, 2017 at 11:29 PM, Steve Ebersole 
>> wrote:
>>
>>> So then how about the following:
>>>
>>>
>>>1. Add a multi-valued setting to define various categories of JPA
>>>compliance.  E.g. `hibernate.jpa.compliance` with multi-selectable values
>>>such as:
>>>1. query (strict jpql compliance)
>>>   2. txn (transaction handling per spec)
>>>   3. close (multiple calls to EMF and EM #close methods)
>>>   4. list (no bags)
>>>   5. others?
>>>   6. all (there should be some form of specifying all)
>>>2. Add @Bag as an explicit declaration of a bag, even if
>>>`hibernate.jpa.compliance=list` is specified - that setting just
>>>controls how List with no @OrderColumn is interpreted.  I vote to delay
>>>adding that until 6.0
>>>3. Retain current behavior for "double close" calls unless "close"
>>>compliance has been specified.
>>>4. Keep current behavior unless "txn" compliance has been specified
>>>
>>>
>>>
>>> On Mon, Nov 27, 2017 at 4:54 AM andrea boriero 
>>> wrote:
>>>
 On 24 November 2017 at 17:39, Steve Ebersole 
 wrote:

> Andrea, SF is a EMF.  Unwrapping simply returns the same instance.
>

 yes but has you pointed out due to the bootstrapping the behaviour of
 the SF will be strict JPA compliant.

>
> Another thing I was discussing with Andrea in chat is possibly making
> these multi-valued, or having multiple values for this.  I can't imagine
> the FQN case is really all that appealing to a user.  I'm fairly certain a
> user would rather simply say "yeah, treat transactions according the JPA
> spec" as opposed to "here is a class I will provide that will tell will
> treat transactions according to the JPA spec".
>
> We have started to identify some cases where we deviate from the
> spec[1], such as:
> * Strict query compliance.  As I mentioned earlier we do have such a
> setting already for this in particular
> * List versus Bag determination from mappings.
> * Closed EMF (SF) handling
> * EntityTransaction status checking - JPA says we should throw
> exceptions whereas we just ignore the call.
>
> We need to decide also which of these we want to just change outright
> versus controlling via a setting.
>
> * Setting
> * Setting, or introduce a new @Bag annotation - the annotation option
> is actually pretty appealing since often times the bag behavior is so
> unexpected from users...
>

 @Bag seems really a good idea to me but that means changing the current
 default behaviour, forcing users to change the code, so not sure if we need
 also a setting.


> * I think we should just change the behavior of calling EMF#close on a
> closed EMF.  Any application that happens to be relying on us no-op'ing
> this call can easily change that to protect the call with an `#isOpen`
> check.  In fact I think we should change all of these to match the JPA
> expectations such that it is an error to call any of the following: 
> #close,
> #getCache, #getMetamodel, #getCriteriaBuilder, #getProperties,
> #getPersistenceUnitUtil, #createEntityManager.  To me these all seem 
> pretty
> reasonable.  And in fact I think we used to handle this all properly from
> the EMF side.  I think we just lost that behavior when we changed to have
> our contracts extend the JPA ones since we kept the legacy Hibernate
> behavior in SessionFactory.
>

 I do not like the EMF#close behaviour, probably a prefer a separate
 setting for this.


> * This one I am very undecided.  I can see very valid arguments for
> each.
>

 probably for such case a setting may be a good option.

>
> [

Re: [hibernate-dev] JPA Compliance

[andrea boriero]

It seems fine to me and I agree to delay the @Bag to 6.0.

On 27 November 2017 at 21:29, Steve Ebersole  wrote:

> So then how about the following:
>
>
>1. Add a multi-valued setting to define various categories of JPA
>compliance.  E.g. `hibernate.jpa.compliance` with multi-selectable values
>such as:
>1. query (strict jpql compliance)
>   2. txn (transaction handling per spec)
>   3. close (multiple calls to EMF and EM #close methods)
>   4. list (no bags)
>   5. others?
>   6. all (there should be some form of specifying all)
>2. Add @Bag as an explicit declaration of a bag, even if
>`hibernate.jpa.compliance=list` is specified - that setting just
>controls how List with no @OrderColumn is interpreted.  I vote to delay
>adding that until 6.0
>3. Retain current behavior for "double close" calls unless "close"
>compliance has been specified.
>4. Keep current behavior unless "txn" compliance has been specified
>
>
>
> On Mon, Nov 27, 2017 at 4:54 AM andrea boriero 
> wrote:
>
>> On 24 November 2017 at 17:39, Steve Ebersole  wrote:
>>
>>> Andrea, SF is a EMF.  Unwrapping simply returns the same instance.
>>>
>>
>> yes but has you pointed out due to the bootstrapping the behaviour of the
>> SF will be strict JPA compliant.
>>
>>>
>>> Another thing I was discussing with Andrea in chat is possibly making
>>> these multi-valued, or having multiple values for this.  I can't imagine
>>> the FQN case is really all that appealing to a user.  I'm fairly certain a
>>> user would rather simply say "yeah, treat transactions according the JPA
>>> spec" as opposed to "here is a class I will provide that will tell will
>>> treat transactions according to the JPA spec".
>>>
>>> We have started to identify some cases where we deviate from the
>>> spec[1], such as:
>>> * Strict query compliance.  As I mentioned earlier we do have such a
>>> setting already for this in particular
>>> * List versus Bag determination from mappings.
>>> * Closed EMF (SF) handling
>>> * EntityTransaction status checking - JPA says we should throw
>>> exceptions whereas we just ignore the call.
>>>
>>> We need to decide also which of these we want to just change outright
>>> versus controlling via a setting.
>>>
>>> * Setting
>>> * Setting, or introduce a new @Bag annotation - the annotation option is
>>> actually pretty appealing since often times the bag behavior is so
>>> unexpected from users...
>>>
>>
>> @Bag seems really a good idea to me but that means changing the current
>> default behaviour, forcing users to change the code, so not sure if we need
>> also a setting.
>>
>>
>>> * I think we should just change the behavior of calling EMF#close on a
>>> closed EMF.  Any application that happens to be relying on us no-op'ing
>>> this call can easily change that to protect the call with an `#isOpen`
>>> check.  In fact I think we should change all of these to match the JPA
>>> expectations such that it is an error to call any of the following: #close,
>>> #getCache, #getMetamodel, #getCriteriaBuilder, #getProperties,
>>> #getPersistenceUnitUtil, #createEntityManager.  To me these all seem pretty
>>> reasonable.  And in fact I think we used to handle this all properly from
>>> the EMF side.  I think we just lost that behavior when we changed to have
>>> our contracts extend the JPA ones since we kept the legacy Hibernate
>>> behavior in SessionFactory.
>>>
>>
>> I do not like the EMF#close behaviour, probably a prefer a separate
>> setting for this.
>>
>>
>>> * This one I am very undecided.  I can see very valid arguments for each.
>>>
>>
>> probably for such case a setting may be a good option.
>>
>>>
>>> [1] we really ought to start keeping a list of these.  I have started
>>> adding them to the migration guide.  Just as a list of things we need to
>>> support configuring or switch to the JPA "way".
>>>
>>> On Fri, Nov 17, 2017 at 11:06 AM andrea boriero 
>>> wrote:
>>>
 I think for 5.3 it's still fine to rely on isJpaBootstrap may be
 documenting that a SF obtained  from unwrapping an EMF will conform to the
 JPA spec in term of exceptions.

 On 16 November 2017 at 21:09, Vlad Mihalcea 
 wrote:

> When I said multiple modes, I was thinking of defining all these
> situations
> In some interface which declares methods like:
>
> boolean throwsExceptionWhenClosingAClosedEMF()
>
> The interface can have two implementations for Strict JPA and Native
> mode.
>
> However, the setting could take the FQN of the interface
> implementation, so
> a user can define those compatibility methods according to their needs.
>
> E.g. Maybe someone wants the Strict JPA mode but with just 2
> differences;
>
> - don't throw exception when closing the ENG twice
> - use the native Hibernate FlushMode.AUTO instead of the JPA one.
>
> Vlad
>
> On 16 Nov 2017 10:49 pm, "Steve Ebersole"  wrote:

Re: [hibernate-dev] JPA Compliance

[andrea boriero]

It is not about the order but about duplicates.

With the following
class A {
   List bsl
@JoinTable(name = "A_B",
joinColumns = @JoinColumn(name = "A_ID"),
inverseJoinColumns = @JoinColumn(name = "B_ID"),
)
@ManyToMany
public List getBs() {
return b;
}
}

class *B*{
List as;

@ManyToMany(mappedBy = "bs", cascade=CascadeType.ALL)
public List getAs() {
return as;
 }
}

and it seems JPA expects the JoinTable A_B to have a PK (A_ID,B_ID).

On 28 November 2017 at 05:44, Vlad Mihalcea  wrote:

> I don't understand what is the requirement for the @Bag annotation and the
>  `hibernate.jpa.compliance=list` setting.
>
> From the JPA spec, only if we provide @OredrBy or @OrderColumn we get an
> ordered List.
> Otherwise, the order is undefined.
> Is there anything I'm missing about handling Lists according to the JPA
> spec?
>
> Vlad
>
> On Mon, Nov 27, 2017 at 11:29 PM, Steve Ebersole 
> wrote:
>
>> So then how about the following:
>>
>>
>>1. Add a multi-valued setting to define various categories of JPA
>>compliance.  E.g. `hibernate.jpa.compliance` with multi-selectable values
>>such as:
>>1. query (strict jpql compliance)
>>   2. txn (transaction handling per spec)
>>   3. close (multiple calls to EMF and EM #close methods)
>>   4. list (no bags)
>>   5. others?
>>   6. all (there should be some form of specifying all)
>>2. Add @Bag as an explicit declaration of a bag, even if
>>`hibernate.jpa.compliance=list` is specified - that setting just
>>controls how List with no @OrderColumn is interpreted.  I vote to delay
>>adding that until 6.0
>>3. Retain current behavior for "double close" calls unless "close"
>>compliance has been specified.
>>4. Keep current behavior unless "txn" compliance has been specified
>>
>>
>>
>> On Mon, Nov 27, 2017 at 4:54 AM andrea boriero 
>> wrote:
>>
>>> On 24 November 2017 at 17:39, Steve Ebersole 
>>> wrote:
>>>
 Andrea, SF is a EMF.  Unwrapping simply returns the same instance.

>>>
>>> yes but has you pointed out due to the bootstrapping the behaviour of
>>> the SF will be strict JPA compliant.
>>>

 Another thing I was discussing with Andrea in chat is possibly making
 these multi-valued, or having multiple values for this.  I can't imagine
 the FQN case is really all that appealing to a user.  I'm fairly certain a
 user would rather simply say "yeah, treat transactions according the JPA
 spec" as opposed to "here is a class I will provide that will tell will
 treat transactions according to the JPA spec".

 We have started to identify some cases where we deviate from the
 spec[1], such as:
 * Strict query compliance.  As I mentioned earlier we do have such a
 setting already for this in particular
 * List versus Bag determination from mappings.
 * Closed EMF (SF) handling
 * EntityTransaction status checking - JPA says we should throw
 exceptions whereas we just ignore the call.

 We need to decide also which of these we want to just change outright
 versus controlling via a setting.

 * Setting
 * Setting, or introduce a new @Bag annotation - the annotation option
 is actually pretty appealing since often times the bag behavior is so
 unexpected from users...

>>>
>>> @Bag seems really a good idea to me but that means changing the current
>>> default behaviour, forcing users to change the code, so not sure if we need
>>> also a setting.
>>>
>>>
 * I think we should just change the behavior of calling EMF#close on a
 closed EMF.  Any application that happens to be relying on us no-op'ing
 this call can easily change that to protect the call with an `#isOpen`
 check.  In fact I think we should change all of these to match the JPA
 expectations such that it is an error to call any of the following: #close,
 #getCache, #getMetamodel, #getCriteriaBuilder, #getProperties,
 #getPersistenceUnitUtil, #createEntityManager.  To me these all seem pretty
 reasonable.  And in fact I think we used to handle this all properly from
 the EMF side.  I think we just lost that behavior when we changed to have
 our contracts extend the JPA ones since we kept the legacy Hibernate
 behavior in SessionFactory.

>>>
>>> I do not like the EMF#close behaviour, probably a prefer a separate
>>> setting for this.
>>>
>>>
 * This one I am very undecided.  I can see very valid arguments for
 each.

>>>
>>> probably for such case a setting may be a good option.
>>>

 [1] we really ought to start keeping a list of these.  I have started
 adding them to the migration guide.  Just as a list of things we need to
 support configuring or switch to the JPA "way".

 On Fri, Nov 17, 2017 at 11:06 AM andrea boriero 
 wrote:

> I think for 5.3 it's still fine to rely on isJpaBootstrap may be
> documenting that a SF obtained  from