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

[Rory O'Donnell]

Thanks for the update Sanne.

Rgds, Rory


On 29/11/2017 12:47, Sanne Grinovero wrote:
> Hi Rory,
>
> sorry we'll have to skip this round of testing: essential Maven
> plugins are still unusable.
>   -https://issues.apache.org/jira/browse/SUREFIRE-1439
>
> We'll resume testing as soon as possible.
>
> Regards,
> Sanne
>
>
>
> On 28 November 2017 at 15:40, Rory O'Donnell  wrote:
>> 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

-- 
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

[hibernate-dev] Why does the disassembledStateText in StandardCacheEntryImpl build from the actual state[] and not from disassembledState[]?

[Vlad Mihalcea]

Hi,

While working on fixing https://hibernate.atlassian.net/browse/HHH-12107,
I realized that the way we create the disassembledStateText property of the
StandardCacheEntryImpl object does not resemble the name of the attribute.

Now, I wonder why we don't build the disassembledStateText from
disassembledState?

Currently, the disassembledStateText is built from the hydrated state
instead. Is there any reason why we do that? Is it for correlating the
disassembledState Object array that's contained in the
StandardCacheEntryImpl object with the original entity hydrated state?

The problem with HHH-12107 was that, from structured 2nd-level cache where
we content is saved as a Map, when we reconstruct the
StandardCacheEntryImpl object
from the Map we get from the 2nd-level cache, we only know the
disassembledState when building the StandardCacheEntryImpl object reference.
So, we can't construct the same disassembledStateText value until we have
the actual hydrated state.

We would not have this issue if the disassembledStateText was built from
the disassembledState Object array via a call to Arrays.deepToString. But
changing the way we build the disassembledStateText is problematic if the
2nd-level cache provider relies on that property.

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