[hibernate-dev] Preparations for HCANN 7.0

[Sanne Grinovero]

Hi all,

I'd like to release Hibernate Commons Annotations 7.0 soon.

Since we have intentions to get rid of it, I'm assuming there is no
interest in resolving any of the open issues?

The main reason for me to release a new major version is that we're
ready to publish this relincesed as ASL2: it's a small step towards
the bigger relicensing plan, and in that sense I'd prefer to keep it
as a drop-in replacement so that other projects can swap this w/o much
hassle (if not removing altogether).

Please let me know; if I don't hear any objections I'd like to release
it next week.

Thanks,
Sanne
___
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
Privacy Statement: https://www.redhat.com/en/about/privacy-policy
List Archives: 
https://lists.jboss.org/archives/list/hibernate-dev@lists.jboss.org/message/DAYYFWQESGIDE3GCDXLYYM3SSPBFU5WB/

[hibernate-dev] Re: [hibernate-announce] Hibernate Search: 7.0.0.Beta1 released

[Sanne Grinovero]

This is awesome, congratulations all!


On Wed, 6 Sept 2023 at 19:18, Yoann Rodiere  wrote:

> Hello,
>
> Yesterday, we published a new Beta release for Hibernate Search:
> 7.0.0.Beta1.
>
> This version uses JDK 11 as a baseline, switches to Jakarta EE entirely,
> upgrades to Lucene 9 and more.
>
> See our blog for more information:
>
> https://in.relation.to/2023/09/05/hibernate-search-7-0-0-Beta1/
>
> Cheers,
>
> Yoann Rodiere
> Hibernate team
> ___
> hibernate-announce mailing list -- hibernate-annou...@lists.jboss.org
> To unsubscribe send an email to hibernate-announce-le...@lists.jboss.org
> Privacy Statement: https://www.redhat.com/en/about/privacy-policy
> List Archives:
> https://lists.jboss.org/archives/list/hibernate-annou...@lists.jboss.org/message/QZTRUFAYIIDQVYVP4H7P3MLZ3PCQ45BC/
>
___
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
Privacy Statement: https://www.redhat.com/en/about/privacy-policy
List Archives: 
https://lists.jboss.org/archives/list/hibernate-dev@lists.jboss.org/message/JYGC4V5X4RF3JIKI5JBY7BPXO7RCYP4D/

[hibernate-dev] Release, amended: Hibernate ORM 5.6.14.Final

[Sanne Grinovero]

Hi all,
the nasty issue that affected yesterday's release is fixed now.

Please enjoy 5.6.14.Final, this time for real :)
 - https://in.relation.to/2022/11/04/hibernate-orm-5614/

Regards,
Sanne
___
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[hibernate-dev] Re: Release: Hibernate ORM 5.6.13.Final

[Sanne Grinovero]

Apologies, a critical bug was identified just after the release process:
 - https://hibernate.atlassian.net/browse/HHH-15662

I'll start a release for 5.6.14.Final today as soon as we have
confidence this is properly fixed.

Sanne

On Thu, 3 Nov 2022 at 22:20, Sanne Grinovero  wrote:
>
> Hi all,
>
> Hibernate ORM 5.6.13.Final is now available.
>
> It contains both important fixes and strong performance optimisations;
> for details
> please check the full announcement on the blog:
>  - https://in.relation.to/2022/11/03/hibernate-orm-5613/
>
> Regards,
> Sanne
___
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[hibernate-dev] Release: Hibernate ORM 5.6.13.Final

[Sanne Grinovero]

Hi all,

Hibernate ORM 5.6.13.Final is now available.

It contains both important fixes and strong performance optimisations;
for details
please check the full announcement on the blog:
 - https://in.relation.to/2022/11/03/hibernate-orm-5613/

Regards,
Sanne
___
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[hibernate-dev] Double release: Hibernate ORM 5.6.9.Final and Hibernate Reactive 1.1.5.Final

[Sanne Grinovero]

Hi all,

we released both projects;

for details see:
 - https://in.relation.to/2022/05/16/hibernate-orm-569-and-reactive-115/

In particular if you're using Hibernate Reactive via the
'Stage.SessionFactory' API I would strongly recommend upgrading.

Regards
___
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[hibernate-dev] Reminder: where is all technical brainstorming?

[Sanne Grinovero]

Hi all,

a reminder for everyone out there not following closely on all activities:

our day to day development discussions are happening on zulip, an OSS chat
platform;
instructions and links are listed on the website:
 - http://hibernate.org/community/

In addition, the Hibernate ORM project is extensively using the Github
Discussions area for design decision making:
https://github.com/hibernate/hibernate-orm/discussions

Please feel free to register for appropriate notifications on github.

Thanks
___
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[hibernate-dev] Re: Hibernate ORM 6.0 Final

[Sanne Grinovero]

Now that's huge news :)  Congratulations all!

On Fri, 1 Apr 2022 at 10:34, Yoann Rodiere  wrote:

> Congratulations to you all! That's a huge milestone, after literal years of
> work.
>
> Also, thanks for asking for opinions and helping with upgrades in Search
> along the way, it really made keeping up with the Alphas/Betas/CRs easier.
>
> Now onwards to 6.0.1 :D
>
> Yoann Rodière
> Hibernate Team
> yo...@hibernate.org
>
>
> On Thu, 31 Mar 2022 at 21:35, Steve Ebersole  wrote:
>
> > Hibernate ORM 6.0 Final has been released -
> > https://in.relation.to/2022/03/31/orm-60-final/
> > ___
> > hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
> > To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
> > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
> ___
> hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
> To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[hibernate-dev] Re: JDK 18 General Availability, and oracle-actions/setup-java

[Sanne Grinovero]

Hi David,

Congratulations!
And thank you for the acknowledgement of Yoann's efforts, that's nice :)

Sanne

On Mon, 28 Mar 2022 at 16:28, David Delabassee 
wrote:

> Greetings!
>
> JDK 18 has been released (General Availability) on March 22nd as
> planned, the release cadence is working like clockwork! As a small token
> of gratitude, some of you have been specifically acknowledged in the
> "The Arrival of Java 18" announcement [1]. On behalf of the entire team,
> let me extend our thanks to all of you.
>
> With JDK 18 released, the focus should now be on making sure your
> project(s) compile and work on JDK 19. As always, if you face any issue
> with early-access builds of JDK 19 please let us know. To help you in
> this task, we have just released a GitHub action to install the OpenJDK
> Early-Access builds. For more information, please check the heads-up below.
>
> I'll conclude with a short teaser, i.e. JavaOne is Back! [2] Stay tuned
> for more details.
>
> [1] https://inside.java/2022/03/22/the-arrival-of-java18/
> [2] https://www.oracle.com/cloudworld/javaone/
>
>
> ## Heads-Up: oracle-actions/setup-java
>
> To help you test your project(s), we have released a GitHub Action [3]
> to download and install various JDK builds produced by Oracle. In
> addition to the latest OpenJDK GA builds (GPL v2 W/CPE) and the Oracle
> JDK builds (NFTC license), this action can also download and install
> OpenJDK early-access builds, and early-access builds of OpenJDK projects
> (ex. Project Loom, Project Valhalla, etc.).
>
> When doing tests using EA builds, it is key to always use the upstream
> EA builds from jdk.java.net as issues should be logged against those
> upstream builds, and ideally against a specific build version. This
> GitHub action is actively following the OpenJDK EA builds releases.
> Please make sure to check the announcement [4] for more details, and
> short FAQ.
>
> To help you isolate regression between different EA builds, we are
> working to add support for archived builds. If you have feedback, please
> either issue the Issue tracker [5] or just send me a mail.
>
> [3]
>
> https://github.com/marketplace/actions/setup-java-development-kits-built-by-oracle
> [4] https://inside.java/2022/03/11/setup-java/
> [5] https://github.com/oracle-actions/setup-java/issues
>
>
> ## General Availability of Java 18 / JDK 18
>
> JDK 18 is now Generally Available [6]. The OpenJDK builds which are
> provided under the GNU General Public License v2, with the Classpath
> Exception are available [7], the JDK 18 Release Notes are also available
> [8].
>
> [6] https://mail.openjdk.java.net/pipermail/jdk-dev/2022-March/006458.html
> [7] https://jdk.java.net/18/
> [8] https://jdk.java.net/18/release-notes
>
> Along with hundreds of smaller enhancements and over a thousand bug
> fixes, JDK 18 includes following JEPs:
> - JEP 400: UTF-8 by Default
> - JEP 408: Simple Web Server
> - JEP 413: Code Snippets in Java API Documentation
> - JEP 416: Reimplement Core Reflection with Method Handles
> - JEP 417: Vector API (Third Incubator)
> - JEP 418: Internet-Address Resolution SPI
> - JEP 419: Foreign Function & Memory API (Second Incubator)
> - JEP 420: Pattern Matching for switch (Second Preview)
> - JEP 421: Deprecate Finalization for Removal
>
> Thanks to everyone who contributed to JDK 18, whether by designing and
> implementing features or enhancements, by fixing bugs, or by downloading
> and testing the early-access builds.
>
>
> ## JDK 19 Early-Access builds
>
> JDK 19 Early-Access builds 15 are now available [9], and are provided
> under the GNU General Public License v2, with the Classpath Exception.
> The Release Notes are also available [10].
>
> [9] https://jdk.java.net/19/
> [10] https://jdk.java.net/19/release-notes
>
> ### JEPs targeted to JDK 19, so far:
> - JEP 422: Linux/RISC-V Port https://openjdk.java.net/jeps/422
>
> ### Recent changes that maybe of interest:
> - JDK-8283415: Update java.lang.ref to use sealed classes
> - JDK-8280494: (D)TLS signature schemes
> - JDK-8282081: java.time.DateTimeFormatter: wrong definition of symbol F
> - JDK-8281181: Do not use CPU Shares to compute active processor count
> - JDK-7192189: Support endpoint identification algorithm in RFC 6125
> - JDK-8277474: jarsigner does not check if algorithm parameters are
> disabled
> - JDK-8280357: If the users home directory is invalid, system property
> user.home is set to $HOME
> - JDK-8277204: Implement PAC-RET branch protection on Linux/AArch64
> - JDK-8282411: Add useful predicates to ElementKind
> - JDK-8282131: java.time.ZoneId should be a sealed abstract class
> - JDK-8281375: Accelerate bitCount operation for AVX2 and AVX512 target
>
>
> ## Topics of Interest:
>
> - “Java 18 is Here!” - Inside Java Podcast
> https://inside.java/2022/03/22/podcast-023/
>
> - “The Simple Web Server” - Inside Java Podcast
> https://inside.java/2022/03/04/podcast-022/
>
> - “Finalization Deprecation” - Inside Java Podcast
> 

[hibernate-dev] Released: Hibernate ORM 5.6.7.Final

[Sanne Grinovero]

Dear all,

Hibernate ORM 5.6.7.Final is now available.

For more details, see
 - https://in.relation.to/2022/03/18/hibernate-orm-567/

-- Sanne
___
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[hibernate-dev] Release: Hibernate ORM 5.6.5.Final

[Sanne Grinovero]

Hi all,

version 5.6.5.Final is now available, bringing a single fix and improved
compatibility with the latest H2 release.

Please see the blog for details:
https://in.relation.to/2022/01/26/hibernate-orm-565/

Thanks
___
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[hibernate-dev] Re: Hibernate ORM 5.6.4.Final has been released

[Sanne Grinovero]

Excellent! Many thanks for the quick fix and release Christian.

On Wed, 19 Jan 2022 at 09:17, Christian Beikov 
wrote:

> Hello all,
>
> we've released Hibernate ORM version 5.6.4.Final !
>
> For details:
> https://in.relation.to/2022/01/19/hibernate-orm-564/
>
> Thanks all!
> Christian
> ___
> hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
> To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[hibernate-dev] Hibernate ORM 5.6.2.Final now available

[Sanne Grinovero]

Hi all,

version 5.6.2.Final is now available in Maven Central.

Please check it out:
 - https://in.relation.to/2021/12/08/hibernate-orm-562/

Happy upgrading
___
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[hibernate-dev] Re: Thank you! JDK 18 Early Access build 20 is now available

[Sanne Grinovero]

Hi Rory,

Best of wishes for your retirement! We'll miss you, and thanks a lot for
all you did for our community, this program has been brilliant.

I still have fond memories of our conversations at FOSDEM :) Was hoping
we'd do it again in the future.

Hi David, good to see you involved here as well :)

Cheers,
Sanne


On Tue, 26 Oct 2021 at 17:15, Rory O'Donnell 
wrote:

> Hi Sanne & Yoann,
>
> *Thank you.*
>
> I'm retiring at the end of November 2021, it's time to spend more time
> with the family.
>
> We started the Quality Outreach back in October 2014.  We now have 170+
> projects participating.
> Thank you for taking the time to provide Testing feedback , excellent
> bugs and support throughout
> the last seven years.
>
> It's been a pleasure working with you. I am delighted to say that the
> program will continue
> with the support of the Java DevRel Team, with David Delabassee as your
> contact. David has
> been assisting with on-boarding new projects for the last couple of years.
>
> All the best, Rory
>
>
> *OpenJDK 18Early Access build 20is now available
> at**https://jdk.java.net/18/ **
> *
>
>   * These early-access , open-source builds are provided under the
>   o GNU General Public License, version 2, with the Classpath
> Exception .
>   * Release Notes are available athttps://jdk.java.net/18/release-notes
> 
>   * Features:
>   o JEPs integrated to JDK 18, so far:
>   + JEP 400: UTF-8 by Default 
>   + JEP 408: Simple Web Server 
>   + JEP 413: Code Snippets in Java API Documentation
> 
>   o JEPs targeted to JDK 18, so far
>   + JEP 417: Vector API (Third Incubator)
> 
>   o JEPs proposed to target JDK 18:
>   + JEP 416: Reimplement Core Reflection with Method Handles
> 
>
>   * Significant changes since the last availability email:
>   o Build 20:
>   + JDK-8275252: Migrate cacerts from JKS to password-less PKCS12
>   + JDK-8275149: (ch) ReadableByteChannel returned by
> Channels.newChannel(InputStream) throws ReadOnlyBufferException
>   + JDK-8266936: Add a finalization JFR event
>   + JDK-8264849: Add KW and KWP support to PKCS11 provider
>   o Build 19:
>   + JDK-8274840: Update OS detection code to recognize Windows 11
>   + JDK-8274407: (tz) Update Timezone Data to 2021c
>   + JDK-8273102: Delete deprecated for removal the empty
> finalize() in java.desktop module
>   o Build 18:
>   + JDK-8274656: Remove default_checksum and safe_checksum_type
> from krb5.conf
>   + JDK-8274471: Add support for RSASSA-PSS in OCSP Response
>   + JDK-8274227: Remove "impl.prefix" jdk system property usage
> from InetAddress
>   + JDK-8274002: [win11 and winserver2022] JDK executable
> installer from network drive starts with huge delay
>   + JDK-8273670: Remove weak etypes from default krb5 etype list
>   o Build 17:
>   + JDK-8273401: Disable JarIndex Support In URLClassPath
>   + JDK-8231640: (prop) Canonical property storage
>   + Build 16:
>   + JDK-8269039: Disable SHA-1 Signed JARs
>
> *Topics of Interest:*_
> _
>
> _JDK 17:_**
> **
>
>   * *Inside Java Podcast “Java 17 is Here!”*
>   o *Part 1: https://inside.java/2021/09/14/podcast-019/
> *
>   o *Part 2: https://inside.java/2021/09/27/podcast-020/
> *
>   * *G1 GC & Parallel GC Improvements in JDK 17*
>   o *https://inside.java/2021/09/17/jdk-17-gc-updates/
> *
>   * ZGC - What's new in JDK 17**
>   o *https://inside.java/2021/10/05/zgc-in-jdk17/
> *
>   * JDK 17 Security Enhancements**
>   o *https://inside.java/2021/09/15/jdk-17-security-enhancements/
> *
>   * The Vector API in JDK 17 (video)**
>   o *https://inside.java/2021/09/23/devlive-vector-api/
> *
>   * Faster Charset Encoding**
>   o *https://inside.java/2021/10/17/faster-charset-encoding/
> *
>
> _JDK 18:_
>
>   * JEP 400 and the Default Charset
>   o https://inside.java/2021/10/04/the-default-charset-jep400/
> 
>   * JDK 18 augmented `javac -Xlint:serial` checks
>   o 

[hibernate-dev] Hibernate Reactive 1.0.0.Final available now

[Sanne Grinovero]

Hi all,

The highly anticipated 1.0.0.Final version of Hibernate Reactive is finally
available.

This time we celebrate with two blog posts;

Gavin King's announcement:
 - https://in.relation.to/2021/10/27/hibernate-reactive-1/

Some considerations about performance by me:
 - https://in.relation.to/2021/10/27/hibernate-reactive-performance/

Please help spreading the word of this important milestone:
 - https://twitter.com/Hibernate/status/1453382684214956040

Also, coincidentally Quarkus 2.4.0.Final is also available today: it
already includes this version of Hibernate Reactive.

Thanks everyone.
 - Sanne
___
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[hibernate-dev] Double release: 5.6.0.Final and 5.5.8.Final now available

[Sanne Grinovero]

Hi all,

both versions have been released;

 - https://in.relation.to/2021/10/13/hibernate-orm-560-final/

Regards,
Sanne
___
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[hibernate-dev] Hibernate ORM 5.6.0.CR1 released!

[Sanne Grinovero]

Hi all,

5.6 is almost ready:
 - https://in.relation.to/2021/09/29/hibernate-orm-560-CR1-release/

Sanne
___
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[hibernate-dev] Hibernate ORM 5.6.0.Beta2 released

[Sanne Grinovero]

Hello all,

Hibernate ORM version 5.6.0.Beta2 was released yesterday;

while it was initially intended to be a relatively light minor release,
some user facing improvements did actually materialize; might be worth
checking the changelog or my summary at

 - https://in.relation.to/2021/09/21/hibernate-orm-560-beta2-release/

Thanks
___
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[hibernate-dev] Re: [External] : Re: Release Announcement: General Availability of Java 17 / JDK 17

[Sanne Grinovero]

Hi Dalibor!
Many thanks, our pleasure, really :)

On Wed, 15 Sept 2021 at 20:33, Dalibor Topic 
wrote:

> Hi Sanne & team,
>
> thank you very much for all your efforts over the years and for the
> shout out [1] - it's been a pleasure to collaborate with you on
> improving and keeping the upgrade experience from one release to next
> for all our users spotless.
>
> cheers,
> dalibor topic
>
> [1] https://twitter.com/OpenJDK/status/1438223281627217922?s=20
>
> On 14.09.2021 21:14, Sanne Grinovero wrote:
> > Hi Rory,
> > congratulations for the release!
> >
> > We've published an update on our status here for all our users, also
> > calling out the Quality Outreach program as it's been a real pleasure to
> > participate.
> >   - https://in.relation.to/2021/09/14/ready-for-jdk17/
> > <
> https://urldefense.com/v3/__https://in.relation.to/2021/09/14/ready-for-jdk17/__;!!ACWV5N9M2RV99hQ!YZc1wrGh2Bn96iGqptSIfQB2sza-eZrPdY9PbTxvYEg-kIj5i97QwSNZsc8yCbFBWKI$
> >
> >   - https://twitter.com/Hibernate/status/1437830411221078018
> > <
> https://urldefense.com/v3/__https://twitter.com/Hibernate/status/1437830411221078018__;!!ACWV5N9M2RV99hQ!YZc1wrGh2Bn96iGqptSIfQB2sza-eZrPdY9PbTxvYEg-kIj5i97QwSNZsc8ywwgf__U$
> >
> >
> > many thanks,
> > Sanne & team
> >
> >
> > On Tue, 14 Sept 2021 at 18:48, Rory O'Donnell  > <mailto:rory.odonn...@oracle.com>> wrote:
> >
> > Hi Sanne & Yoann,
> >
> > *Release Announcement: General Availability of Java 17 / JDK 17 *
> >
> > **
> >
> >* JDK 17, the reference implementation of Java 17, is now
> Generally
> >  Available. [1]
> >* GPL-licensed OpenJDK builds from Oracle are available here:
> > https://jdk.java.net/17/
> > <
> https://urldefense.com/v3/__https://jdk.java.net/17/__;!!ACWV5N9M2RV99hQ!YZc1wrGh2Bn96iGqptSIfQB2sza-eZrPdY9PbTxvYEg-kIj5i97QwSNZsc8yFSazvag$
> >
> > <https://jdk.java.net/17/
> > <
> https://urldefense.com/v3/__https://jdk.java.net/17/__;!!ACWV5N9M2RV99hQ!YZc1wrGh2Bn96iGqptSIfQB2sza-eZrPdY9PbTxvYEg-kIj5i97QwSNZsc8yFSazvag$
> >>
> >* JDK 17 Release notes
> >
> > <https://www.oracle.com/java/technologies/javase/17-relnotes.html
> > <https://www.oracle.com/java/technologies/javase/17-relnotes.html>>
> >* Inside Java: The Arrival of Java 17!
> >  <https://inside.java/2021/09/14/the-arrival-of-java17/
> > <
> https://urldefense.com/v3/__https://inside.java/2021/09/14/the-arrival-of-java17/__;!!ACWV5N9M2RV99hQ!YZc1wrGh2Bn96iGqptSIfQB2sza-eZrPdY9PbTxvYEg-kIj5i97QwSNZsc8yW05SuCc$
> >>
> >
> > *JDK 17 includes the following features [2]:*
> >
> >* JEP 306: Restore Always-Strict Floating-Point Semantics
> >  <https://openjdk.java.net/jeps/306
> > <https://openjdk.java.net/jeps/306>>
> >* JEP 356: Enhanced Pseudo-Random Number Generators
> >  <https://openjdk.java.net/jeps/356
> > <https://openjdk.java.net/jeps/356>>
> >* JEP 382: New macOS Rendering Pipeline
> >  <https://openjdk.java.net/jeps/382
> > <https://openjdk.java.net/jeps/382>>
> >* JEP 391: macOS/AArch64 Port <https://openjdk.java.net/jeps/391
> > <https://openjdk.java.net/jeps/391>>
> >* JEP 398: Deprecate the Applet API for Removal
> >  <https://openjdk.java.net/jeps/398
> > <https://openjdk.java.net/jeps/398>>
> >* JEP 403: Strongly Encapsulate JDK Internals
> >  <https://openjdk.java.net/jeps/403
> > <https://openjdk.java.net/jeps/403>>
> >* JEP 406: Pattern Matching for switch (Preview)
> >  <https://openjdk.java.net/jeps/406
> > <https://openjdk.java.net/jeps/406>>
> >* JEP 407: Remove RMI Activation
> > <https://openjdk.java.net/jeps/407 <
> https://openjdk.java.net/jeps/407>>
> >* JEP 409: Sealed Classes <https://openjdk.java.net/jeps/409
> > <https://openjdk.java.net/jeps/409>>
> >* JEP 410: Remove the Experimental AOT and JIT Compiler
> >  <https://openjdk.java.net/jeps/410
> > <https://openjdk.java.net/jeps/410>>
> >* JEP 411: Deprecate the Security Manager for Removal
> >  <https://openjdk.java.net/jeps/411
> > <https://openjdk.java.net/jeps/411>>
> >* JEP 412: Foreign Function & Memory API (Incubator)
&g

[hibernate-dev] Re: Release Announcement: General Availability of Java 17 / JDK 17

[Sanne Grinovero]

Hi Rory,
congratulations for the release!

We've published an update on our status here for all our users, also
calling out the Quality Outreach program as it's been a real pleasure to
participate.
 - https://in.relation.to/2021/09/14/ready-for-jdk17/
 - https://twitter.com/Hibernate/status/1437830411221078018

many thanks,
Sanne & team


On Tue, 14 Sept 2021 at 18:48, Rory O'Donnell 
wrote:

> Hi Sanne & Yoann,
>
> *Release Announcement: General Availability of Java 17 / JDK 17 *
>
> **
>
>   * JDK 17, the reference implementation of Java 17, is now Generally
> Available. [1]
>   * GPL-licensed OpenJDK builds from Oracle are available here:
> https://jdk.java.net/17/ 
>   * JDK 17 Release notes
> 
>   * Inside Java: The Arrival of Java 17!
> 
>
> *JDK 17 includes the following features [2]:*
>
>   * JEP 306: Restore Always-Strict Floating-Point Semantics
> 
>   * JEP 356: Enhanced Pseudo-Random Number Generators
> 
>   * JEP 382: New macOS Rendering Pipeline
> 
>   * JEP 391: macOS/AArch64 Port 
>   * JEP 398: Deprecate the Applet API for Removal
> 
>   * JEP 403: Strongly Encapsulate JDK Internals
> 
>   * JEP 406: Pattern Matching for switch (Preview)
> 
>   * JEP 407: Remove RMI Activation 
>   * JEP 409: Sealed Classes 
>   * JEP 410: Remove the Experimental AOT and JIT Compiler
> 
>   * JEP 411: Deprecate the Security Manager for Removal
> 
>   * JEP 412: Foreign Function & Memory API (Incubator)
> 
>   * JEP 414: Vector API (Second Incubator)
> 
>   * JEP 415: Context-Specific Deserialization Filters
> 
>
> *JDK 17 will be a long-term-support (LTS) release* from most
> vendors,including Oracle. If you’re upgrading from the previous LTS
> release,JDK 11, then you have many more JEPs to look forward to,
> summarized here:
>
> https://openjdk.java.net/jdk/17/jeps-since-jdk-11
> 
>
>
> Thanks to everyone who contributed to JDK 17, whether by creating
> features or enhancements, logging bugs, or
>
> downloading and testing the early-access builds.
>
>
> *OpenJDK 18 Early Access build 14 is now available at
> https://jdk.java.net/18/ 
> *
>
>   * These early access, open source builds are provided under the GNU
> General Public License, version 2, with the Classpath Exception
> .
>   * JEPs targeted to JDK 18, so far:
>   o JEP 400: UTF-8 by Default 
>   o JEP 413: Code Snippets in Java API Documentation
> 
>
>   * Release Notes are available at https://jdk.java.net/18/release-notes
> 
>
>   * Significant changes since the last availability email:
>   o JDK-8271745: Fix Issues With the KW and KWP Modes of SunJCE
> Provider
>   o JDK-8262186: Call X509KeyManager.chooseClientAlias once for all
> key types
>   o JDK-8225083: Remove Google certificate that is expiring in
> December 2021
>   o JDK-8251329: Zip File System Provider Throws ZipException when
> entry name element contains "." or ".."
>   o JDK-8225082: Remove IdenTrust certificate that is expiring in
> September 2021
>   o
>
> *Project Loom Early-Access Builds*
>
>   * Build 18-loom+2-74 (2021/8/7) based on jdk-18+9
>  is
> available - https://jdk.java.net/loom/ 
>   * These early access, open source builds are provided under the GNU
> General Public License, version 2, with the Classpath Exception
> .
>   * Please send feedback via e-mail to loom-...@openjdk.java.net
> . To send e-mail to this address
> you must first subscribe to the mailing list
> .
>
> Rgds,Rory
>
>
> [1]
> https://mail.openjdk.java.net/pipermail/jdk-dev/2021-September/006037.html
>
> [2] https://openjdk.java.net/projects/jdk/17/
> 
>
> ___
> hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
> To unsubscribe send an email to 

[hibernate-dev] Twin release: Hibernate ORM 5.5.7.Final and 5.6.0.Beta1

[Sanne Grinovero]

Hi all,

both are now available. Please check out our blog:
 - https://in.relation.to/2021/08/27/hibernate-orm-560-beta1-release/

Enjoy!
___
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[hibernate-dev] Hibernate ORM: creating branch 5.5, long live 5.6

[Sanne Grinovero]

Hi all,

While the Hibernate ORM core experts are focused on Hibernate ORM 6, we
have a small team working on Hibernate Reactive that needs some more
changes done on Hibernate ORM v5.x (as that's what they are using
currently).

I'm keen to apply these and they look great, but honestly I've been
hesitant as they are significant and with larger patches there always is
some degree of risk, no matter how cautious we are.

To better address these needs, I will bump the minor version of releases
more regularly than what we've seen in the past; this doesn't reflect a
change of pace of the project, nor should you expect significant features
to be highlighted in each minor release: it just puts us in a position to
more reliably be able to ship important fixes in older releases, w/o such
release having to include also the many fast paced changes required by the
Reactive team.

I'm confident this makes sense to all: after all that's what the
minor/micro differences are for.
So nothing is really different here, expect that you'll likely see minor
releases happening more frequently from now on.

Thanks,
Sanne
___
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[hibernate-dev] Hibernate ORM 5.5.2.Final released

[Sanne Grinovero]

Hi all,

and following the Hibernate Search release, we also have an Hibernate ORM
version 5.5.2.Final available now.

N.B. we skipped version 5.5.1.Final : my fault, I made a mistake during the
process.

More details on:
 - https://in.relation.to/2021/06/15/hibernate-orm-552-release/

Thanks
___
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[hibernate-dev] Re: Release Announcement: General Availability of Java 16 / JDK 16

[Sanne Grinovero]

Awesome news, thanks for the update and congratulations!

Sanne


On Tue, 16 Mar 2021 at 17:16, Rory O'Donnell 
wrote:

>
> Hi Sanne & Yoann,
>
> *Release Announcement: General Availability of Java 16 / JDK 16 *
>
> **
>
>   * JDK 16, the reference implementation of Java 16, is now Generally
> Available. [1]
>   * GPL-licensed OpenJDK builds from Oracle are available here:
> http://jdk.java.net/16/ 
>   * JDK 16 Release notes
> 
>
> *JDK 16 includes the following features [2]:*
>
>   * JEP 338:Vector API (Incubator) 
>   * JEP 347:Enable C++14 Language Features
> 
>   * JEP 357:Migrate from Mercurial to Git
> 
>   * JEP 369:Migrate to GitHub 
>   * JEP 376:ZGC: Concurrent Thread-Stack Processing
> 
>   * JEP 380:Unix-Domain Socket Channels  >
>   * JEP 386:Alpine Linux Port 
>   * JEP 387:Elastic Metaspace 
>   * JEP 388:Windows/AArch64 Port 
>   * JEP 389:Foreign Linker API (Incubator)
> 
>   * JEP 390:Warnings for Value-Based Classes
> 
>   * JEP 392:Packaging Tool 
>   * JEP 393:Foreign-Memory Access API (Third Incubator)
> 
>   * JEP 394:Pattern Matching for instanceof
> 
>   * JEP 395:Records 
>   * JEP 396:Strongly Encapsulate JDK Internals by Default
> 
>   * JEP 397:Sealed Classes (Second Preview)
> 
>
> Thanks to everyone who contributed to JDK 16, whether by creating
> features or enhancements, logging bugs, or
>
> downloading and testing the early-access builds.
>
> *OpenJDK 17 Early Access build 13 is now available at
> http://jdk.java.net/17 
> *
>
>
> **
>
>   * These early access, open source builds are provided under the GNU
> General Public License, version 2, with the Classpath Exception
> .
>   * JEPs targeted to JDK 17, so far:
>   o JEP 356: Enhanced Pseudo-Random Number Generators
> 
>
>   * Release Notes are available at http://jdk.java.net/17/release-notes
> 
>
>   * Significant changes since the last availability email:
>   o JDK-8259709: Disable SHA-1 XML Signatures (b13)
>   o JDK-6323374: (coll) Optimize Collections.unmodifiable* and
> synchronized*(b13)
>   o JDK-8139348: Deprecate 3DES and RC4 in Kerberos (b12)
>   o JDK-8259662: Don't wrap SocketExceptions into SSLExceptions in
> SSLSocketImpl (b11)
>   o JDK-8235139: Deprecate the socket impl factory mechanism(b10)
>   o JDK-8225081: Remove Telia Company CA certificate expiring in
> April 2021(b9)
>
>
> *Project Lanai Early-Access Builds
> *
>
>   * EA 10 Build 17-lanai+3-133 (2021/3/2) is available -
> http://jdk.java.net/lanai/
>   * These early access, open source builds are provided under the GNU
> General Public License, version 2, with the Classpath Exception
> .
>
>
> *Project Loom Early-Access Builds*
>
>   * Build 17-loom+4-174 (2021/3/12) is available -
> http://jdk.java.net/loom/
>   * These early access, open source builds are provided under the GNU
> General Public License, version 2, with the Classpath Exception
> .
>
>
> *Project Panama Early-Access Builds
> *
>
>   * Build 17-panama+2-51 (2021/2/12) is available -
> http://jdk.java.net/panama/
>   * These early access, open source builds are provided under the GNU
> General Public License, version 2, with the Classpath Exception
> .
>
>
> Rgds,Rory
>
> [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2021-March/005188.html
>
> [2] https://openjdk.java.net/projects/jdk/16/
> 
>
> ___
> hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
> To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[hibernate-dev] Re: Bot for checking contribution rules in Hibernate projects

[Sanne Grinovero]

That's great, thank you!

On Mon, 15 Mar 2021 at 14:42, Yoann Rodiere  wrote:

> Hello everyone,
>
> I just deployed a GitHub bot on our infrastructure. The purpose of this bot
> is to run basic checks on pull requests, so that contributors know right
> away if something needs to be changed, without having to wait for a human
> to take the time to review. And to avoid oversights for some boring, but
> nevertheless important rules.
>
> You can see a few failing checks in this playground project:
>
>-
>
> https://github.com/yrodiere/hibernate-github-bot-playground/pull/6/checks
>- https://github.com/yrodiere/hibernate-github-bot-playground/pull/6
>
> Pull requests failing these checks can still be merged ; the checks are
> only here to help, not to enforce anything. So if you need to merge a few
> commits that do not mention a JIRA ticket (e.g. changes in github
> workflows), you can still do it.
>
> The checks are obviously very simple. At the moment, we check:
>
>- That the pull request title has at least two words
>- That the pull request title doesn't end with a dot or ellipsis (they
>are a sign that the title may be incomplete)
>- That every commit message starts with a JIRA ticket key.
>- That the pull request title/description mentions all JIRA ticket keys
>mentioned in commit messages.
>
> We can definitely work on adding more checks, or tuning the existing
> checks. Please create issues here:
> https://github.com/hibernate/hibernate-github-bot/issues
>
> The bot is currently only enabled on Hibernate Search and Hibernate ORM. If
> you want to enable it on other projects, please follow instructions here:
>
> https://github.com/hibernate/hibernate-github-bot/#enabling-the-bot-in-a-new-repository
>
> To anyone interested, the bot was implemented using Quarkus and Guillaume's
> GitHub extension: https://github.com/quarkiverse/quarkus-github-app
>
> Cheers,
>
>
> Yoann Rodière
> Hibernate Team
> yo...@hibernate.org
> ___
> hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
> To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[hibernate-dev] Released: Hibernate ORM 5.4.29.Final

[Sanne Grinovero]

Hi all,

Hibernate ORM 5.4.29.Final is now available.
 - https://in.relation.to/2021/03/03/hibernate-orm-5429-final-release/

Thanks and enjoy :)
___
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[hibernate-dev] Re: FetchMode.SELECT

[Sanne Grinovero]

On Tue, 12 Jan 2021 at 08:31, andrea boriero  wrote:
>
> I agree with Christian, the FetchMode should only influence the how and not
> the when of a fetch.
>
> If the association is EAGER and annotated with FetchMode.SELECT then it
> should be loaded immediately using a secondary select.

+1

How and when to load express different needs and can be valid in
various combinations.

A use case is that one might explicitly want a separate loading event,
for example to simplify the generated SQL or to make better use of the
2LC.

One might still want it EAGERly loaded, so to prepare an object graph
for detached processing.

>
> On Thu, 7 Jan 2021 at 10:31, Christian Beikov 
> wrote:
>
> > I agree that this should be supported. Specifying a fetch mode should
> > IMO not change the fetch type to LAZY or EAGER.
> >
> > Am 06.01.2021 um 04:50 schrieb Gail Badner:
> > > Should it be possible to force an eager association to be loaded by a
> > > separate query using @Fetch(FetchMode.SELECT)?
> > >
> > > I thought that Hibernate supported that for an EAGER association, but I
> > see
> > > the documentation for FetchMode.SELECT
> > > <
> > https://docs.jboss.org/hibernate/orm/5.4/userguide/html_single/Hibernate_User_Guide.html#fetching-fetch-annotation
> > >
> > > says:
> > >
> > > "SELECT
> > > The association is going to be fetched lazily using a secondary select
> > for
> > > each individual entity, collection, or join load. It’s equivalent to
> > > JPA FetchType.LAZY fetching strategy."
> > >
> > > The reason I ask is because I am trying to wrap up HHH-13085, which will
> > > change derived IDs mapped as a one-to-one association, currently loaded
> > by
> > > a separate query, to instead be loaded in the same query that loads the
> > > dependent entity. I want to ensure that it is possible to revert back to
> > > loading that one-to-one association in a separate query after HHH-13085
> > is
> > > fixed.
> > >
> > > Currently, a StackOverflowError is thrown when loading an entity with an
> > ID
> > > that is an bidirectional eager one-to-one association has
> > FetchMode.SELECT
> > > mapped.
> > >
> > > @Entity(name = "Foo")public class Foo implements Serializable {
> > >
> > >  @Id
> > >  @GeneratedValue
> > >  private Long id;
> > >
> > >  @OneToOne(mappedBy = "foo", cascade = CascadeType.ALL)
> > >  private Bar bar;
> > > }
> > >
> > > @Entity(name = "Bar")public class Bar implements Serializable {
> > > @Id
> > >  @OneToOne(fetch = FetchType.EAGER)
> > >  @Fetch(FetchMode.SELECT)
> > >  @JoinColumn(name = "BAR_ID")
> > >  private Foo foo;
> > > }
> > >
> > >
> > > According to the documentation, it sounds like @Fetch(FetchMode.SELECT)
> > > should make the association lazy. Is that really correct?
> > >
> > > Could someone please clarify the expected behavior?
> > >
> > > I created HHH-14390 
> > for
> > > the StackOverflowError. I've pushed some FailureExpected tests
> > > <
> > https://github.com/hibernate/hibernate-orm/commit/b40d1251e385a5fdb018f9583a83c472d6da4e8f
> > >
> > > that reproduce this issue.
> > >
> > > Thanks,
> > > Gail
> > > ___
> > > hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
> > > To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
> > > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
> > ___
> > hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
> > To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
> > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
> ___
> hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
> To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[hibernate-dev] Hibernate Reactive : Beta2 now available

[Sanne Grinovero]

Hi all,

please see
 - https://in.relation.to/2021/01/07/hibernate-reactive-beta2/

Thanks!
___
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[hibernate-dev] Hibernate ORM 5.4.27.Final

[Sanne Grinovero]

Hi all,

apologies I failed to send this earlier.

Both Hibernate ORM 5.4.26.Final and 5.4.27.Final have been released at
end of last year with some minor improvements, a new Micrometer
module.

As usual, please see here for more details:
 - https://in.relation.to/2021/01/06/hibernate-orm-5427-final-release/

Thanks,
Sanne
___
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[hibernate-dev] Re: Hibernate Search 6.0.0.Final is out!

[Sanne Grinovero]

Congratulations!

Really cool, and that was a huge amount of work.

On Fri, 11 Dec 2020 at 10:31, Yoann Rodiere  wrote:
>
> Hello,
>
> We just published the first stable release of Hibernate Search 6: version
> 6.0.0.Final.
>
> With more than 900 tickets addressed
> 
> over the course of 20 alphas and betas, Hibernate Search 6 really is a
> major release, and it shows.
>
> The most obvious changes: an overhauled API better suited to working with
> Elasticsearch (but that still works perfectly with embedded Lucene), and
> upgrades from Lucene 5 to 8 and from Elasticsearch 5.6 to 7.
>
> But it doesn’t stop there: a safer and more concise Search DSL, easier
> mapping, more powerful bridges, smarter automatic indexing, nested
> documents, …
>
> For more information (what's new, getting started, migrating, ...), see our
> blog:
>
> https://in.relation.to/2020/12/11/hibernate-search-6-0-0-Final/
>
> Yoann Rodière
> Hibernate Team
> yo...@hibernate.org
> ___
> hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
> To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[hibernate-dev] Re: Automatically Upgrade to HTTPS

[Sanne Grinovero]

Sure, we're in control of the DNS.

On Tue, 24 Nov 2020 at 12:13, Max Rydahl Andersen  wrote:
>
> can you control the dns ? i.e. for jbang.dev I moved to cloud flare for
> dns to let me do things GitHub pages and hover.com didn't support doing.
>
> cloudflare seem to have more fine grained control options.
>
> /max
>
> > +1
> >
> > I think we need to move off github pages; it's great for simple
> > projects but it's not flexible enough for us.
> >
> > On Tue, 24 Nov 2020 at 08:55, Gunnar Morling 
> > wrote:
> >>
> >>> it broke legacy applications whose XML parser will automatically
> >>> fetch
> >> the DTD from hibernate.org on startup,
> >>
> >> Gasp, I see. They shouldn't really be fetching that file in the first
> >> place, but I see how you don't want to break those consumers.
> >>
> >> You might do it perhaps by announcing a transition date in a few
> >> months
> >> (e.g. 2020/03/31), giving people time to upgrade. I cannot quantify
> >> the SEO
> >> impact of this, but I suppose it's only getting worse. Tough choice
> >> :(
> >>
> >> --Gunnar
> >>
> >>
> >> Am Mo., 23. Nov. 2020 um 17:34 Uhr schrieb Yoann Rodiere <
> >> yo...@hibernate.org>:
> >>
> >>> Hey,
> >>>
> >>> Ah, this again.
> >>>
> >>> We've already looked into it. Last time we did, we got bug reports
> >>> because
> >>> it broke legacy applications whose XML parser will automatically
> >>> fetch the
> >>> DTD from hibernate.org on startup, and does not handle redirection
> >>> or
> >>> HTTPS (I don't know which exactly).
> >>>
> >>> We cannot do this redirection on a per-page basis (to exclude /dtd/)
> >>> because we're using GitHub pages and the redirection setting is
> >>> global.
> >>>
> >>> So right now, we could only do this by moving away from GitHub
> >>> pages. And
> >>> then we'd probably need some cache in front of our server.
> >>>
> >>> Long story short, nobody had time to look into this so far.
> >>>
> >>> Yoann Rodière
> >>> Hibernate Team
> >>> yo...@hibernate.org
> >>>
> >>>
> >>> On Mon, 23 Nov 2020 at 17:23, Gunnar Morling 
> >>> wrote:
> >>>
>  Hey all,
> 
>  I just noticed that visiting http://hibernate.org/ (i.e. not
>  http*s*)
>  will
>  not automatically upgrade you to HTTPS, but leave you with that
>  ugly
>  unsecure icon in the browser address bar. It's also what you get
>  when
>  simply typing hibernate.org (i.e. 99% of users).
> 
>  As search engines tend to penalize non-HTTPS these days, I'd
>  suggest to
>  look into automatically upgrading if possible.
> 
>  Best,
> 
>  --Gunnar
>  ___
>  hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
>  To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
>  %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
> >>>
> >>>
> >> ___
> >> hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
> >> To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
> >> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
> > ___
> > hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
> > To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
> > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
> /max
> https://xam.dk/about
___
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[hibernate-dev] Re: Automatically Upgrade to HTTPS

[Sanne Grinovero]

+1

I think we need to move off github pages; it's great for simple
projects but it's not flexible enough for us.

On Tue, 24 Nov 2020 at 08:55, Gunnar Morling  wrote:
>
> > it broke legacy applications whose XML parser will automatically fetch
> the DTD from hibernate.org on startup,
>
> Gasp, I see. They shouldn't really be fetching that file in the first
> place, but I see how you don't want to break those consumers.
>
> You might do it perhaps by announcing a transition date in a few months
> (e.g. 2020/03/31), giving people time to upgrade. I cannot quantify the SEO
> impact of this, but I suppose it's only getting worse. Tough choice :(
>
> --Gunnar
>
>
> Am Mo., 23. Nov. 2020 um 17:34 Uhr schrieb Yoann Rodiere <
> yo...@hibernate.org>:
>
> > Hey,
> >
> > Ah, this again.
> >
> > We've already looked into it. Last time we did, we got bug reports because
> > it broke legacy applications whose XML parser will automatically fetch the
> > DTD from hibernate.org on startup, and does not handle redirection or
> > HTTPS (I don't know which exactly).
> >
> > We cannot do this redirection on a per-page basis (to exclude /dtd/)
> > because we're using GitHub pages and the redirection setting is global.
> >
> > So right now, we could only do this by moving away from GitHub pages. And
> > then we'd probably need some cache in front of our server.
> >
> > Long story short, nobody had time to look into this so far.
> >
> > Yoann Rodière
> > Hibernate Team
> > yo...@hibernate.org
> >
> >
> > On Mon, 23 Nov 2020 at 17:23, Gunnar Morling  wrote:
> >
> >> Hey all,
> >>
> >> I just noticed that visiting http://hibernate.org/ (i.e. not http*s*)
> >> will
> >> not automatically upgrade you to HTTPS, but leave you with that ugly
> >> unsecure icon in the browser address bar. It's also what you get when
> >> simply typing hibernate.org (i.e. 99% of users).
> >>
> >> As search engines tend to penalize non-HTTPS these days, I'd suggest to
> >> look into automatically upgrading if possible.
> >>
> >> Best,
> >>
> >> --Gunnar
> >> ___
> >> hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
> >> To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
> >> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
> >
> >
> ___
> hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
> To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[hibernate-dev] Hibernate ORM 5.4.24.Final fixes CVE-2020-25638

[Sanne Grinovero]

Hi all,

Hibernate ORM 5.4.24.Final is now available.

Among the other numerous improvements, it includes a security fix.

Please see more details on our blog:
 - https://in.relation.to/2020/11/19/hibernate-orm-5424-final-release/

Thanks
___
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[hibernate-dev] Re: First candidate release for Hibernate Search 6.0

[Sanne Grinovero]

Congratulations for this fantastic milestone!

Looking forward to a better search experience across the world ;)


On Wed, 4 Nov 2020 at 12:52, Yoann Rodiere  wrote:
>
> Hello,
>
> We just published the first candidate release for Hibernate Search 6.0:
> version 6.0.0.CR1.
>
> Compared to Hibernate Search 5, changes are extensive, due to the API
> overhaul, but with plenty of improvements: upgrades to Lucene 8 and
> Elasticsearch 7 of course, but also a more concise Search DSL with typed
> result types, full control on field declaration in Bridges, easier to
> configure and more efficient automatic indexing, runtime joins with nested
> documents, …
>
> No more changes are planned before the final release, so *this is the
> perfect time to test your applications based on Hibernate Search*, and
> report problems as soon as possible so that everything works perfectly as
> soon as 6.0.0.Final is released.
>
> For more information (in particular regarding migration to the new API),
> see our blog:
>
> https://in.relation.to/2020/11/04/hibernate-search-6-0-0-CR1/
>
> Yoann Rodière
> Hibernate Team
> yo...@hibernate.org
> ___
> hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
> To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[hibernate-dev] Hibernate ORM 5.4.23.Final : upgrade to save some memory

[Sanne Grinovero]

Hi all,

we released both Hibernate ORM 5.4.23.Final and its dependency
Hibernate Commons Annotations 5.1.2.Final

This is a micro release so not meant to have new features, but it
features substantially reduced memory usage.

For more details, please see:
 - https://in.relation.to/2020/11/03/hibernate-orm-memory/

Regards,
Sanne
___
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[hibernate-dev] Design of threadsafe, immutable internal components

[Sanne Grinovero]

Hi all,

I'm inspecting some old code, and regularly finding a pattern which
isn't entirely correct; it's not a big deal as it seems to not cause
any problems so far in practice (expect the one I'm working on!), but
I'll share this in hope we can slowly improve such things while
evolving the codebase.

When making an immutable, internal component we'll often have many
fields with a "final" qualifier. This is good and we should definitely
keep doing it.

But also, one needs to ensure that once the constructor of an object
has completed, such objects referenced in the final field should no
longer be mutated (unless of course they are mutated in a thread safe
way as well).

To get more concrete, the following pattern is frequent in our code,
but should not be used:

class A {

   private final HashMap state = new HashMap();

A() { //constructor
}

public initState( p ) {
   state.put (p, v);
}
}

There's many reasons for this; at this stage my concern is mostly that
the actual state which we're writing in the _state_ field doesn't
benefit from the effect of the final field on visibility, as by
specification the "freeze" of state is applied when the constructor
has concluded.
an additional problem is that such protected methods get to work on a
partially constructed object as the constructor hasn't finished being
invoked yet; this leads to additional subtle errors when the method is
overridden by subclasses or relying on state from superclasses.

A better version could be:

class A {

   private final Map state;

A(params) { //constructor
   this.state = initState( params );
}

static Map initState( params ) {
  HashMap state = new HashMap();
   for ( some_loop on params ) {
   state.put (p, v);
   }
   return state;
  }

}

If this doesn't work in your case as you need to "collect" some data
by passing A to various other services, like we frequently need, this
would suggest that you need an intermediary object, such as a builder
pattern: collect all things you need, then build the immutable final
representation of the state you need and make sure the builder is
discarded.

Alternatively, that "state" Map could use a ConcurrentHashMap if your
service actually needs runtime state mutation by design.

Please take this in consideration, as it will allow us to write better
maintainable code, unlocks some possible optimisations which are
otherwise hard to implement, and above all is actually correct in
regards to the Java memory model.

In the above example, it's interesting to highlight that the current
code is working fine as we eventually publish references to A over a
barrier, which will publish the state of the post-initialized A.state
, so there's no rush in fixing such things BUT when I need to make
changes to such patterns it's challenging to trace the barriers to
make sure I'm not inadvertently introducing an obscure issue. Would be
best to not rely on such root barriers.

For those who want to know more, a good reference is Chapter 17.5 of
the Java Language Specification.

Thanks!
Sanne
___
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[hibernate-dev] Re: HCANN evolution

[Sanne Grinovero]

I am needing to release this, but a combination of changes in the
JBoss Nexus authentication process and the fact we're using an older
version of Gradle made this much more complicated than I wanted;

so I began the process to transfer HCANN to bintray as well.
___
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[hibernate-dev] Re: HCANN evolution

[Sanne Grinovero]

On Thu, 22 Oct 2020 at 14:50, Steve Ebersole  wrote:
>
> Sounds good, I'll take a look.

Thanks, here is a draft PR for ORM master:
 - https://github.com/hibernate/hibernate-orm/pull/3608

>
> Longer term, the best option from the perspective of ORM is to simply drop 
> HCANN altogether in favor of Jandex + JAXB.  In fact, I am considering 
> playing with that on top of your work.  It would be awesome to start dropping 
> the things that hold us to including dom4j

+100 :)

Further such steps should be easier after this.

N.B. I'm considering these steps as a preparation step, I didn't yet
address the core of the memory retention issue - I'll get to that
next, having simplified the problem first.

>
> On Thu, Oct 22, 2020 at 8:02 AM Yoann Rodiere  wrote:
>>
>> Hi,
>>
>> Looks good to me, but please ping me when you submit the PR. HCANN is used
>> in Hibernate Search as well, and not just the ORM module.
>> If we ever need to have two ORM modules in Hibernate Search (one for ORM 5
>> and one for ORM 6), I'll need to be sure that Hibernate Search can switch
>> from HCANN 5 to 6 without recompiling...
>>
>>
>> Yoann Rodière
>> Hibernate Team
>> yo...@hibernate.org
>>
>>
>> On Thu, 22 Oct 2020 at 14:51, Sanne Grinovero  wrote:
>>
>> > Hi all,
>> >
>> > While investigating a case of too much memory being held after boot, I
>> > noticed Hibernate Commons Annotations's old design and patterns are a
>> > strong contributor to the problem.
>> >
>> > We talked many times about getting rid of it, yet we know it's not
>> > easy as we have a high level of coupling - but I believe we can
>> > achieve it in iterative steps, reducing the coupling.
>> >
>> > I now have a draft of patches which remove its capability to load
>> > classes and packages "by name";  this implies it removing any
>> > interaction with classloaders, and associated complexity; this will of
>> > course require some adaptation in ORM but it turns out its own code is
>> > also cleaner as a result (ORM's ClassLoaderService is preferred), so
>> > I'd like to proceed.
>> >
>> > Unless there are strong objections, I'll mark all those classes which
>> > I mean to delete as deprecated in HCANN 5.x, and remove them in HCANN
>> > master (6).
>> > Then I'll release the next 5.x and propose the adaptation PR to ORM;
>> > since I'm not actually removing the functionality yet we still have
>> > the option to keep the ORM patches limited to a smaller scope, should
>> > there be any concerns regarding specific details (to be discussed in
>> > PRs), but I don't believe this should be necessary.
>> >
>> > I'd also like to release an HCANN 6 preview and have ORM6 use it.
>> >
>> > Among other benefits, this will leave the HCANN codebase significantly
>> > smaller and more focused on its core goals; I believe after this
>> > cleanup it looks much better and we might not need to fully get rid of
>> > it, for example it does solve the generics problem quite elegantly, so
>> > there's no need to throw that out too.
>> >
>> > Thanks,
>> > Sann
>> > ___
>> > hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
>> > To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
>> > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>> ___
>> hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
>> To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[hibernate-dev] Re: HCANN evolution

[Sanne Grinovero]

On Thu, 22 Oct 2020 at 14:36, Guillaume Smet  wrote:
>
> On Thu, Oct 22, 2020 at 3:30 PM Sanne Grinovero  wrote:
>>
>> Sure, I'll do that.
>>
>> Regarding Validator, I believe it doesn't use it?
>
> No, it doesn't!

Great! thanks
___
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[hibernate-dev] Re: HCANN evolution

[Sanne Grinovero]

Sure, I'll do that.

Regarding Validator, I believe it doesn't use it?

On Thu, 22 Oct 2020 at 14:02, Yoann Rodiere  wrote:
>
> Hi,
>
> Looks good to me, but please ping me when you submit the PR. HCANN is used in 
> Hibernate Search as well, and not just the ORM module.
> If we ever need to have two ORM modules in Hibernate Search (one for ORM 5 
> and one for ORM 6), I'll need to be sure that Hibernate Search can switch 
> from HCANN 5 to 6 without recompiling...
>
>
> Yoann Rodière
> Hibernate Team
> yo...@hibernate.org
>
>
> On Thu, 22 Oct 2020 at 14:51, Sanne Grinovero  wrote:
>>
>> Hi all,
>>
>> While investigating a case of too much memory being held after boot, I
>> noticed Hibernate Commons Annotations's old design and patterns are a
>> strong contributor to the problem.
>>
>> We talked many times about getting rid of it, yet we know it's not
>> easy as we have a high level of coupling - but I believe we can
>> achieve it in iterative steps, reducing the coupling.
>>
>> I now have a draft of patches which remove its capability to load
>> classes and packages "by name";  this implies it removing any
>> interaction with classloaders, and associated complexity; this will of
>> course require some adaptation in ORM but it turns out its own code is
>> also cleaner as a result (ORM's ClassLoaderService is preferred), so
>> I'd like to proceed.
>>
>> Unless there are strong objections, I'll mark all those classes which
>> I mean to delete as deprecated in HCANN 5.x, and remove them in HCANN
>> master (6).
>> Then I'll release the next 5.x and propose the adaptation PR to ORM;
>> since I'm not actually removing the functionality yet we still have
>> the option to keep the ORM patches limited to a smaller scope, should
>> there be any concerns regarding specific details (to be discussed in
>> PRs), but I don't believe this should be necessary.
>>
>> I'd also like to release an HCANN 6 preview and have ORM6 use it.
>>
>> Among other benefits, this will leave the HCANN codebase significantly
>> smaller and more focused on its core goals; I believe after this
>> cleanup it looks much better and we might not need to fully get rid of
>> it, for example it does solve the generics problem quite elegantly, so
>> there's no need to throw that out too.
>>
>> Thanks,
>> Sann
>> ___
>> hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
>> To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[hibernate-dev] HCANN evolution

[Sanne Grinovero]

Hi all,

While investigating a case of too much memory being held after boot, I
noticed Hibernate Commons Annotations's old design and patterns are a
strong contributor to the problem.

We talked many times about getting rid of it, yet we know it's not
easy as we have a high level of coupling - but I believe we can
achieve it in iterative steps, reducing the coupling.

I now have a draft of patches which remove its capability to load
classes and packages "by name";  this implies it removing any
interaction with classloaders, and associated complexity; this will of
course require some adaptation in ORM but it turns out its own code is
also cleaner as a result (ORM's ClassLoaderService is preferred), so
I'd like to proceed.

Unless there are strong objections, I'll mark all those classes which
I mean to delete as deprecated in HCANN 5.x, and remove them in HCANN
master (6).
Then I'll release the next 5.x and propose the adaptation PR to ORM;
since I'm not actually removing the functionality yet we still have
the option to keep the ORM patches limited to a smaller scope, should
there be any concerns regarding specific details (to be discussed in
PRs), but I don't believe this should be necessary.

I'd also like to release an HCANN 6 preview and have ORM6 use it.

Among other benefits, this will leave the HCANN codebase significantly
smaller and more focused on its core goals; I believe after this
cleanup it looks much better and we might not need to fully get rid of
it, for example it does solve the generics problem quite elegantly, so
there's no need to throw that out too.

Thanks,
Sann
___
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[hibernate-dev] Hibernate Reactive 1.0.0.Alpha10 released

[Sanne Grinovero]

Hi all,

We released 1.0.0.Alpha10 of Hibernate Reactive, to be able to upgrade
both Hibernate ORM and Hibernate Reactive in Quarkus. Still work in
progress though!

Thanks
___
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[hibernate-dev] Released: Hibernate ORM 5.4.22.Final

[Sanne Grinovero]

Hi all,

Hibernate ORM 5.4.22.Final is now available on your favourite mirrors.

Some more details:
 - https://in.relation.to/2020/10/01/hibernate-orm-5/

Thanks
___
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[hibernate-dev] Re: Commit messages, and keeping JIRA in synch

[Sanne Grinovero]

On Tue, 29 Sep 2020 at 12:34, Gunnar Morling  wrote:
>
> Hey Sanne,
>
> > ALL commits need to start with the JIRA code which relates to the change.
>
> Perhaps you're doing this already, so just in case: for Debezium we have a 
> simple check of that as a GH action, failing PR builds if they contain 
> commits whose message does not begin with "DBZ-":
>
> 
> https://github.com/debezium/debezium/blob/master/.github/workflows/sanity-check.yml

thanks! I was just reading about such options right now, and your
example is really handy!

Do you think it would be possible to evolve such a rule to check that
it's not a closed JIRA ? (I'm sure it is, but I mean to ask if it's
simple enough to be worth exploring)

>
> --Gunnar
>
>
>
> Am Di., 29. Sept. 2020 um 13:15 Uhr schrieb Sanne Grinovero 
> :
>>
>> Hi all,
>>
>> looks like it's a good time for me to remind how we need commits
>> managed, and their relation to JIRA tickets.
>>
>> When reviewing pull requests, and before merging them, please pay
>> attention to these simple rules as it's important for long term
>> maintenance.
>> We need to be able to query JIRA to figure out which branches and
>> versions contain a specific patch; it's also useful for people to know
>> if they might be affected by a specific bug.
>>
>> # Commit format
>> ALL commits need to start with the JIRA code which relates to the change.
>>
>> This implies that any little improvement needs a JIRA ticket created
>> before being integrated; this is sometimes a little inconvenient, but
>> please stick to it the same.
>>
>> The exception to this rule is the release process itself; it's ok for
>> scripts to push placeholder commits to help identify just-before and
>> just-after tags.
>>
>> # Closed JIRA tickets
>> One should never have a new commit which is recycling a JIRA ticket
>> which is closed already.
>>
>> A closed ticket for us means "sealed and archived".
>>
>> This means that if you discover a better way to fix an issue which is
>> already closed, you will need to open a new JIRA.
>> Even if technically the old issue had not been fixed properly, we
>> don't re-open it as it represents a specific changeset which was
>> already included in a published release: a published release either
>> contains a changeset (a patch) or it doesn't - we can't manage
>> situations well such as "it had half a fix".
>>
>> # Keep unrelated commits separated
>> For as much as possible, when fixing an issue try to focus on the
>> individual issue exclusively.
>>
>> If you notice an opportunity for refactoring related code, it's ok to
>> include it. But if you notice such opportunities, typos, or have a
>> general urge to rewrite code which isn't necessarily useful to touch
>> during the main patch you're working on - then please make this a
>> separate JIRA and a separate set of commits.
>>
>> --
>>
>> That said, we're very reasonable. Including two kinda related
>> changesets in a same PR is ok, especially if one depends on the other.
>> Including a single typo fix is ok. Sending a "follow-up" PR for a fix
>> which was just merged is fine to reuse the same JIRA - as long as it
>> wasn't released yet (and closed).
>>
>> Also, opening a JIRA doesn't have to take much of your time. We don't
>> require many fields to be filled, and for simple issues it's totally
>> ok to have a short description. You can also learn its shortcuts, or
>> use scripts / command line tools to interact with it, integrate it
>> with your IDE.
>>
>> I'll update the CONTRIBUTING.md as I see we could clarify some of
>> these points there.
>>
>> Many thanks,
>> Sanne
>> ___
>> hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
>> To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[hibernate-dev] Commit messages, and keeping JIRA in synch

[Sanne Grinovero]

Hi all,

looks like it's a good time for me to remind how we need commits
managed, and their relation to JIRA tickets.

When reviewing pull requests, and before merging them, please pay
attention to these simple rules as it's important for long term
maintenance.
We need to be able to query JIRA to figure out which branches and
versions contain a specific patch; it's also useful for people to know
if they might be affected by a specific bug.

# Commit format
ALL commits need to start with the JIRA code which relates to the change.

This implies that any little improvement needs a JIRA ticket created
before being integrated; this is sometimes a little inconvenient, but
please stick to it the same.

The exception to this rule is the release process itself; it's ok for
scripts to push placeholder commits to help identify just-before and
just-after tags.

# Closed JIRA tickets
One should never have a new commit which is recycling a JIRA ticket
which is closed already.

A closed ticket for us means "sealed and archived".

This means that if you discover a better way to fix an issue which is
already closed, you will need to open a new JIRA.
Even if technically the old issue had not been fixed properly, we
don't re-open it as it represents a specific changeset which was
already included in a published release: a published release either
contains a changeset (a patch) or it doesn't - we can't manage
situations well such as "it had half a fix".

# Keep unrelated commits separated
For as much as possible, when fixing an issue try to focus on the
individual issue exclusively.

If you notice an opportunity for refactoring related code, it's ok to
include it. But if you notice such opportunities, typos, or have a
general urge to rewrite code which isn't necessarily useful to touch
during the main patch you're working on - then please make this a
separate JIRA and a separate set of commits.

-- 

That said, we're very reasonable. Including two kinda related
changesets in a same PR is ok, especially if one depends on the other.
Including a single typo fix is ok. Sending a "follow-up" PR for a fix
which was just merged is fine to reuse the same JIRA - as long as it
wasn't released yet (and closed).

Also, opening a JIRA doesn't have to take much of your time. We don't
require many fields to be filled, and for simple issues it's totally
ok to have a short description. You can also learn its shortcuts, or
use scripts / command line tools to interact with it, integrate it
with your IDE.

I'll update the CONTRIBUTING.md as I see we could clarify some of
these points there.

Many thanks,
Sanne
___
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[hibernate-dev] Re: Release Announcement: General Availability of Java 15 / JDK 15

[Sanne Grinovero]

Many thanks Rory!

All, there's plenty of great features here which are relevant to
Hibernate; I hope you're having a look. Unfortunately we're still
aiming at backwards compatibility with Java8 for our main projects,
but I hope some of us will want to start experimenting with these.

Some suggestions:

* JEP 371: Hidden Classes 
Some of the classes we generate might be a good candidate to be
"hidden"? Although I have to warn I haven't fully understood this JEP,
it will require some exploration.

* JEP 378: Text Blocks 
Expressing SQL queries is the canonical example of this JEP; clearly
it's going to be useful for HQL as well. I suppose it will "just
work", but it would be good to verify this, see how it looks, and if
there's improvements we can do to our API / documentation / examples.

* JEP 360: Sealed Classes (Preview) 
For those cases in which we have an SPIs which isn't really meant to
be third-party pluggable.

 * JEP 384: Records (Second Preview) 
Since they are immutable, they aren't a good fit for entities; but
they seem like a great way to represent a scalar query result, as sets
of parameters for queries, and there's possibly some desire to use
them mappeddd as embeddable types.

Thanks,
Sanne


On Tue, 15 Sep 2020 at 15:37, Rory O'Donnell  wrote:
>
> Hi Sanne & Yoann,
>
> **Release Announcement: General Availability of Java 15 / JDK 15 [1]
> **
>
>   * JDK 15, the reference implementation of Java 15, is now Generally
> Available.
>   * GPL-licensed OpenJDK builds from Oracle are available here:
> http://jdk.java.net/15/
>   * JDK 15 Release notes
> 
>
> JDK 15 includes fourteen features [2]:
>
>   * JEP 339: Edwards-Curve Digital Signature Algorithm (EdDSA)
> 
>   * JEP 360: Sealed Classes (Preview) 
>   * JEP 371: Hidden Classes 
>   * JEP 372: Remove the Nashorn JavaScript Engine
> 
>   * JEP 373: Reimplement the Legacy DatagramSocket API
> 
>   * JEP 374: Disable and Deprecate Biased Locking
> 
>   * JEP 375: Pattern Matching for instanceof (Second Preview)
> 
>   * JEP 377: ZGC: A Scalable Low-Latency Garbage Collector
> 
>   * JEP 378: Text Blocks 
>   * JEP 379: Shenandoah: A Low-Pause-Time Garbage Collector
> 
>   * JEP 381: Remove the Solaris and SPARC Ports
> 
>   * JEP 383: Foreign-Memory Access API (Second Incubator)
> 
>   * JEP 384: Records (Second Preview) 
>   * JEP 385: Deprecate RMI Activation for Removal
> 
>
> Thanks to everyone who contributed to JDK 15, whether by creating
> features or enhancements, logging  bugs, or downloading and testing the
> early-access builds.
>
> OpenJDK 16 Early Access build 15**is now available at http://jdk.java.net/16
>
>   * JEPs integrated to JDK 16:
>   o JEP 347: Enable C++14 Language Features
> 
>   o JEP 357: Migrate from Mercurial to Git
> 
>   o JEP 369: Migrate to GitHub 
>
>   * Release Notes are available at http://jdk.java.net/16/release-notes
>
> **
>
>   * Significant changes since the last availability email:
>   o Build 15
>   + JDK-8244090: public lookup should find public members of
> public exported types (Reported by Eclipse Jetty)
>   + JDK-8250968: Symlinks attributes not preserved when using
> jarsigner on zip files
>   o Build 14
>   + JDK-8189744: Deprecate the JDK-specific API for setting
> socket options, jdk.net.Sockets
>   + JDK-8241003: Deprecate "denigrated" java.security.cert APIs
> that represent DNs as Principal or String objects
>   + JDK-8245462: The default HttpClient implementation returns
> cancelable futures
>
>
> *__*
> Rgds,Rory
>
> [1]
> https://mail.openjdk.java.net/pipermail/jdk-dev/2020-September/004733.html
> [2] https://openjdk.java.net/projects/jdk/15/
> --
>
> Rgds, Rory O'Donnell
> Quality Engineering Manager
> Oracle EMEA, Dublin, Ireland
>
> ___
> hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
> To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___

[hibernate-dev] Long live "metamodelgen"

[Sanne Grinovero]

The metamodelgen project has since many years been incorporated in
ORM, so we archived the old repository; the idea was triggered by
contributors sending patches to the wrong codebase.

FYI I've also deleted the maintenance team from Github :
metamodelgen-dev ; it had only Gunnar and Emmanuel in it.

Thanks
___
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[hibernate-dev] Re: regarding more human-friendly table alias

[Sanne Grinovero]

Hi Nathan,

this sounds worthwhile to me at a high level, but I'm not sure about
us being able to implement a reasonable heuristic. In particular, the
mentioned "huffman encoding" doesn't sound like an improvement over
the current strategy? I suppose you're not referring to the
compression algorithm? Maybe I misunderstand, it would help to see a
concrete example.

Thanks

On Wed, 26 Aug 2020 at 14:09, Nathan Xu  wrote:
>
> My point might have been discussed previously. I beg your pardon if my 
> message bothers you.
>
> As everybody knows, Hibernate will create very terse and mystic table alias. 
> I often feel frustrated by them when trying to read the SQL Hibernate has 
> produced. There must be many thoughts behind its current design, I think. 
> Could we achieve the goal to avoid sacrificing SQL readability while having 
> our job done? Needless to say, experienced Hibernate user still needs to 
> understand the auto-generated SQL for many reasons (troubleshooting, 
> optimization),  and a human-friendly SQL might make for a far better user 
> experience.
>
> In terms of implementation, we can simulate human's thinking process when 
> designing a table alias (TBH, sometimes even human is frustrated to think of 
> a most satisfying alias). Many heuristics could be applied (e.g., hufman 
> encoding algorithm) and it would be a good selling point for v6.
>
> Any thoughts? Again, pardon me if the point has been discussed previously.
> ___
> hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
> To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[hibernate-dev] Re: Regarding lazy initialization of ArrayList

[Sanne Grinovero]

On Wed, 19 Aug 2020 at 13:48, Nathan Xu  wrote:
>
> Thanks for the null-check tip! I appreciate that.
>
> As a matter of fact, NPE issue still bothers us a lot. This recent PR from 
> the community is another validation: 
> https://github.com/hibernate/hibernate-orm/pull/3499How to systematically 
> combat NPE is a good topic and still highly relevant. Maybe we can talk about 
> it later.
>
> I didn't anticipate we should abandon the 'lazy initialization' pattern 
> totally (even when we limited its scope to ArrayList constructed by default 
> constructor). My point is to raise the awareness that  since JDK7, ArrayList 
> has a lazy-initialization feature built-in already. We still pay the cost to 
> create an empty ArrayList (without allocating 10 elements in advance), but 
> the overhead might be worthwhile for it leads to a more elegant and 
> maintainable codebase.

Noted, thanks. But I still recommend to keep this pattern as the
overhead has been proven to be very significant in some cases. We'll
just need to be careful with any change, but that's always the case :)
___
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[hibernate-dev] Released Hibernate ORM 5.4.20.Final

[Sanne Grinovero]

Hi all,

we just published Hibernate ORM 5.4.20.Final

It contains the usual set of minimally intrusive and non-exciting
bugfixes, and I'm happy with that.

https://in.relation.to/2020/08/10/hibernate-orm-5/

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

Re: [hibernate-dev] Dropping support for Java 8 in Hibernate ORM (Search) v6 ?

[Sanne Grinovero]

d releases with JDK11 (and -release 8), so it may be an
> > option.
> >
> >
> > Yoann Rodière
> > Hibernate Team
> > yo...@hibernate.org
> >
> >
> > On Fri, 24 Jul 2020 at 16:23, Christian Beikov  > >
> > wrote:
> >
> > > Hey,
> > >
> > > I'm not sure it is a good idea to do this for Hibernate ORM 6 already as
> > > that would probably hinder adoption. Some projects just didn't update to
> > > Java 9+ yet because using the newer versions would have no real benefit.
> > >
> > > We can use the Multi-Release JAR feature to make use of JDK features
> > > introduced in newer Java versions. Since the Java 11 doesn't provide any
> > > significant languages changes for which it would be worth dropping
> > > support for Java 8, I see no reason for raising the minimum version
> > > requirement.
> > >
> > > We can benefit from Jigsaw already by defining module-info file and let
> > > the moditect plugin(from Gunnar) compile it. If necessary, we can make
> > > use of the Multi-Release JAR feature to use the module system APIs.
> > >
> > > How about raising the minimum Java version for Hibernate ORM 7 instead?
> > >
> > > Regards,
> > >
> > > Christian
> > >
> > > Am 24.07.2020 um 16:00 schrieb Sanne Grinovero:
> > > > Hi all,
> > > >
> > > > [meta: I had this email as a draft on hold since a year; very glad to
> > > > finally be able to send it.]
> > > >
> > > > We're usually quite conservative in dropping support for older JDKs
> > > > within the Hibernate team, but there's an increasing maintenance (and
> > > > development) cost when keeping older JDK compatibility for too long.
> > > >
> > > > In particular, Java 8 compatibility was so far still a requirement for
> > > > various strategic integrations; first, we had runtimes targeting
> > > > GraalVM still needing it, but they support Java 11 now as well; after
> > > > that, Azure Functions were also still requiring Java 8, but this
> > > > limitation was resolved now.
> > > >
> > > > We're aware that Java 8 is still widely used; still I think we need to
> > > > look forward - for various reasons, including maintenance burden, and
> > > > to deliver a better experience on the later versions of the JDK. Also,
> > > > looking at the existing usage statistics implies a fallacy: that's
> > > > current production usage, while the code we normally work is
> > > > (typically) not going to see production usage for quite some time.
> > > >
> > > > While we'll want to keep Java 8 compatibility for existing
> > > > [maintained] releases, there is no compelling reason anymore to keep
> > > > doing this for the upcoming major releases.
> > > >
> > > > So I'd propose we require Java 11 the minimum compatible runtime for
> > > > ORM v6 onward, and I'd suggest we do the same with all our actively
> > > > developed projects.
> > > >
> > > > Initially, I don't really expect this to significantly increase the
> > > > efforts from our already packed roadmaps: in the first stage this
> > > > proposal is literally only about making minimal changes to our build
> > > > scripts to change the compatibility versions, and for CI to stop
> > > > testing the JDK/branches combinations which are no longer supported.
> > > >
> > > > In a second step, as convenient, we'll be able to:
> > > >   - do some code cleanup / refactorings to benefit from the minor API
> > > > improvements of the JDK
> > > >   - some APIs had more substantial improvements, such as java.sql now
> > > > features native support for multi-tenancy, literals and identifiers
> > > > enquoting [among others] .. might be interesting.
> > > >   - finally benefit from Jigsaw?
> > > >
> > > > Any thoughts?
> > > >
> > > > Thanks,
> > > > Sanne
> > > > ___
> > > > hibernate-dev mailing list
> > > > hibernate-dev@lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > > ___
> > > hibernate-dev mailing list
> > > hibernate-dev@lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > >
> > >
> > ___
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

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

Re: [hibernate-dev] Bad boot performance since 5.4 switched to ByteBuddy

[Sanne Grinovero]

 > Does anyone know if there is a known performance issue [...]

I'm aware that loading Byte Buddy takes a little longer than Javassist
to initialize: it's a larger library and it needs to load a
significantly larger number of classes, including ASM, but this comes
with several benefits so as long as the cost is not disproportionate,
I wouldn't see it as a performance issue.

How bad is it in absolute numbers? Is the highlighted problem specific
to a particular bootstrap configuration, such as a particular
container or a particular way of booting it? Lots of entities, or very
few of them?

Also, are you concerned about "cold boot" as in bootstrapping a new
JVM+Hibernate, or about (re)starting an ORM instance in a running JVM?

+1 to Guillaume's suggestions: if you can point a finger to a specific
problematic area we might be able to do something about it.

Tangentially: having to currently support both ByteBuddy and Javassist
complicates things quite a bit, and complications also come at a
performance cost. I wish to fully remove Javassist in 6 - for other
reasons as well - and I believe that doing so will allow us to improve
some integration with BB.
But it would be interesting to know more about this problem, so to
make sure we go into the right direction.

Thanks

On Tue, 4 Aug 2020 at 19:15, Guillaume Smet  wrote:
>
> If you can get some SVG profiles from Async Profiler, that would help to
> determine what we can do to improve things.
>
> And yes, we don't want the BB state to be static again. We had a hard time
> avoiding the static here and I don't remember exactly why but it was for
> sure worth it or I wouldn't have spent time on it :).
>
> --
> Guillaume
>
> On Tue, Aug 4, 2020 at 6:28 PM Yoann Rodiere  wrote:
>
> > > @Yoann: It seems the commit you posted is about supporting a
> > > SecurityManager environment, but I'm not sure how making the state an
> > > instance variable rather than static helps with this. What kind of
> > > buggyness are you referring to?
> >
> > Not sure what the bug was; I just remember there was a problem (multiple
> > problems?) related to the bytebuddy state being static. Maybe the bytebuddy
> > state does change from one execution to the other, depending on the
> > classpath, security manager, or whatever. Maybe it was just a problem when
> > running tests and changing some classes from one test to another, or
> > changing the security manager. To be honest I don't remember. Maybe 
> > @Guillaume
> > Smet  remembers, but that was two years ago...
> >
> > Yoann Rodière
> > Hibernate Team
> > yo...@hibernate.org
> >
> >
> > On Tue, 4 Aug 2020 at 18:17, Christian Beikov 
> > wrote:
> >
> >> Hey,
> >>
> >> sorry for the confusion. "Apparently" was the wrong word I guess, my
> >> colleague Moritz Becker ran a few CPU sampling rounds with JFR which is
> >> how we found out about this, so this is more like "the data suggests"
> >> that the problem is in ByteBuddy.
> >>
> >> I can do some profiling with the async-profiler as well, but I the issue
> >> definitely is the proxy building code.
> >>
> >> @Yoann: It seems the commit you posted is about supporting a
> >> SecurityManager environment, but I'm not sure how making the state an
> >> instance variable rather than static helps with this. What kind of
> >> buggyness are you referring to?
> >>
> >> Am 04.08.2020 um 17:56 schrieb Guillaume Smet:
> >> > Hi Christian,
> >> >
> >> > I don't like "apparently" when talking about performances :).
> >> >
> >> > I would advise to use async profiler
> >> > (https://github.com/jvm-profiling-tools/async-profiler, also see
> >> > https://github.com/quarkusio/quarkus/blob/master/TROUBLESHOOTING.md to
> >> > learn more on how to use it) to try to understand what's going wrong
> >> > and how we could improve things.
> >> >
> >> > I remember things were very slow with the initial ByteBuddy
> >> > implementation Rafael did and we got much better results by caching
> >> > the ByteBuddy transformations. In particular the calls to the
> >> > ByteBuddy DSL are quite expensive in terms of allocations because they
> >> > are creating a ton of objects.
> >> >
> >> > Once we have some profiling results, we can talk.
> >> >
> >> > --
> >> > Guillaume
> >> >
> >> > On Tue, Aug 4, 2020 at 5:26 PM Christian Beikov
> >> > mailto:christian.bei...@gmail.com>> wrote:
> >> >
> >> > I'm moving this discussion from Zulip to the mailing list as
> >> > Rafael does
> >> > not seem to be on Zulip. Here a little context:
> >> >
> >> >  > Does anyone know if there is a known performance issue with
> >> > Bytebuddy
> >> > during boot in 5.4? I noticed that 5.4 takes about 25%, sometimes
> >> > up to
> >> > 30% percent longer to boot, even when using a prebuilt Jandex index,
> >> > apparently due to the use of Bytebuddy
> >> >
> >> >  > @Moritz Becker found the issue while trying to find out why our
> >> > Blaze-Persistence testsuite runs into CI timeouts with 5.4 but not
> 

[hibernate-dev] Dropping support for Java 8 in Hibernate ORM (Search) v6 ?

[Sanne Grinovero]

Hi all,

[meta: I had this email as a draft on hold since a year; very glad to
finally be able to send it.]

We're usually quite conservative in dropping support for older JDKs
within the Hibernate team, but there's an increasing maintenance (and
development) cost when keeping older JDK compatibility for too long.

In particular, Java 8 compatibility was so far still a requirement for
various strategic integrations; first, we had runtimes targeting
GraalVM still needing it, but they support Java 11 now as well; after
that, Azure Functions were also still requiring Java 8, but this
limitation was resolved now.

We're aware that Java 8 is still widely used; still I think we need to
look forward - for various reasons, including maintenance burden, and
to deliver a better experience on the later versions of the JDK. Also,
looking at the existing usage statistics implies a fallacy: that's
current production usage, while the code we normally work is
(typically) not going to see production usage for quite some time.

While we'll want to keep Java 8 compatibility for existing
[maintained] releases, there is no compelling reason anymore to keep
doing this for the upcoming major releases.

So I'd propose we require Java 11 the minimum compatible runtime for
ORM v6 onward, and I'd suggest we do the same with all our actively
developed projects.

Initially, I don't really expect this to significantly increase the
efforts from our already packed roadmaps: in the first stage this
proposal is literally only about making minimal changes to our build
scripts to change the compatibility versions, and for CI to stop
testing the JDK/branches combinations which are no longer supported.

In a second step, as convenient, we'll be able to:
 - do some code cleanup / refactorings to benefit from the minor API
improvements of the JDK
 - some APIs had more substantial improvements, such as java.sql now
features native support for multi-tenancy, literals and identifiers
enquoting [among others] .. might be interesting.
 - finally benefit from Jigsaw?

Any thoughts?

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

Re: [hibernate-dev] Bytecode enhancement as proxy

[Sanne Grinovero]

+1 Great idea

On Tue, 7 Jul 2020 at 13:15, andrea boriero  wrote:
>
> Hi all,
>
> Last year the Bytecode enhancement as proxy feature was introduced (see
> https://in.relation.to/2019/07/30/bytecode-proxy/ for details) and the
> hibernate.bytecode.allow_enhancement_as_proxy was added to enable/disable
> the new feature.
>
> In ORM 5.3 and 5.4 versions this feature is disabled by default, I was
> wondering if it is a good idea for the future ORM 5.5 release to make
> it enabled by default.
>
> Thanks,
> Andrea
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] My email

[Sanne Grinovero]

Sure that's not a problem.

However, 6.x has many open issues still - it might be best to track
things on JIRA as usual:
 - https://hibernate.atlassian.net/secure/Dashboard.jspa

Either way is fine in principle, just normally we use the list to
discuss proposals; for example if you plan to contribute a fix and
have questions, or just want to let others know that you're looking at
it then the list is more suitable.

Thanks!

On Wed, 3 Jun 2020 at 11:26, Catalin Tudose  wrote:
>
> Great, thank you!
> There is a possible issue I discovered with 6.0.0.Alpha5.
> Would that be fine to share it on this list?
>
> On Wed, Jun 3, 2020 at 1:22 PM Sanne Grinovero  wrote:
>>
>> Hi Catalin,
>>
>> looks like you managed to post to the list!
>>
>> welcome,
>> Sanne
>>
>> On Wed, 3 Jun 2020 at 11:15, Catalin Tudose  wrote:
>> >
>> > Hello!
>> >
>> > I would like to post to the hibernate-dev@lists.jboss.org mailing list!
>> > My e-mail is catalin.tud...@gmail.com
>> >
>> > Thank you!
>> > ___
>> > hibernate-dev mailing list
>> > hibernate-dev@lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] My email

[Sanne Grinovero]

Hi Catalin,

looks like you managed to post to the list!

welcome,
Sanne

On Wed, 3 Jun 2020 at 11:15, Catalin Tudose  wrote:
>
> Hello!
>
> I would like to post to the hibernate-dev@lists.jboss.org mailing list!
> My e-mail is catalin.tud...@gmail.com
>
> Thank you!
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Hibernate Reactive: Release day!

[Sanne Grinovero]

It's released. Version 1.0.0.Alpha1 (not 0.0.1 as I mentioned in my
previous email)

Kudos to Yoann, as it's fully automated and it takes just under a
minute to do the release - we should definitely try to do the same on
other projects.

On Fri, 29 May 2020 at 15:14, Sanne Grinovero  wrote:
>
> Hi all,
>
> we're about to test a first automated release.. Hibernate Reactive v. 0.0.1
>
> I expect some of you might be annoyed that they had "one more cool
> improvement" which didn't make it; don't be: the release process is
> highly automated (thanks to Yoann!) and we will have many more
> triggered in the following days as we polish the process.
>
> Thanks,
> Sanne
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Hibernate Reactive: Release day!

[Sanne Grinovero]

Hi all,

we're about to test a first automated release.. Hibernate Reactive v. 0.0.1

I expect some of you might be annoyed that they had "one more cool
improvement" which didn't make it; don't be: the release process is
highly automated (thanks to Yoann!) and we will have many more
triggered in the following days as we polish the process.

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

Re: [hibernate-dev] v6 and load-event

[Sanne Grinovero]

On Fri, 29 May 2020 at 07:22, Yoann Rodiere  wrote:
>
> +1 not to add surround capability initially. Sounds better to start simple 
> and make things more complex when we actually need it :)

Right. I didn't mean to raise additional requirements without having
investigated those tracing libraries - what I meant really is just to
raise awareness that we'll likely need to evolve it further when it
comes to finally implement such things.

>
> Yoann Rodière
> Hibernate Team
> yo...@hibernate.org
>
>
> On Fri, 29 May 2020 at 07:25, Sanne Grinovero  wrote:
>>
>> Yes, I agree.
>>
>> On Thu, 28 May 2020, 22:11 Steve Ebersole,  wrote:
>>>
>>> Wanted to clarify -
>>>
>>> Regarding incremental addition of "surround listeners", so long as we are 
>>> all in agreement that this simply means there will be absolutely no 
>>> surround capability ***initially*** then I am fine with that.
>>>
>>> On Thu, May 28, 2020 at 4:10 PM Steve Ebersole  wrote:
>>>>
>>>> Hm, the dynamic enable/disable stuff should be easy to handle, no?  
>>>> Depends on what specific library you are thinking of and exactly how that 
>>>> detail gets propagated to us.  At the end of the day, its really as simple 
>>>> as protecting the creation of some of these objects with `if 
>>>> (enabled)`-type checks.
>>>>
>>>> But again, if you have specific details in mind we can take a look.
>>>>
>>>> Also, I think it is not at all a good idea to even plan for "different 
>>>> types of events".  In fact I'm fine with getting rid of LoadEvent 
>>>> completely from that contract and simply directly passing the information 
>>>> that is likely useful.  I mean at the end of the day a listener for load 
>>>> events is going to be interested in the same set of information.  Yes, 
>>>> some will not need all of that information but that's not really a concern 
>>>> IMO.  Especially if we inline the parameters and completely avoid the 
>>>> event object instantiation
>>>>
>>>> Regarding incremental addition of "surround listeners", so long as we are 
>>>> all in agreement that this simply means there will be absolutely no 
>>>> surround capability then I am fine with that.
>>>>
>>>>
>>>> On Thu, May 28, 2020 at 3:55 PM Sanne Grinovero  
>>>> wrote:
>>>>>
>>>>> On Thu, 28 May 2020 at 21:27, Steve Ebersole  wrote:
>>>>> >
>>>>> > Any thoughts on this "continuation" approach?
>>>>>
>>>>> I love the pattern! Maybe we'll need also some ability to not capture
>>>>> the state for events which don't have any?
>>>>>
>>>>> I wonder if that implies we'll need two different event contracts: one
>>>>> for the listeners which need state and one for those which don't; but
>>>>> I'm not eager to overcomplicate this.
>>>>>
>>>>> > Or maybe its just not important (yet) to handle "surround" handling?
>>>>>
>>>>> I'm confident that integration with tracing libraries would be very
>>>>> useful and interesting to have - but indeed not having time to
>>>>> research it properly I'm a bit afraid that it might need further
>>>>> changes to reach excellent performance.
>>>>>
>>>>> For example one thing I remember is that with some libraries you're
>>>>> supposed to have the option to enable/disable the profiling options
>>>>> dynamically, and since there's an expectation of no overhead when it's
>>>>> disabled this would need to imply having a way for the overhead of
>>>>> allocating space for the captured state to "vanish": this might be a
>>>>> bit more complicated, or need to be able to take advantage of JIT
>>>>> optimisations.
>>>>>
>>>>> So if we end up thinking that such event APIs need to be different
>>>>> depending on the need for state, perhaps indeed it's better to
>>>>> postpone the design of those with state to when someone has time to
>>>>> research an optimal integration with a tracing library. It might not
>>>>> be too hard, I just haven't explored it myself yet.
>>>>>
>>>>> Maybe let's do this incrementally, considering the "continuation"
>>>>> approach a next 

Re: [hibernate-dev] v6 and load-event

[Sanne Grinovero]

Yes, I agree.

On Thu, 28 May 2020, 22:11 Steve Ebersole,  wrote:

> Wanted to clarify -
>
> Regarding incremental addition of "surround listeners", so long as we are
> all in agreement that this simply means there will be absolutely no
> surround capability ***initially*** then I am fine with that.
>
> On Thu, May 28, 2020 at 4:10 PM Steve Ebersole 
> wrote:
>
>> Hm, the dynamic enable/disable stuff should be easy to handle, no?
>> Depends on what specific library you are thinking of and exactly how that
>> detail gets propagated to us.  At the end of the day, its really as simple
>> as protecting the creation of some of these objects with `if
>> (enabled)`-type checks.
>>
>> But again, if you have specific details in mind we can take a look.
>>
>> Also, I think it is not at all a good idea to even plan for "different
>> types of events".  In fact I'm fine with getting rid of LoadEvent
>> completely from that contract and simply directly passing the information
>> that is likely useful.  I mean at the end of the day a listener for load
>> events is going to be interested in the same set of information.  Yes, some
>> will not need all of that information but that's not really a concern IMO.
>> Especially if we inline the parameters and completely avoid the event
>> object instantiation
>>
>> Regarding incremental addition of "surround listeners", so long as we are
>> all in agreement that this simply means there will be absolutely no
>> surround capability then I am fine with that.
>>
>>
>> On Thu, May 28, 2020 at 3:55 PM Sanne Grinovero 
>> wrote:
>>
>>> On Thu, 28 May 2020 at 21:27, Steve Ebersole 
>>> wrote:
>>> >
>>> > Any thoughts on this "continuation" approach?
>>>
>>> I love the pattern! Maybe we'll need also some ability to not capture
>>> the state for events which don't have any?
>>>
>>> I wonder if that implies we'll need two different event contracts: one
>>> for the listeners which need state and one for those which don't; but
>>> I'm not eager to overcomplicate this.
>>>
>>> > Or maybe its just not important (yet) to handle "surround" handling?
>>>
>>> I'm confident that integration with tracing libraries would be very
>>> useful and interesting to have - but indeed not having time to
>>> research it properly I'm a bit afraid that it might need further
>>> changes to reach excellent performance.
>>>
>>> For example one thing I remember is that with some libraries you're
>>> supposed to have the option to enable/disable the profiling options
>>> dynamically, and since there's an expectation of no overhead when it's
>>> disabled this would need to imply having a way for the overhead of
>>> allocating space for the captured state to "vanish": this might be a
>>> bit more complicated, or need to be able to take advantage of JIT
>>> optimisations.
>>>
>>> So if we end up thinking that such event APIs need to be different
>>> depending on the need for state, perhaps indeed it's better to
>>> postpone the design of those with state to when someone has time to
>>> research an optimal integration with a tracing library. It might not
>>> be too hard, I just haven't explored it myself yet.
>>>
>>> Maybe let's do this incrementally, considering the "continuation"
>>> approach a next step?
>>>
>>> Thanks,
>>> Sanne
>>>
>>> >
>>> > On Wed, May 27, 2020 at 9:27 AM Steve Ebersole 
>>> wrote:
>>> >>
>>> >> Inline...
>>> >>
>>> >> On Wed, May 27, 2020 at 8:10 AM Sanne Grinovero 
>>> wrote:
>>> >>>
>>> >>> At high level I agree, just have 3 more thoughts:
>>> >>>
>>> >>> # Regarding the "swap" of information between listeners - could that
>>> >>> even work? I might have misunderstood something, but wouldn't we
>>> >>> require listeners to run in some specific order for such swapping to
>>> >>> work?
>>> >>
>>> >>
>>> >> This is why we allow control over the ordering of the registered
>>> listeners.  And yes, that is and was a hokey solution.  Nothing changes
>>> there really if that is why you are using load listener.
>>> >>
>>> >>
>>> >>>
>>> >>

Re: [hibernate-dev] v6 and load-event

[Sanne Grinovero]

On Thu, 28 May 2020 at 21:27, Steve Ebersole  wrote:
>
> Any thoughts on this "continuation" approach?

I love the pattern! Maybe we'll need also some ability to not capture
the state for events which don't have any?

I wonder if that implies we'll need two different event contracts: one
for the listeners which need state and one for those which don't; but
I'm not eager to overcomplicate this.

> Or maybe its just not important (yet) to handle "surround" handling?

I'm confident that integration with tracing libraries would be very
useful and interesting to have - but indeed not having time to
research it properly I'm a bit afraid that it might need further
changes to reach excellent performance.

For example one thing I remember is that with some libraries you're
supposed to have the option to enable/disable the profiling options
dynamically, and since there's an expectation of no overhead when it's
disabled this would need to imply having a way for the overhead of
allocating space for the captured state to "vanish": this might be a
bit more complicated, or need to be able to take advantage of JIT
optimisations.

So if we end up thinking that such event APIs need to be different
depending on the need for state, perhaps indeed it's better to
postpone the design of those with state to when someone has time to
research an optimal integration with a tracing library. It might not
be too hard, I just haven't explored it myself yet.

Maybe let's do this incrementally, considering the "continuation"
approach a next step?

Thanks,
Sanne

>
> On Wed, May 27, 2020 at 9:27 AM Steve Ebersole  wrote:
>>
>> Inline...
>>
>> On Wed, May 27, 2020 at 8:10 AM Sanne Grinovero  wrote:
>>>
>>> At high level I agree, just have 3 more thoughts:
>>>
>>> # Regarding the "swap" of information between listeners - could that
>>> even work? I might have misunderstood something, but wouldn't we
>>> require listeners to run in some specific order for such swapping to
>>> work?
>>
>>
>> This is why we allow control over the ordering of the registered listeners.  
>> And yes, that is and was a hokey solution.  Nothing changes there really if 
>> that is why you are using load listener.
>>
>>
>>>
>>> # The "surround advice" you mention for e.g. timing seems very
>>> interesting, especially as I'd love us to be able to integrate with
>>> tracing libraries - but these would need to be able to co-relate the
>>> pre-load event with some post-load event. How would that work?  I'd
>>> expect these to need having a single listener implementation which
>>> implements both PreLoadEventListener and PostLoadEventListener, but
>>> also they'll likely need some capability to store some information
>>> contextual to the "event".
>>
>>
>> I was just thinking through this one as well.  My initial thought was 
>> exactly what you proposed - some combination of pre/post listener with some 
>> ability to store state between.  But that gets ugly.
>>
>> Another option I thought about is easier to illustrate, but basically works 
>> on the principle of "continuation" many surround advice solutions are based 
>> on: https://gist.github.com/sebersole/142765fe2417492061e92726e7cb6bd8
>>
>> I kept the name LoadEventListener there, but since it changes the contract 
>> anyway I'd probably rename this to something like SurroundLoadEventListener
>>
>>
>>>
>>> # To clarify on my previous comment regarding why I'd consider having
>>> an actual Event class more maintainable:
>>> Sure we won't have inline classes widely used for a while, but I
>>> prefer planning for the long term - also we could start using them
>>> very soon via multi-release jars, which would simply imply that users
>>> on newer JDKs would see more benefits than other users.
>>> But especially, such event instances are passed over and over across
>>> many methods; so in terms of maintenance and readability, such methods
>>> would need to pass many parameters rather than one: the example made
>>> above is oversimplifying our use.  Also while I understand it's
>>> unlikely, having a "cheap" event objects makes it easier to change the
>>> exact types being passed on.
>>> BTW stack space is cheap but forcing many references to be passed when
>>> one single reference could do might also have some performance
>>> implications since these are passed many times - I've never tested
>>> this scientifically though :)   Inline objects would typically be
>>&

Re: [hibernate-dev] v6 and load-event

[Sanne Grinovero]

>> Another advantage is we separate the "SPI"/internal interface (Handler) from 
>> the API that can be implemented by users (listeners).
>> That could be a great help moving forward to evolve Hibernate ORM without 
>> breaking APIs.
>>
>> > but I wonder about the readability of the code.
>>
>> I was thinking that it was actually *more* readable. Maybe it's just a 
>> matter of taste, but this:
>>
>> Object loaded = handler.load( param1, param2, ... )
>>
>> Seems considerably more straightforward than this:
>>
>> LoadEvent event = new LoadEvent( param1, param2, ... )
>> for (LoadListener listener: listeners) {
>>listener.onLoad( event );
>> }
>> Object loaded = event.getLoaded();
>>
>> Especially if you consider that with the handler, the implementation of 
>> loading is just one CTRL+click away.
>> With listeners you have to go through all the listener implementations and 
>> find which one actually implements loading.
>> Not a problem with load since there's only one implementation, but I know 
>> I've had trouble with other events in the past.
>>
>> The devil is in the details, though. I admit it could get more complex if 
>> multiple return values are necessary, and maybe there are other problems 
>> with this approach that we can't see right away.
>> But still, I think it's worth a try.
>>
>> > With "inline types" coming soon to the JDK, the event object
>> types could be great candidates to be converted into inline?
>>
>> Aren't you talking about JDKs that we won't be able to use as the baseline 
>> for Hibernate ORM for a few years at least? If so, Steve's change seems 
>> worthwhile, if only in the meantime.
>>
>>
>>
>> Yoann Rodière
>> Hibernate Team
>> yo...@hibernate.org
>>
>>
>> On Tue, 26 May 2020 at 20:17, Sanne Grinovero  wrote:
>>>
>>> Hi Steve,
>>>
>>> looks like you're getting rid of the "event object"? No more events to
>>> be allocated?
>>>
>>> I think that's a great idea, but I wonder about the readability of the
>>> code. With "inline types" coming soon to the JDK, the event object
>>> types could be great candidates to be converted into inline?
>>>
>>> If we used the inline types for such things I'm confident that
>>> allocation would improve significantly; it's undeniable that not
>>> having anything-at-all would be even better - but perhaps it could be
>>> a better tradeoff in consideration of maintainability.
>>>
>>> I also noticed that it's quite possible that some "list of
>>> eventlisteners" for a specific event type could be empty: no listeners
>>> at all.
>>> So an aspect that could be worth exploring while thinking about the
>>> event system design, is to avoid creating en event in such cases;
>>> there's an example of this approach already in
>>> org.hibernate.internal.SessionImpl#internalClear : the signature I had
>>> to use is a bit puzzling, but it manages to avoid allocating the event
>>> (unless needed) and also avoids allocating the iterator on the
>>> listeners.
>>>
>>> For example PostLoad events by default have a single listener, but
>>> looking more closely I believe we could avoid registering that single
>>> listener depending on configuration.
>>>
>>> Thanks,
>>> Sanne
>>>
>>>
>>>
>>> On Tue, 26 May 2020 at 16:00, Steve Ebersole  wrote:
>>> >
>>> > Historically we made a terrible design mistake with the event system as a
>>> > whole.  This has both a confusing design impact and a very real 
>>> > performance
>>> > impact.  The main problem is the smashing together of things that handle
>>> > events and things that listen to such events.
>>> >
>>> > In working on a problem in v6 I have come to a point where fixing this
>>> > design flaw for load events specifically would be a huge help.  So I'm
>>> > going to make a proposal for how to specifically change this for load 
>>> > event
>>> > handling.  The plan at the moment is to not make similar changes to the
>>> > other event types for now, though I certainly would like to keep them all
>>> > in mind with regard to the overall design for if/when we can get to the
>>> > others.
>>> >
>>> > So I'd love feedback specifically regarding (1) general design considering
>>> > other event types and (2) issues/concerns specific to load event type.
>>> >
>>> > I created a simple example at
>>> > https://gist.github.com/sebersole/2a1c3ac010a166fc91e62b088179678d
>>> >
>>> > Thanks!
>>> > ___
>>> > hibernate-dev mailing list
>>> > hibernate-dev@lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> >
>>> ___
>>> hibernate-dev mailing list
>>> hibernate-dev@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>

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

Re: [hibernate-dev] v6 and load-event

[Sanne Grinovero]

Hi Steve,

looks like you're getting rid of the "event object"? No more events to
be allocated?

I think that's a great idea, but I wonder about the readability of the
code. With "inline types" coming soon to the JDK, the event object
types could be great candidates to be converted into inline?

If we used the inline types for such things I'm confident that
allocation would improve significantly; it's undeniable that not
having anything-at-all would be even better - but perhaps it could be
a better tradeoff in consideration of maintainability.

I also noticed that it's quite possible that some "list of
eventlisteners" for a specific event type could be empty: no listeners
at all.
So an aspect that could be worth exploring while thinking about the
event system design, is to avoid creating en event in such cases;
there's an example of this approach already in
org.hibernate.internal.SessionImpl#internalClear : the signature I had
to use is a bit puzzling, but it manages to avoid allocating the event
(unless needed) and also avoids allocating the iterator on the
listeners.

For example PostLoad events by default have a single listener, but
looking more closely I believe we could avoid registering that single
listener depending on configuration.

Thanks,
Sanne



On Tue, 26 May 2020 at 16:00, Steve Ebersole  wrote:
>
> Historically we made a terrible design mistake with the event system as a
> whole.  This has both a confusing design impact and a very real performance
> impact.  The main problem is the smashing together of things that handle
> events and things that listen to such events.
>
> In working on a problem in v6 I have come to a point where fixing this
> design flaw for load events specifically would be a huge help.  So I'm
> going to make a proposal for how to specifically change this for load event
> handling.  The plan at the moment is to not make similar changes to the
> other event types for now, though I certainly would like to keep them all
> in mind with regard to the overall design for if/when we can get to the
> others.
>
> So I'd love feedback specifically regarding (1) general design considering
> other event types and (2) issues/concerns specific to load event type.
>
> I created a simple example at
> https://gist.github.com/sebersole/2a1c3ac010a166fc91e62b088179678d
>
> Thanks!
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Beyond checkstyle

[Sanne Grinovero]

Hi all,

in Quarkus we're using a plugin which automatically reformats the code
and sorts imports.

In our older projects we've been using checkstyle; the goal has always
been to try to avoid conflicts and improve readability, but to try to
impose such consistency typically leads to a significant annoyance and
waste of time during development - so imposing checkstyle hans't been
very popular, and certainly comes at a cost.

So the idea in Quarkus has this nice effect: rather than getting "in
the way" it uses a plugin which automatically fixes the code, one
needs to just add the further changes to version control (CI can be
setup to fail rather than fix). The plugin used by Quarkus have some
drawbacks though: the code style can't be configured, and it happens
to look very different than the Hibernate conventions so I don't think
it would be useful for us.

With Hibernate Reactive I started now to explore a new tool which looks better:
 - 
https://github.com/hibernate/hibernate-reactive/pull/191/commits/c7c47c4c990da945e6058631a2eddfdb06ca7e05

This one is rather flexible and configurable, great support for
Gradle, and can also be set to automatically fix the code rather than
complain.

We're going to use it on Hibernate Reactive to enforce only some
essentials: license headers, remove unused imports, remove end-of-line
whitespace.  I suppose we could start using it for some more advanced
rules later, but I'd be cautious about it. One high on my list of
wishlist is to have imports sorted in a standard way, as that's
another source of totally pointless, annoying conflicts.

Other projects might want to explore using it as well?

It supposedly supports Maven as well; haven't tests it though.
See:
 - https://github.com/diffplug/spotless

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

[hibernate-dev] Branch protections: enabling selected maintainers on older branches

[Sanne Grinovero]

Hi all,

yesterday I pushed a fix on Hibernate ORM branch 5.3 by mistake and
had to apologize to Gail, since we're to be very conservative with
that branch and she needs to be able to track and approve any changes
on this specific branch.

This made me check if there was a way to express such rules on github,
and there is: the "branch protection" feature can now apply different
rules, such as requiring to be a member of a specific team, on a
specific branch.

I like that: we can allow most current committers to keep working on
any branches in active development, such as master, while only a more
restricted group can push freely on selected older branches.

Of course admins can always change the settings if there's compelling
need; in this case I like the self-imposed restriction as it would
help avoid mistakes - such as trying to be helpful when too tired.

So I enabled this on 5.3 already .. I hope you agree it's a welcome
change, but we can of course reverse this if there's strong concerns,
or if we regret it later.

Thoughts? I'd assume other Hibernate projects might want to do a
similar thing; among other benefits it might make it easier to give
push permissions to new volunteers, withouth needing to impose on them
all the responsibilities and more complex processes we have for
maintenance branches.

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

Re: [hibernate-dev] #3401

[Sanne Grinovero]

Thanks for the heads up, I had not noticed this PR.

We're planning an ORM release in the early afternoon - mainly as
Quarkus has the code freeze tonight and there are some bugfixes they
will need.  So let's try to get all Reactive things in too - but if
they aren't ready by approx ~15h today we can do another release in a
few days.

They all seem simple enough so just push it:)

On Mon, 18 May 2020 at 11:26, Gavin King  wrote:
>
> We need to get this pull request on ORM applied ASAP, since it's
> currently blocking us from doing work.
>
> --
> Gavin King
> IBM
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Renamed the Hibernate Reactive repository

[Sanne Grinovero]

Hi all,

I've just renamed the repository on github.

Please update your bookmarks, scripts, git remotes and habits :)
 - https://github.com/hibernate/hibernate-reactive

I see github automatically activated redirects, but I don't know how
well that works.

You might want to rename your own forks as well?

sorry for the inconvenience, better soon than later!

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

[hibernate-dev] Jakarta EE 9 / JPA 3: reverting changes from master

[Sanne Grinovero]

Hi all,

in previous emails I mentioned I suggested to release a JPA3
compatible version of Hibernate ORM out soon, as I expected this to be
the natural way forward, and soon to be needed by other projects such
as WildFly. I had started working on this myself.

However, the WildFly team hasn't decided if/when they will adopt the
new Jakarta EE APIs, and I've been advised by many that this upgrade
is unlikely to be in high demand:
it brings no new benefits at all, while it introduces quite some
annoying breaking changes.

We have a fairly complete prototype in the draft PR I've sent here:
 - https://github.com/hibernate/hibernate-orm/pull/3373

And yet, I think I'll "put it in the freezer". Unfortunately I had
already merged some preparations work in 5.5, such as upgrading to
Validator 7.x: I will revert those changes, apologies for that mess
but I think it's for the best to postpone this for later.

When there will be more interest in this, it should not be too hard to
adapt the work as it's mostly strucutured in the form of replacement
scripts which should apply nicely w/o any conflict even on future
branches.

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

Re: [hibernate-dev] [hibernate-announce] ORM 6.0 Alpha5 released

[Sanne Grinovero]

Awesome! And great blog, it's nice to see so much progress.

On Mon, 27 Apr 2020 at 18:10, Steve Ebersole  wrote:
>
> https://in.relation.to/2020/04/24/hibernate-orm-600-Alpha5-release/
> ___
> hibernate-announce mailing list
> hibernate-annou...@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-announce
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] run a single unit test speed up?

[Sanne Grinovero]

On Thu, 23 Apr 2020 at 13:20, Jason Pyeron  wrote:
>
> > -Original Message-
> > From: Sanne Grinovero
> > Sent: Thursday, April 23, 2020 8:04 AM
> >
> > Hi Jason,
> >
> > I'm surprised. It's not instantaneous here either, but it doesn't take
> > minutes - provided you've built the project before and didn't change a
> > lot of code.
>
> Just the one unit test.
>
> >
> > If I run such a test for the first time, possibly after having
> > switched branches, I'll get test results in ~20 seconds; most of this
>
> What versions of tools in your tool chain are you using?

# Gradle
Using the gradle wrapper, so the same as what we have in each branch
of Hibernate ORM.
I don't think Gradle's version matters, we just recently used version
4, then 5, now 6 and they all perform well.

# JDK
Shouldn't matter either as I have many versions installed, and from
different vendors, to run various tests. Never noticed one being
particularly slow.

# OS
I run Fedora Linux exclusively, as most members of the team. Some of
us are on OSX, some use different Linux distributions.

> > is spent recompiling. But if I repeat the same command right away, it
> > will complete in ~1 second.
> >
> > What do you see if you repeat the test a second time after having just run 
> > it?
>
> After multiple builds it stabilized at 90 seconds.

Very odd. Having some old style spinning drives? AFAIK we all use fast
solid state drives for development.

Thanks,
Sanne

>
> >
> > Just for reference, a full build runnig all tests on H2 takes 6
> > minutes on my machine.
> >
> > Thanks,
> > Sanne
> >
> >
> >
> > On Wed, 22 Apr 2020 at 21:59, Jason Pyeron  wrote:
> > >
> > > I got it down to BUILD SUCCESSFUL in 2m 32s
> > > 27 actionable tasks: 5 executed, 22 up-to-date
> > >
> > > By using
> > >
> > > ./gradlew :hibernate-core:test --tests
> > org.hibernate.test.annotations.cid.CompositeIdFkGeneratedValueIdentityTest
> > >
> > >
> > > Package___  Tests   DurationSuccess 
> > > rate
> > > org.hibernate.test.annotations.cid  1   0.586s__100%
> > >
> > > For an approximate 250x slow down compared to the test execution, sigh.
> > >
> > > > -Original Message-
> > > > From: hibernate-dev-boun...@lists.jboss.org 
> > > >  On
> > Behalf Of Jason
> > > > Pyeron
> > > > Sent: Wednesday, April 22, 2020 4:48 PM
> > > > To: 'Hibernate Dev' 
> > > > Subject: [hibernate-dev] run a single unit test do I really have to 
> > > > manually put -
> > x for every task
> > > > I do not want?
> > > >
> > > > Does anyone know how to get a single unit test to run without building 
> > > > a battleship
> > too? Tried in
> > > > eclipse too.
> > > >
> > > > ./gradlew test --tests
> > org.hibernate.test.annotations.cid.CompositeIdFkGeneratedValueIdentityTest
> > > >
> > > > ... 5 minutes later ...
> > > >
> > > > FAILURE: Build failed with an exception.
> > > >
> > > > * What went wrong:
> > > > Execution failed for task ':documentation:test'.
> > > > > No tests found for given includes:
> > > > [org.hibernate.test.annotations.cid.CompositeIdFkGeneratedValueIdentityTest](--tests
> > filter)
> > > >
> > > > * Try:
> > > > Run with --stacktrace option to get the stack trace. Run with --info or 
> > > > --debug option
> > to get more log
> > > > output. Run with --scan to get full insights.
> > > >
> > > > * Get more help at https://help.gradle.org
> > > >
> > > > Deprecated Gradle features were used in this build, making it 
> > > > incompatible with Gradle
> > 5.0.
> > > > Use '--warning-mode all' to show the individual deprecation warnings.
> > > > See
> > https://docs.gradle.org/4.10.3/userguide/command_line_interface.html#sec:command_line_warn
> > ings
> > > >
> > > > BUILD FAILED in 4m 38s
> > > > 36 actionable tasks: 35 executed, 1 up-to-date
> > > >
> > > > --
> > > > Jason Pyeron  | Architect
> > > > PD Inc|
> > > > 10 w 24th St  |
> > > > Baltimore, MD |
> > > >
> > > > .mil: jason.j.pyeron@mail.mil
> > > > .com: jpye...@pdinc.us
> > > > tel : 202-741-9397
> > > >
> > > >
> > > >
> > > >
> > > > ___
> > > > hibernate-dev mailing list
> > > > hibernate-dev@lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > >
> > > ___
> > > hibernate-dev mailing list
> > > hibernate-dev@lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > >
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] run a single unit test speed up?

[Sanne Grinovero]

Hi Jason,

I'm surprised. It's not instantaneous here either, but it doesn't take
minutes - provided you've built the project before and didn't change a
lot of code.

If I run such a test for the first time, possibly after having
switched branches, I'll get test results in ~20 seconds; most of this
is spent recompiling. But if I repeat the same command right away, it
will complete in ~1 second.

What do you see if you repeat the test a second time after having just run it?

Just for reference, a full build runnig all tests on H2 takes 6
minutes on my machine.

Thanks,
Sanne



On Wed, 22 Apr 2020 at 21:59, Jason Pyeron  wrote:
>
> I got it down to BUILD SUCCESSFUL in 2m 32s
> 27 actionable tasks: 5 executed, 22 up-to-date
>
> By using
>
> ./gradlew :hibernate-core:test --tests 
> org.hibernate.test.annotations.cid.CompositeIdFkGeneratedValueIdentityTest
>
>
> Package___  Tests   DurationSuccess rate
> org.hibernate.test.annotations.cid  1   0.586s__100%
>
> For an approximate 250x slow down compared to the test execution, sigh.
>
> > -Original Message-
> > From: hibernate-dev-boun...@lists.jboss.org 
> >  On Behalf Of Jason
> > Pyeron
> > Sent: Wednesday, April 22, 2020 4:48 PM
> > To: 'Hibernate Dev' 
> > Subject: [hibernate-dev] run a single unit test do I really have to 
> > manually put -x for every task
> > I do not want?
> >
> > Does anyone know how to get a single unit test to run without building a 
> > battleship too? Tried in
> > eclipse too.
> >
> > ./gradlew test --tests 
> > org.hibernate.test.annotations.cid.CompositeIdFkGeneratedValueIdentityTest
> >
> > ... 5 minutes later ...
> >
> > FAILURE: Build failed with an exception.
> >
> > * What went wrong:
> > Execution failed for task ':documentation:test'.
> > > No tests found for given includes:
> > [org.hibernate.test.annotations.cid.CompositeIdFkGeneratedValueIdentityTest](--tests
> >  filter)
> >
> > * Try:
> > Run with --stacktrace option to get the stack trace. Run with --info or 
> > --debug option to get more log
> > output. Run with --scan to get full insights.
> >
> > * Get more help at https://help.gradle.org
> >
> > Deprecated Gradle features were used in this build, making it incompatible 
> > with Gradle 5.0.
> > Use '--warning-mode all' to show the individual deprecation warnings.
> > See 
> > https://docs.gradle.org/4.10.3/userguide/command_line_interface.html#sec:command_line_warnings
> >
> > BUILD FAILED in 4m 38s
> > 36 actionable tasks: 35 executed, 1 up-to-date
> >
> > --
> > Jason Pyeron  | Architect
> > PD Inc|
> > 10 w 24th St  |
> > Baltimore, MD |
> >
> > .mil: jason.j.pyeron@mail.mil
> > .com: jpye...@pdinc.us
> > tel : 202-741-9397
> >
> >
> >
> >
> > ___
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Migration to Jakarta API: some practical aspects in dealing with Git and mass replacements

[Sanne Grinovero]

Hi all,

the migration to the Jakarta API is rather simple and can be performed
by "find and replace" operations, but it will affect a lot of code and
might get int the way of other work.

To keep things simple and avoid tedious, massive conflict resolutions
for all of us who are having "work in progress" somewhere in branches,
open pull requests, and local work in progress which didn't make it to
pull requests yet, I would suggest to not blindly merge/rebase changes
from master, but take a little special care while this process is
ongoing.

For example, I just pushed the update to Hibernate Validator 7
[HHH-13950], which is done
via the following two commits:

 1 - 
https://github.com/hibernate/hibernate-orm/commit/b9a24f458c6e9c5331b2362f58eb36e5c244de5e

 2 - 
https://github.com/hibernate/hibernate-orm/commit/60abc8aa76492992047d1d6b08b95df3846a

Please note I'm using the commit description space to make notes about
how to port these commits.

I hope this helps; on top of single scripts for the individual
commits, when I'm done I'll also share a "one shot" script which could
be useful to process patches, so to have them apply cleanly for all
the unmerged work in progress we might have around.

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

Re: [hibernate-dev] HHH-13916 / WFLY-13259

[Sanne Grinovero]

On Thu, 16 Apr 2020 at 01:06, Gail Badner  wrote:
>
> Hi Galder,
>
> Thanks for the response. I agree this would be a good change for H6. I'm 
> happy to hear that this is on someone's radar for Infinispan.
>
> Sanne, regarding:
> > I'd say if you clearly mark the old method deprecated (or even remove it?) 
> > it
> will be guaranteed we don't forget about this improvement.
>
> Are you suggesting that SharedSessionContractImplementor#getSessionIdentifier 
> be deprecated?
> If so, it has other uses, so it really can't be deprecated.

Right, sorry let me clarify that. What I'm getting at is that clearly
the current method is being used in different contexts; I see at leat
two main ones:
 - requiring a Serializable identifier (across the wire for
clustering, and to be stored in databases) - typically an UUID.
 - some form of "identity token" as we discussed on Zulip, which is
far cheaper to generate but unsuitable for serialization.

When we get to such realizations, I generally think it's a good idea
to create more suitably named versions for *both* such use cases so to
avoid the overloaded notion we currently have.
Then, as second step deprecate (or remove) the original method.

Since we're discussing a major release, I'd remove the existing
method, or if you prefer the more conservative approach create JIRA
for it to be removed just before Final if that's more convenient -
for example keeping it a little longer could facilitate testing of the
previews without already needing the custom 2LC release but
I suspect it's not really worth it to be overzealous.

Thanks,
Sanne


>
> I've moved the fix version for HHH-13916 to 6.0.0.Beta1 and created a wip/6.0 
> PR: https://github.com/hibernate/hibernate-orm/pull/3341 .
>
> Regards,
> Gail
>
>
> On Wed, Apr 15, 2020 at 7:58 AM Galder Zamarreno  wrote:
>>
>> Given that there's a workaround for the issue, I'd agree with Sanne to make 
>> this an ORM 6+ only improvement.
>>
>> Indeed I'm no longer in the team and hence could not be the maintainer for 
>> such a module, but I'd be happy to discuss improvements for ORM6 caching. 
>> I've not been aware of any discussions on that yet.
>>
>> On the Infinispan side, just a couple of weeks back Tristan was asking me 
>> about the need for a remote Infinispan cache provider for ORM. Maybe ORM6 
>> offers a good opportunity to rework the provider and make it easy to 
>> maintain a local/remote provider.
>>
>> Galder
>>
>>
>> On Wed, Apr 15, 2020 at 1:42 PM Sanne Grinovero  wrote:
>>>
>>> On Wed, 15 Apr 2020 at 02:16, Gail Badner  wrote:
>>> >
>>> > FWIW, there's no point in fixing HHH-13916 unless we hear that Infinispan 
>>> > is going to use the fix.
>>>
>>> I suppose we can expect that that will eventually happen - I just
>>> don't know when and were to best make a note of such a need? I'd say
>>> if you clearly mark the old method deprecated (or even remove it?) it
>>> will be guaranteed we don't forget about this improvement.
>>>
>>> As far as I know, there isn't an Infinispan 2LC codebase for ORM6 yet,
>>> and there will be more differences likely?
>>>
>>> Also keep in mind that Galder no longer works on Infinispan, he's now
>>> focused on GraalVM and JDK engineering. I'm glad he's still around and
>>> we might be able to bother him for suggestions and wisdom, but I'm not
>>> sure yet who's going to be responsible to create such a new module.
>>> Radim is on the performance team; as always, would be awesome to have
>>> his help but I don't know of the performance team will be able to own
>>> the module maintenance.
>>>
>>> Thanks,
>>> Sanne
>>>
>>>
>>> >
>>> > Radim/Galder, WDYT?
>>> >
>>> > Thanks,
>>> > Gail
>>> >
>>> > On Tue, Apr 14, 2020 at 3:25 PM Gail Badner  wrote:
>>> >>
>>> >> Hi Sanne,
>>> >>
>>> >> I've reworked HHH-13916 to use this alternative, and set the fix version 
>>> >> to 6-wishlist.
>>> >>
>>> >> Regards,
>>> >> Gail
>>> >>
>>> >> On Tue, Apr 14, 2020 at 1:23 AM Sanne Grinovero  
>>> >> wrote:
>>> >>>
>>> >>> Hi Gail,
>>> >>>
>>> >>> I would go ahead with this improvement for ORM 6 and avoid spending
>>> >>> your precious time on a v5 improvement - especially if it's going to
>>> >>> require coordination with both the

Re: [hibernate-dev] Remove or disable the WildFly feature packs of Hibernate ORM?

[Sanne Grinovero]

Hi Fabio,

yes good point. Infinispan has been using our feature packs as well, but
they are in a similar situation and will have to change strategy.

Even if others will need them, we don't have much choice: the existing
feature packs won't work with the newer WildFly versions. So we'll keep
going with our plan to delete these, and then if there's compelling need
for a "Galleon XP" pack to be delivered in the future... we'll seen when
the demands materialize.

Regarding older WildFly versions which we still support: obviously we're
not backporting the removal to any supported branch so older Wildfly
versions (and older Infinispan versions) will be able to continue using
them.

Thanks
Sanne

On Fri, 17 Apr 2020 at 05:55, Fabio Massimo Ercoli 
wrote:

> Hello,
>
> I take advantage of the topic to say that there is an `integrationtests`
> module in Infinispan too using feature packs, which are usings in turn the
> feature packs of the Hibernate Search 5.
> I have to ask the ISPN guys on Zulip about that, maybe they have already
> planned to remove such modules and maybe we can get rid of them with the
> Search 6 integration.
>
> Thanks,
> Fabio
>
> On Fri, Apr 17, 2020 at 12:26 AM Sanne Grinovero 
> wrote:
>
>> We have a PR for this now, if someone would like to have a look:
>>  - https://github.com/hibernate/hibernate-orm/pull/3347
>>
>> One thing to note, is that it also removes all Arquillian based tests:
>> we had some which were testing more than just the basics of our
>> feature pack; although most had been disabled already for other
>> reasons.  Sadly even the few useful ones will need to be removed as
>> well.
>>
>> After this, we no longer have Arquillian among the test dependencies
>> either... back to basics.
>>
>> Thanks,
>> Sanne
>>
>> On Thu, 16 Apr 2020 at 16:18, Yoann Rodiere  wrote:
>> >
>> > > Any specific reason you say that Yoann?
>> >
>> > No, I was just thinking that moving to Jarakarta JPA and Jakarta CDI
>> had a high chance of breaking OSGi tests, unless the Jakarta artifacts
>> properly support OSGi.
>> >
>> > But it was just a hunch; if it works, I don't have anything against
>> keeping it.
>> >
>> >
>> > Yoann Rodière
>> > Hibernate Team
>> > yo...@hibernate.org
>> >
>> >
>> > On Thu, 16 Apr 2020 at 16:12, Steve Ebersole 
>> wrote:
>> >>
>> >> I do not plan on dropping hibernate-osgi.  Its there; it works.  Any
>> >> specific reason you say that Yoann?
>> >>
>> >> Brett is the only one to do anything with that "tutorial".  Though as
>> time
>> >> went on its focus was more a way to find problems when the paxexam
>> tests
>> >> failed - they almost always give useless feedback.  If you think
>> people are
>> >> using it as a tutorial then I agree we should remove it or update it.
>> >> Depending whether it still has benefit for troubleshooting I'd actually
>> >> just clarify its intent somehow rather removing it.  Brett?
>> >>
>> >>
>> >>
>> >> On Thu, Apr 16, 2020 at 8:42 AM Sanne Grinovero 
>> wrote:
>> >>
>> >> > Agreed, I'll remove it.  Thanks Steve and Yoann!
>> >> >
>> >> > I'll remove them from 5.5 soon, you can then merge the removal in 6.0
>> >> > or do it differently if that's easier.
>> >> >
>> >> > This is the JIRA:
>> >> >  - https://hibernate.atlassian.net/browse/HHH-13952
>> >> >
>> >> > Regarding OSGi (which Yoann raised): I agree we shouldn't spend
>> >> > significant amounts of time on it, but as long as tests still work
>> and
>> >> > it doesn't get in the way I'll leave them be.
>> >> > I have a related JIRA for OSGi as well: the tutorial is using very
>> old
>> >> > (unmaintained?) dependency versions, so it will either need to be
>> >> > removed (people can always read the older tutorial), or it should be
>> >> > updated (and tested).
>> >> > I might give it a shot to update it, but I'm afraid it will need a
>> >> > full set of Jakarta EE 9 dependencies available as well.
>> >> >  - https://hibernate.atlassian.net/browse/HHH-13951
>> >> >
>> >> > Yoann, great idea about the platform agnostic testrunner. We should
>> >> > keep that in mind, hopefully we'll be able to make it happen
>> >> > eventually.
>&

Re: [hibernate-dev] Remove or disable the WildFly feature packs of Hibernate ORM?

[Sanne Grinovero]

We have a PR for this now, if someone would like to have a look:
 - https://github.com/hibernate/hibernate-orm/pull/3347

One thing to note, is that it also removes all Arquillian based tests:
we had some which were testing more than just the basics of our
feature pack; although most had been disabled already for other
reasons.  Sadly even the few useful ones will need to be removed as
well.

After this, we no longer have Arquillian among the test dependencies
either... back to basics.

Thanks,
Sanne

On Thu, 16 Apr 2020 at 16:18, Yoann Rodiere  wrote:
>
> > Any specific reason you say that Yoann?
>
> No, I was just thinking that moving to Jarakarta JPA and Jakarta CDI had a 
> high chance of breaking OSGi tests, unless the Jakarta artifacts properly 
> support OSGi.
>
> But it was just a hunch; if it works, I don't have anything against keeping 
> it.
>
>
> Yoann Rodière
> Hibernate Team
> yo...@hibernate.org
>
>
> On Thu, 16 Apr 2020 at 16:12, Steve Ebersole  wrote:
>>
>> I do not plan on dropping hibernate-osgi.  Its there; it works.  Any
>> specific reason you say that Yoann?
>>
>> Brett is the only one to do anything with that "tutorial".  Though as time
>> went on its focus was more a way to find problems when the paxexam tests
>> failed - they almost always give useless feedback.  If you think people are
>> using it as a tutorial then I agree we should remove it or update it.
>> Depending whether it still has benefit for troubleshooting I'd actually
>> just clarify its intent somehow rather removing it.  Brett?
>>
>>
>>
>> On Thu, Apr 16, 2020 at 8:42 AM Sanne Grinovero  wrote:
>>
>> > Agreed, I'll remove it.  Thanks Steve and Yoann!
>> >
>> > I'll remove them from 5.5 soon, you can then merge the removal in 6.0
>> > or do it differently if that's easier.
>> >
>> > This is the JIRA:
>> >  - https://hibernate.atlassian.net/browse/HHH-13952
>> >
>> > Regarding OSGi (which Yoann raised): I agree we shouldn't spend
>> > significant amounts of time on it, but as long as tests still work and
>> > it doesn't get in the way I'll leave them be.
>> > I have a related JIRA for OSGi as well: the tutorial is using very old
>> > (unmaintained?) dependency versions, so it will either need to be
>> > removed (people can always read the older tutorial), or it should be
>> > updated (and tested).
>> > I might give it a shot to update it, but I'm afraid it will need a
>> > full set of Jakarta EE 9 dependencies available as well.
>> >  - https://hibernate.atlassian.net/browse/HHH-13951
>> >
>> > Yoann, great idea about the platform agnostic testrunner. We should
>> > keep that in mind, hopefully we'll be able to make it happen
>> > eventually.
>> >
>> > Thanks,
>> > Sanne
>> >
>> >
>> > On Thu, 16 Apr 2020 at 13:46, Steve Ebersole  wrote:
>> > >
>> > > Considering the changes in WildFly, I also think we should just drop
>> > hibernate-orm-modules.
>> > >
>> > > For 6.0 I will definitely do this.  I also think removing it is good for
>> > 5.5.
>> > >
>> > > Not sure it is even worth the hassle for earlier releases however.
>> > >
>> > >
>> > > On Wed, Apr 15, 2020 at 5:03 PM Sanne Grinovero 
>> > wrote:
>> > >>
>> > >> As we're working to upgrade to Jakarta EE 9, our feature packs for
>> > >> Wildfly are not going to be functional for a while at least.
>> > >>
>> > >> Not only do we have to upgrade to JPA 3, but we also need to upgrade
>> > >> our integrations with a different Validator, a different CDI - none of
>> > >> these are provided by WildFly yet.
>> > >>
>> > >> I see several options:
>> > >>  A] I could disable the feature pack generation and its integration
>> > tests.
>> > >>  B] Keep generating and releasing a knowingly broken feature pack,
>> > >> disable its integration tests, document this is work in progress.
>> > >>  C] Delete all this stuff
>> > >>
>> > >> Frankly it's tempting to just delete it all: WildFly has switched to a
>> > >> new model which replaces the "feature pack" notion we have, so even if
>> > >> Wildfly were to provide an Jakarta EE 9 build for us to run
>> > >> integration tests sometimes soon I'm sadly quite certain that we'll
>> > >> have to rethink

Re: [hibernate-dev] Hibernate Rx: Remove Optional from API

[Sanne Grinovero]

I would agree with you all about the general sentiment against the use
of Optional, but there's one use case in which I think it might make
sense (although bear with me as I've never really used it much yet) :

there's several methods on the standard Session and EntityManager in
Hibernate ORM to fetch a single entity: load/find/get/...

Even after all these years, I always have to open the Javadoc to
remember which ones are making assumptions about the entity existence
in the database (so could return a proxy even if the object doesn't
actually existin the DB), and which ones are going to check first in
the DB, possibly returning null.

Wouldn't Optional be great there to express the doubt vs the certainty
of it returning something?

Similarly in xToOne associations, having to remember to set the
"optional" attribute, or having business code having to match the
mapping is not ideal. That's perhaps unrelated, as this second point
is more about how users should express mappings rather than how we
expose APIs, but I mean it as an example to not necessarily go to the
extreme of ignoring that it might have some use in some selected
cases.

Thanks,
Sanne

On Thu, 16 Apr 2020 at 11:44, Davide D'Alto  wrote:
>
> Hi,
> Gavin sent this PR: https://github.com/hibernate/hibernate-rx/pull/93
>
> It removes Optional from the API, for example:
>
>  CompletionStage> fetch(T association);
>
> becomes:
>
>  CompletionStage fetch(T association);
>
> Is there anybody here with strong opinions about keeping Optional in the
> API?
>
> Thanks,
> Davide
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Remove or disable the WildFly feature packs of Hibernate ORM?

[Sanne Grinovero]

Agreed, I'll remove it.  Thanks Steve and Yoann!

I'll remove them from 5.5 soon, you can then merge the removal in 6.0
or do it differently if that's easier.

This is the JIRA:
 - https://hibernate.atlassian.net/browse/HHH-13952

Regarding OSGi (which Yoann raised): I agree we shouldn't spend
significant amounts of time on it, but as long as tests still work and
it doesn't get in the way I'll leave them be.
I have a related JIRA for OSGi as well: the tutorial is using very old
(unmaintained?) dependency versions, so it will either need to be
removed (people can always read the older tutorial), or it should be
updated (and tested).
I might give it a shot to update it, but I'm afraid it will need a
full set of Jakarta EE 9 dependencies available as well.
 - https://hibernate.atlassian.net/browse/HHH-13951

Yoann, great idea about the platform agnostic testrunner. We should
keep that in mind, hopefully we'll be able to make it happen
eventually.

Thanks,
Sanne


On Thu, 16 Apr 2020 at 13:46, Steve Ebersole  wrote:
>
> Considering the changes in WildFly, I also think we should just drop 
> hibernate-orm-modules.
>
> For 6.0 I will definitely do this.  I also think removing it is good for 5.5.
>
> Not sure it is even worth the hassle for earlier releases however.
>
>
> On Wed, Apr 15, 2020 at 5:03 PM Sanne Grinovero  wrote:
>>
>> As we're working to upgrade to Jakarta EE 9, our feature packs for
>> Wildfly are not going to be functional for a while at least.
>>
>> Not only do we have to upgrade to JPA 3, but we also need to upgrade
>> our integrations with a different Validator, a different CDI - none of
>> these are provided by WildFly yet.
>>
>> I see several options:
>>  A] I could disable the feature pack generation and its integration tests.
>>  B] Keep generating and releasing a knowingly broken feature pack,
>> disable its integration tests, document this is work in progress.
>>  C] Delete all this stuff
>>
>> Frankly it's tempting to just delete it all: WildFly has switched to a
>> new model which replaces the "feature pack" notion we have, so even if
>> Wildfly were to provide an Jakarta EE 9 build for us to run
>> integration tests sometimes soon I'm sadly quite certain that we'll
>> have to rethink how these packs are generated, and if it's still worth
>> for us doing this.
>>
>> Any thoughts?
>>
>> Thanks,
>> Sanne
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Remove or disable the WildFly feature packs of Hibernate ORM?

[Sanne Grinovero]

As we're working to upgrade to Jakarta EE 9, our feature packs for
Wildfly are not going to be functional for a while at least.

Not only do we have to upgrade to JPA 3, but we also need to upgrade
our integrations with a different Validator, a different CDI - none of
these are provided by WildFly yet.

I see several options:
 A] I could disable the feature pack generation and its integration tests.
 B] Keep generating and releasing a knowingly broken feature pack,
disable its integration tests, document this is work in progress.
 C] Delete all this stuff

Frankly it's tempting to just delete it all: WildFly has switched to a
new model which replaces the "feature pack" notion we have, so even if
Wildfly were to provide an Jakarta EE 9 build for us to run
integration tests sometimes soon I'm sadly quite certain that we'll
have to rethink how these packs are generated, and if it's still worth
for us doing this.

Any thoughts?

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

Re: [hibernate-dev] HHH-13916 / WFLY-13259

[Sanne Grinovero]

On Wed, 15 Apr 2020 at 02:16, Gail Badner  wrote:
>
> FWIW, there's no point in fixing HHH-13916 unless we hear that Infinispan is 
> going to use the fix.

I suppose we can expect that that will eventually happen - I just
don't know when and were to best make a note of such a need? I'd say
if you clearly mark the old method deprecated (or even remove it?) it
will be guaranteed we don't forget about this improvement.

As far as I know, there isn't an Infinispan 2LC codebase for ORM6 yet,
and there will be more differences likely?

Also keep in mind that Galder no longer works on Infinispan, he's now
focused on GraalVM and JDK engineering. I'm glad he's still around and
we might be able to bother him for suggestions and wisdom, but I'm not
sure yet who's going to be responsible to create such a new module.
Radim is on the performance team; as always, would be awesome to have
his help but I don't know of the performance team will be able to own
the module maintenance.

Thanks,
Sanne


>
> Radim/Galder, WDYT?
>
> Thanks,
> Gail
>
> On Tue, Apr 14, 2020 at 3:25 PM Gail Badner  wrote:
>>
>> Hi Sanne,
>>
>> I've reworked HHH-13916 to use this alternative, and set the fix version to 
>> 6-wishlist.
>>
>> Regards,
>> Gail
>>
>> On Tue, Apr 14, 2020 at 1:23 AM Sanne Grinovero  wrote:
>>>
>>> Hi Gail,
>>>
>>> I would go ahead with this improvement for ORM 6 and avoid spending
>>> your precious time on a v5 improvement - especially if it's going to
>>> require coordination with both the Infinispan and WildFly teams.
>>>
>>> Thanks
>>>
>>> On Fri, 10 Apr 2020 at 00:56, Gail Badner  wrote:
>>> >
>>> > I've been looking into how to fix this issue:
>>> >
>>> > https://hibernate.atlassian.net/browse/HHH-13916
>>> > https://issues.redhat.com/browse/WFLY-13259
>>> >
>>> > The crux of the matter is when Hibernate calls 
>>> > CacheHelper.fromSharedCache(
>>> > session, cacheKey, cachAccess ), and the entity is not found in the cache,
>>> > Infinispan stores a PendingPut containing a
>>> > SharedSessionContractImplementor instance.
>>> >
>>> > IIUC, as an optimization, Infinispan assumes that the entity not found in
>>> > the cache will ultimately be added to the cache after it is loaded from 
>>> > the
>>> > database. If that doesn't happen, the PendingPut will expire and will
>>> > eventually be removed. Until it expires,
>>> > the SharedSessionContractImplementor instance cannot be garbage-collected.
>>> >
>>> > This is particularly a problem if the cache is not disabled while a large
>>> > amount of cacheable data is being imported. This is the particular use 
>>> > case
>>> > described by WFLY-13259. There is a reproducer attached that
>>> > throws OutOfMemoryError.
>>> >
>>> > The obvious workaround is to set org.hibernate.CacheMode.IGNORE (or
>>> > possibly CacheMode.PUT?) while importing data.
>>> >
>>> > I discussed this briefly with Sanne, and we agree that an improvement 
>>> > would
>>> > be to not store a SharedSessionContractImplementor in a PendingPut at all.
>>> >
>>> > There is already a way to get a UUID for the session by calling
>>> > SharedSessionContractImplementor#getSessionIdentifier(). Unfortunately, 
>>> > the
>>> > implementation in AbstractSharedSessionContract indicates that frequent
>>> > "UUID generations will cause a significant amount of contention".
>>> >
>>> > Sanne has suggested returning a "token" that is just a new Object. I've
>>> > created a branch
>>> > <https://github.com/gbadner/hibernate-core/tree/HHH-13916_token> [1] that
>>> > does this.
>>> >
>>> > Infinispan would need to be updated so that PendingPut#owner is set
>>> > to SharedSessionContractImplementor#getSessionToken() (instead of
>>> > the SharedSessionContractImplementor object).
>>> >
>>> > Looking at the Infinispan code, I see that code that would be affected is
>>> > in
>>> > org.infinispan.hibernate.cache.commons.access.PutFromLoadValidator, which
>>> > is used by infinispan-hibernate-cache-v51.
>>> >
>>> > IIUC, in order to fix this any time soon for WildFly or EAP 7.x, [1] would
>>> > have to be backported to both Hibernate ORM 5.1 and 5.3 branches, and the
>>&g

[hibernate-dev] Branching 5.4, master is now 5.5

[Sanne Grinovero]

Hi all,

I've branched the current master, which was updated now to build
version 5.5.0-SNAPSHOT.

In parallel, we've created a 5.4 branch.

Please merge any new enhancements and bugfixes in master first; then
we can take backports in consideration as usual.

But also: we'd expect most enhancements to rather target the quickly
evolving branch for ORM 6: wip/6.0 - the main purpose for the 5.5
branch is to deliver some of the simpler enhancements, such as JPA 3,
but the focus for most new cool things is definitely the ORM 6 branch.

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

Re: [hibernate-dev] HHH-13916 / WFLY-13259

[Sanne Grinovero]

Hi Gail,

I would go ahead with this improvement for ORM 6 and avoid spending
your precious time on a v5 improvement - especially if it's going to
require coordination with both the Infinispan and WildFly teams.

Thanks

On Fri, 10 Apr 2020 at 00:56, Gail Badner  wrote:
>
> I've been looking into how to fix this issue:
>
> https://hibernate.atlassian.net/browse/HHH-13916
> https://issues.redhat.com/browse/WFLY-13259
>
> The crux of the matter is when Hibernate calls CacheHelper.fromSharedCache(
> session, cacheKey, cachAccess ), and the entity is not found in the cache,
> Infinispan stores a PendingPut containing a
> SharedSessionContractImplementor instance.
>
> IIUC, as an optimization, Infinispan assumes that the entity not found in
> the cache will ultimately be added to the cache after it is loaded from the
> database. If that doesn't happen, the PendingPut will expire and will
> eventually be removed. Until it expires,
> the SharedSessionContractImplementor instance cannot be garbage-collected.
>
> This is particularly a problem if the cache is not disabled while a large
> amount of cacheable data is being imported. This is the particular use case
> described by WFLY-13259. There is a reproducer attached that
> throws OutOfMemoryError.
>
> The obvious workaround is to set org.hibernate.CacheMode.IGNORE (or
> possibly CacheMode.PUT?) while importing data.
>
> I discussed this briefly with Sanne, and we agree that an improvement would
> be to not store a SharedSessionContractImplementor in a PendingPut at all.
>
> There is already a way to get a UUID for the session by calling
> SharedSessionContractImplementor#getSessionIdentifier(). Unfortunately, the
> implementation in AbstractSharedSessionContract indicates that frequent
> "UUID generations will cause a significant amount of contention".
>
> Sanne has suggested returning a "token" that is just a new Object. I've
> created a branch
>  [1] that
> does this.
>
> Infinispan would need to be updated so that PendingPut#owner is set
> to SharedSessionContractImplementor#getSessionToken() (instead of
> the SharedSessionContractImplementor object).
>
> Looking at the Infinispan code, I see that code that would be affected is
> in
> org.infinispan.hibernate.cache.commons.access.PutFromLoadValidator, which
> is used by infinispan-hibernate-cache-v51.
>
> IIUC, in order to fix this any time soon for WildFly or EAP 7.x, [1] would
> have to be backported to both Hibernate ORM 5.1 and 5.3 branches, and the
> Hibernate versions would have to be updated in Infinispan before Infinispan
> could be updated to use SharedSessionContractImplementor#getSessionToken().
>
> Galder/Radim, are there any plans for
> dropping infinispan-hibernate-cache-v51?
>
> Are there other places where the SharedSessionContractImplementor is stored
> in the cache?
>
> Aside from infinispan-hibernate-cache-v51, do you see anything about [1]
> that would cause problems?
>
> If not, when do you think we could coordinate this change? Do we need to
> wait for Hibernate ORM 6.0?
>
> This is considered an improvement, so it's not urgent. It would be nice to
> fix this though.
>
> Galder/Radim, please provide your input so we figure out when it can be
> fixed.
>
> Thanks,
> Gail
>
> [1] https://github.com/gbadner/hibernate-core/tree/HHH-13916_token
> [2]
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] please close HHH-13939

[Sanne Grinovero]

Hi Jason,

thanks for letting us know! Closed

-- Sanne

On Wed, 8 Apr 2020 at 01:39, Jason Pyeron  wrote:
>
> It was a failure of finding the documentation between 4.x and 5.x with 
> regards to @GeneratedValue(AUTO) behavior.
>
> Setting hibernate.id.new_generator_mappings=false fixed it.
>
> v/r,
>
> Jason
>
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Jakarta EE: JPA 3.0 is coming

[Sanne Grinovero]

Personally I'm now leaning to just adopt the "big bang" approach like
Hibernate Validator did, and other specs are doing, as Guillaume
passionately reminded me we have a lot on our plates - and beyond
doing this work we'd need many tricky integration tests.

However as usual we need to keep some open paths, so even though me
might not do any bytecode manipulation let me clarify what I meant by
answering to the questions from Steve:

On Wed, 11 Mar 2020 at 22:54, Steve Ebersole  wrote:
>
> When y'all talk about the bytecode enhancement solution, I'd like to better 
> understand what you mean exactly.
>
> Do you mean at run-time like we did for ORM when we combined 
> Session/EntityManager?  The problem there is that this only works when we 
> control the environment (WildFly e.g.).  Do you mean at build-time?

I meant build-time, and very limited. Since the new EntityManager API
and the old EntityManager API are exactly the same - except for the
package - it's actually trivial to have the SessionImpl to extend
*both* without needing any adaptors, with one single caveat: those
methods which return an enum, as the types will be defined by the spec
and we won't be able to override those.

But that's exactly the same problem we had when making the SessionImpl
implement both Session and EntityManager; if I remember correctly we
had this problem on a single method and this could be resolved by
using David's bridger tool (to which I linked as [1] in the first
email of this thread).

In terms of dependencies, the ORM core module would need to depend on
both JPA 2.2 and JPA 3.0 API jars.

> Generally I am not a fan of either of these approaches.

Ok, I'm not going to try any of these options for now.

>
> My preference is based on the previous discussions that we intend no more 5.x 
> release families (5.5, 5.6, etc).  Given that I'd prefer that we:
>
> Create a new 5.x family (5.5, 5.9, etc) that adds support for JPA 3 on top of 
> 5.3.  This would effectively "kill" 5.4.  This new 5.x release would be based 
> on the JPA 3 API (renamed packages) and be able to read JPA 3 annotations.  
> It would be nice if this version could read javax.persistence annotation as 
> well, but to me that is a nice-to-have.  None of us really has the time to 
> tackle that work at the moment.  And who know, maybe a contributor takes that 
> on.

Agreed, and yes my proposal was based on the conversations with you.

I still think it's tempting to see how easily we could read both
families of annotations but we all seem to agree that's just a "nice
to have" that's best deferred.  If someone wants to contribute it, it
might be a bit tricky: it's likely easy to do, but I'm not sure how
far an occasional contributor would be willing to go with integration
tests.

> Convert 6 to use JPA 3 API.  I'd prefer to not support "dual annotation 
> reading" here - based simply on resources.  This is a long term view - moving 
> forward I do not think it is reasonable expectation to use JPA 3 API with JPA 
> 2 annotations.  That might (debatable) make sense for a transitory period, 
> but I'd rather not "waste" the effort here for 6.

Agreed, I didn't mean to suggest we'd do anything different for 6.

Thanks,
Sanne

>
> For (1), in theory, I'd prefer to keep it using the JPA 2 API and read both.  
> However I suggested using the JPA 3 API there because I assume we are going 
> to need a JPA 3 compliant version sooner rather than later for TCKs.
>
> On Wed, Mar 11, 2020 at 3:51 AM Sanne Grinovero  wrote:
>>
>> On Wed, 11 Mar 2020 at 08:39, Yoann Rodiere  wrote:
>>
>> > > Yet I'm convinced that having a release
>> > > which provides full JPA 3.0 TCK between 5 and 6 (or however it gets
>> > > renamed) would be no good to us, as it would create an adoption
>> > > barrier for both cathegories of people: the ones not interested to
>> > > migrate away from JPA2, and the ones not interested to migrate beyond
>> > > JPA3.
>> >
>> > I get that, but I'm definitely not as hopeful as you are as to the
>> > reliability of those bytecode hacks you mentioned. But I guess that's an
>> > uphill battle.
>> >
>>
>> I'm not a fan of bytecode hacks either, so maybe let's just see what a POC
>> looks like before tearing it down?
>>
>> What's to stop you from supporting JPA2.0 in ORM 7, with the same hacks you
>> > mentioned for JPA3?
>> >
>>
>> Right, and in fact I mentioned as one of the possibilities for ORM6 to be
>> able to read and interpret the "legacy" annotations from JPA2.
>>
>> I believe that's important to not get in the way of adoption but rather
>> actively help with some flexibility, otherwise

Re: [hibernate-dev] Jakarta EE: JPA 3.0 is coming

[Sanne Grinovero]

On Wed, 11 Mar 2020 at 12:16, Yoann Rodiere  wrote:
>
> > Yet I'm convinced that having a release
> > which provides full JPA 3.0 TCK between 5 and 6 (or however it gets
> > renamed) would be no good to us, as it would create an adoption
> > barrier for both cathegories of people: the ones not interested to
> > migrate away from JPA2, and the ones not interested to migrate beyond
> > JPA3.
>
> I get that, but I'm definitely not as hopeful as you are as to the 
> reliability of those bytecode hacks you mentioned. But I guess that's an 
> uphill battle.

I hear you: I'll make sure to focus on reading the mapping
(annotations) can be done as an independent PR and POC; not planning
to use any bytecode hacks for that.

I believe the mapping is actually the most important aspect: we can
drop the others, or iterate on such aspects later if we feel like we
need more.

Regarding on ORM7, ORM8 ... I remember talking about such options with
Steve and I believe he was open to it but we both agreed it's a last
resort choice, so let's hope that won't be necessary.

Thanks,
Sanne


>
> What's to stop us from supporting JPA2.0 in ORM 7, with the same hacks you 
> mentioned for JPA3?
>
> People who want JPA3 only have a hack-free ORM 7 that happens to support JPA2 
> annotations.
> People who want JPA2 can migrate to ORM 7, and we'll provide hacks to make it 
> work.
>
> At least we wouldn't be penalizing people who want to migrate to JPA3 with 
> potentially unreliable bytecode hacks. Only people who want the latest and 
> greatest on an older API (which is, after all, quite an unreasonable request) 
> would have to put up with that.
> And we'll be clear about the fact that this is a major version, since we're 
> switching to different APIs by default and will ultimately remove the old 
> ones.
> And we'll be able to completely ignore these hacks in ORM 8 after we rebased 
> it on 7, since ORM 8 will drop support for JPA2 (I hope?).
>
> Yoann Rodière
> Hibernate Team
> yo...@hibernate.org
>
>
> On Wed, 11 Mar 2020 at 00:17, Guillaume Smet  wrote:
>>
>> On Tue, Mar 10, 2020 at 7:12 PM Sanne Grinovero  wrote:
>>
>> > The "big bang" approach that Validator implemented is an option as
>> > well; but the context is a bit different as we're having an actual
>> > major release being developed, and the matter of possible time
>> > pressure.
>> >
>>
>> Thus the proposal of Yoann and me to just rename the current 6 to a later
>> version and release a new major version that only contains the Jakarta
>> package change.
>>
>> That way, we don't end up doing additional work and having weird versions
>> partially supporting both.
>>
>> --
>> Guillaume
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>

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

Re: [hibernate-dev] Jakarta EE: JPA 3.0 is coming

[Sanne Grinovero]

On Wed, 11 Mar 2020 at 08:39, Yoann Rodiere  wrote:

> > Yet I'm convinced that having a release
> > which provides full JPA 3.0 TCK between 5 and 6 (or however it gets
> > renamed) would be no good to us, as it would create an adoption
> > barrier for both cathegories of people: the ones not interested to
> > migrate away from JPA2, and the ones not interested to migrate beyond
> > JPA3.
>
> I get that, but I'm definitely not as hopeful as you are as to the
> reliability of those bytecode hacks you mentioned. But I guess that's an
> uphill battle.
>

I'm not a fan of bytecode hacks either, so maybe let's just see what a POC
looks like before tearing it down?

What's to stop you from supporting JPA2.0 in ORM 7, with the same hacks you
> mentioned for JPA3?
>

Right, and in fact I mentioned as one of the possibilities for ORM6 to be
able to read and interpret the "legacy" annotations from JPA2.

I believe that's important to not get in the way of adoption but rather
actively help with some flexibility, otherwise people will have a very hard
time to upgrade to 6, and that's something that risks becoming a
significant burden on us all.

Thanks,
Sanne


>- People who want JPA3 only have a hack-free ORM 7 that happens to
>support JPA2 annotations.
>- People who want JPA2 can migrate to ORM 7, and we'll provide hacks
>to make it work.
>
> At least we wouldn't be penalizing people who want to migrate to JPA3 with
> potentially unreliable bytecode hacks. Only people who want the latest and
> greatest on an older API (which is, after all, quite an unreasonable
> request) would have to put up with that.
> And we'll be able to completely ignore these hacks in ORM 8 after we
> rebased it on 7, since ORM 8 will drop support for JPA2 (I hope?).
>
> Yoann Rodière
>
> Sr. Software Engineer, Middleware Engineering, Hibernate team
>
> Red Hat <https://www.redhat.com>
>
> <https://www.redhat.com>
>
>
> On Wed, 11 Mar 2020 at 00:17, Guillaume Smet 
> wrote:
>
>> On Tue, Mar 10, 2020 at 7:12 PM Sanne Grinovero 
>> wrote:
>>
>> > The "big bang" approach that Validator implemented is an option as
>> > well; but the context is a bit different as we're having an actual
>> > major release being developed, and the matter of possible time
>> > pressure.
>> >
>>
>> Thus the proposal of Yoann and me to just rename the current 6 to a later
>> version and release a new major version that only contains the Jakarta
>> package change.
>>
>> That way, we don't end up doing additional work and having weird versions
>> partially supporting both.
>>
>> --
>> Guillaume
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Jakarta EE: JPA 3.0 is coming

[Sanne Grinovero]

I didn't mean to suggest that we fully implement both JPA 3.x and JPA
2.y in any one version.

I'm really just focusing on those principles I mentioned; the main ones being:
 - don't spend ages on this effort
 - don't add pressure on ORM 6
 - not getting in the way of eventual ORM6 adoption

What happens next is definitely very open up for options, but bear in
mind that we might need to have some JPA3 implementation soon, so some
plan needs to be devised. As a broad idea, WildFly would like to have
it by September - that's not fully decided and they are asking us how
reasonable that could be.

In more formal terms, we have the spectrum of certifications:
 - [fact] Hibernate ORM 5.3 passes the JPA 2.2 TCK (as does ORM 5.4)
 - [goal] to have Hibernate ORM 6 (or 7?) to pass the JPA 3.0 TCK &
certification

To be fair what happens in the middle is more like a gray area. I
agree with Steve on wondering about how far we want stuff to be
simultaneously supported: in my opinion it would be totally fine if -
for example - Hibernate ORM 5.5 would materialize as a special edition
which is totally backwards compatible, able to pass the JPA 2.2 TCK,
and perhaps also able to load entities mapped via JPA 3 annotations
while not exposing anything else from Jakarta. As long as we don't aim
at JPA certification we can of course do whatever works for us, so
let's take this as an option.

A second step would be - assuming ORM6 branch incorporates such
changes - to also support both JPA 2.2 and JPA 3.0 annotations in the
ORM6 branch, but completely switch to the JPA 3.0 API and
configuration settings so to keep things simple.

The "big bang" approach that Validator implemented is an option as
well; but the context is a bit different as we're having an actual
major release being developed, and the matter of possible time
pressure.

We know from experience that people tend to linger on the older
versions for too long, so you need both a carrot and a stick to move
on. It would be good to be able to say to people that want JPA3 that
they need to upgrade to 6; and yet it also needs to be relatively easy
to upgrade - and that's where we have a problem: Jakarta haves you
"just search and replace all javax. strings" - but if we incidentally
also ask people to adapt to all changes from ORM5 to 6 - even if they
are small - it muddies the strategy significantly.
Conceptually I'm not sure if JPA3 is going to scare people off or
rather make people interested, as some might want to avoid it as there
is no immediate benefit, while others will need it: surely we'll have
many users in both camps. Yet I'm convinced that having a release
which provides full JPA 3.0 TCK between 5 and 6 (or however it gets
renamed) would be no good to us, as it would create an adoption
barrier for both cathegories of people: the ones not interested to
migrate away from JPA2, and the ones not interested to migrate beyond
JPA3.

Finally, consider the timeline. Both WildFly and Quarkus will need a
JPA 3 implementation soon: we either have it all ready or we need to
be able to deliver at least support for the mapping so that they can
do some bytecode magic to cover the other areas such as API; that's
why I see some merits in having some flexible intermediate support -
POC pending of course.

Thanks,
Sanne

On Tue, 10 Mar 2020 at 14:39, Steve Ebersole  wrote:
>
> I'm curious... why are we saying that we need to simultaneously support
> both sets of annotations and config settings?
>
> As a user, if I choose to use the Jakarta-based JPA I would fully expect
> that to only work with the Jakarta-based annotations and settings.
>
> Is there something in the spec I am missing that says we need to understand
> both simultaneously?
>
> On Tue, Mar 10, 2020 at 9:21 AM Guillaume Smet 
> wrote:
>
> > Hi,
> >
> > On Tue, Mar 10, 2020 at 2:48 PM Yoann Rodiere  wrote:
> >
> > > > In particular I wonder, how would you all feel if (for example)
> > > > Hibernate ORM 5.5.x were to depend on both JPA 2 and JPA 3 API
> > > > artifacts?
> > >
> > > Mixed feelings, to be honest
> >
> >
> > Same here. I thought we decided against supporting both at the same time.
> >
> > As for HV, I won't. HV 7 will only support jakarta packages all over the
> > place. And if you want jakarta packages, you will have to use HV 7. And
> > it's going to be a big bang, meaning you also need jakarta-package CDI and
> > so on.
> >
> > That is an important point for ORM too because that means you will have to
> > also support both legacy CDI and new jakarta CDI if you want to support
> > both at the same time. Pretty sure it's going to be a nightmare.
> >
> > Quick feedback on the HV move: it was relatively easy (but it's less
> > code/complex than ORM).
> >
> > >From my point of view, the options are:
> > 1/
> > - release an ORM 5.5 with Jakarta packages but it will break all existing
> > applications in a minor, not ideal
> > - move 6 to jakarta packages too to avoid conflicts
> >
> > 2/
> > - rename 6 to 7 

Re: [hibernate-dev] Jakarta EE: JPA 3.0 is coming

[Sanne Grinovero]

Hi Christian,

On Tue, 10 Mar 2020 at 11:33, Christian Beikov
 wrote:
>
> Hey,
>
> do you think it is feasible to create a separate artifact that is a
> bytecode rewriting of the main artifact, replacing javax.persistence by
> jakarta.persistence. This should be no big deal as e.g. the Maven Shade
> Plugin does that as well. We would only need to accept additonal
> poperties like e.g. jakarta.persistence.jdbc.user in addition to
> javax.persistence.jdbc.user.

yes that's an option, but beyond the configuration properties (and
thanks for reminding me of those!) I think the bulk of our work would
be in making sure we recognize both sets of annotations.

So for at least annotations and properties, changes would need to be
made to the core. Then to expose the different APIs we could have a
different, bytecode enhanced artifact, but it gets a bit tricky then
for other projects that integrate with it: will all project e.g.
Hibernate Search and Hibernate Validator need the same split, and will
this lead to an explosion of possible permutations?

>From my side I think that even if that's cool, it will be hard for
people to migrate if your libraries operate on an assumption of
"either or": if we could support both mapping styles while exposing
both APIs, the migration path becomes easier as people can do it in
smaller steps.

> That way, only minimal changes would be required and we'd have a
> separate artifact that can be consumed for Jakarta EE users. Maybe we
> could make Hibernate 6 JPA 3 only?

Yes I hope so. A consequence however would be that if we don't do a
5.x version which is able to allow people to use either JPA2 and 3, I
would be afraid that we'd be introducing a significant adoption
barrier for 6: we need to make sure it's easy for people to get there
before we drop JPA 2.

Thanks!
Sanne

>
> Regards,
>
> Christian
>
> Am 10.03.2020 um 12:17 schrieb Sanne Grinovero:
> > Hi all,
> >
> > as a consequence of having moved all Java EE technologies to the
> > Jakarta EE project at the Eclipse foundation, the API needs to change
> > so to address the Oracle trademark requirements.
> >
> > The new JPA project lives here:
> >   - https://github.com/eclipse-ee4j/jpa-api
> >
> > For context, to make it simpler for people to adopt the new API the
> > Jakarta EE team decided to not allow any other change to the API; this
> > would make it possible for people to migrate their existing code bases
> > by running a simple "search and replace all".  This implies that even
> > though it's a new major version, it's sadly not a good time to
> > challenge any API or spec working as this is intentionally frozen.
> >
> > And (our very own!) Scott Marlow helped with the primary change, which
> > you can see here having quite an impact:
> >   - https://github.com/eclipse-ee4j/jpa-api/pull/231
> >
> > It's just a small change of renaming all packages "javax.persistence"
> > to "jakarta.persistence" .. but it has wide impact all over.
> >
> > We should start thinking how to make support for JPA 3 happen in
> > Hibernate ORM; there's of course many options, but we need to take
> > into account some points:
> > to
> > 1)We can't spend years of brilliant minds on this
> > 2)We don't want to make the migration too hard to users
> > 3)We normally promise backwards compatibility within minor releases of
> > our projects
> > 4)While Hibernate ORM 6 is making great progress, it's a very large
> > quest to finish it. It's not wise to try to time-box it, while we
> > might need to deliver JPA 3 at some (TBD) reasonable deadline.
> > 5)Whatever we do, it shall not have a major burden on the team working
> > on ORM6 as that's our most important project.
> >
> > I hope we agree on these points?
> >
> > So I think I will spend some time exploring the fesability of a JPA
> > 3.0 in some 5.x branch, while aiming at maintaining backwards
> > compatibility.
> >
> > To address requirement 1# , I'll just explore this without making a
> > commitment to the plan.. also I think it would be interesting to
> > explore a partial migration, for example I suppose it might be
> > possible for us to "accept" the use of mapping annotations from JPA
> > 3.0 (on top of the ones from JPA 2.0) while not exposing the full
> > proper API yet.
> >
> > Considering the API is literally the same contract, if you except the
> > package name, it might be feasible to expose the full JPA 3.0 in a
> > backwards compatible way as well but this might require:
> >   - use of bridge methods, e.g. bytecode manipulation at build time [1]
> >   -

[hibernate-dev] Jakarta EE: JPA 3.0 is coming

[Sanne Grinovero]

Hi all,

as a consequence of having moved all Java EE technologies to the
Jakarta EE project at the Eclipse foundation, the API needs to change
so to address the Oracle trademark requirements.

The new JPA project lives here:
 - https://github.com/eclipse-ee4j/jpa-api

For context, to make it simpler for people to adopt the new API the
Jakarta EE team decided to not allow any other change to the API; this
would make it possible for people to migrate their existing code bases
by running a simple "search and replace all".  This implies that even
though it's a new major version, it's sadly not a good time to
challenge any API or spec working as this is intentionally frozen.

And (our very own!) Scott Marlow helped with the primary change, which
you can see here having quite an impact:
 - https://github.com/eclipse-ee4j/jpa-api/pull/231

It's just a small change of renaming all packages "javax.persistence"
to "jakarta.persistence" .. but it has wide impact all over.

We should start thinking how to make support for JPA 3 happen in
Hibernate ORM; there's of course many options, but we need to take
into account some points:

1)We can't spend years of brilliant minds on this
2)We don't want to make the migration too hard to users
3)We normally promise backwards compatibility within minor releases of
our projects
4)While Hibernate ORM 6 is making great progress, it's a very large
quest to finish it. It's not wise to try to time-box it, while we
might need to deliver JPA 3 at some (TBD) reasonable deadline.
5)Whatever we do, it shall not have a major burden on the team working
on ORM6 as that's our most important project.

I hope we agree on these points?

So I think I will spend some time exploring the fesability of a JPA
3.0 in some 5.x branch, while aiming at maintaining backwards
compatibility.

To address requirement 1# , I'll just explore this without making a
commitment to the plan.. also I think it would be interesting to
explore a partial migration, for example I suppose it might be
possible for us to "accept" the use of mapping annotations from JPA
3.0 (on top of the ones from JPA 2.0) while not exposing the full
proper API yet.

Considering the API is literally the same contract, if you except the
package name, it might be feasible to expose the full JPA 3.0 in a
backwards compatible way as well but this might require:
 - use of bridge methods, e.g. bytecode manipulation at build time [1]
 - depend on both JPA API packages

In particular I wonder, how would you all feel if (for example)
Hibernate ORM 5.5.x were to depend on both JPA 2 and JPA 3 API
artifacts?

And additional change to take into account is that the JPA3 API now
defines a module-info resource; it would be nice to try taking
advantage of that but it's of course more complicated if we have a
hybrid JPA 2/3 implementation. I guess that aspect will have to wait
for ORM6, but also that ORM6 being rebased on this work could benefit
from using the JPA3 groundwork.

Thanks,
Sanne

1 - https://github.com/dmlloyd/bridger
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Custom EventType and listeners

[Sanne Grinovero]

Hi Gail,

at high level it seems a reasonable idea to me.

In more detail, let's make sure the `registeredEventListeners`
initialization is not affected by data races, but we can defer
discussing such details on a PR as that would probably be clearer.

Thanks,
Sanne

On Thu, 5 Mar 2020 at 07:16, Gail Badner  wrote:
>
> There has been some discussion that it may be useful for hibernate-rx to be
> able to define RX-specific event types and listeners.
>
> I've created a POC [1] that adds this support. I still need to do some
> testing, but I would like some feedback before I spend too much time on
> this.
>
> Please let me know if this is a reasonable improvement. If it is, I will
> create an HHH jira and create a pull request.
>
> Thanks,
> Gail
>
> [1]
> https://github.com/gbadner/hibernate-core/commit/2d368a2ce1da36468ab7f965467711bc59f439cf
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Using Panache without Quarkus

[Sanne Grinovero]

Hi Gunnar,

a tricky aspect is that Panache requires transform and not limited to the
entities: all application code which is accessing those entities needs to
be enhaced as well.

Anything could be done of course, but that one is rather tricky to
accomplish without the well designed analysis and augmentation phases of
Quarkus, especially in a modular environment.

Cheers
Sanne

On Fri, 28 Feb 2020, 06:52 Gunnar Morling,  wrote:

> Hi,
>
> An interesting question came up during the Quarkus meet-up with Harald
> Pehl here in Hamburg last night: could Panache also be used without
> Quarkus, e.g. within a WildFly application?
>
> Any plans to enable that?
>
> Thanks,
>
> --Gunnar
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] DB2 support in Hibernate RX

[Sanne Grinovero]

Hi all,

Andy Guibert (IBM) is creating a reactive driver to access DB2, based
on the VertX APIs.

The new driver is not fully complete yet but I believe it might be in
good enough status to experiment with its integration in Hibernate RX.

An overview of its status can be found here:
 - https://github.com/orgs/eclipse-vertx/projects/1

Andy has been contributing on Quarkus as well: don't hesitate to reach
out to him for any need, as I hope he'll be able to help on RX too.

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

Re: [hibernate-dev] PSA: Maven users, upgrade to Maven 3.6.3 if you can

[Sanne Grinovero]

+1 for enforcing the latest version.

thanks Yoann and Fabio

-- Sanne

On Fri, 21 Feb 2020 at 11:24, Yoann Rodiere  wrote:
>
> Hello,
>
> Just to warn you there are bugs in Maven 3.6.1 and below impacting the
> resolution of transitive dependencies when your direct dependencies rely on
> exclusions or dependency management.
>
> In practice, I don't think it's very dangerous, as Maven has algorithms
> that resolve conflicting dependencies whenever they arise. Not great to
> rely on these, but they work most of the time.
>
> However, it's bound to cause some headaches, as I recently discovered
> thanks to Fabio: the maven-enforcer-plugin was (wrongly) detecting a
> dependency convergence issue with Maven 3.6.1 and below, just because the
> dependency management of one of our dependencies was being ignored.
>
> So there is no rush, but for your own good, I recommend that you upgrade
> your machine and CI jobs to Maven 3.6.3, and maybe even set the minimum
> required version of Maven to 3.6.2 (the first version that fixes the bug)
> in your POM.
>
> The CI already uses Maven 3.6.3 by default for all jobs configured with
> Maven 3.6. Jobs configured with Maven 3.5 or below will be affected by the
> bug.
>
> Cheers,
>
> Yoann Rodière
> Hibernate Team
> yo...@hibernate.org
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

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

Re: [hibernate-dev] api/doc suggestions

[Sanne Grinovero]

On Wed, 19 Feb 2020 at 23:42, Max Rydahl Andersen  wrote:
>
> Finally figure out my atlassian account so i could go with the hibernate
> issues ;)
>
> >> What is the equivalent way to do this in new metadata api:
> >>
> >> ```
> >> new Configuration().setProperty("hibernate.dialect",
> >> "org.hibernate.dialect.H2Dialect")
> >>  .setProperty("hibernate.connection.url",
> >> "jdbc:h2:./sakila")
> >>  .setProperty("hibernate.connection.username",
> >> "sa")
> >>  .buildSessionFactory();
> >> ```
> >>
> >> Just setup dialect, give connection info and get a
> >> sessionfactory/entitymanager ?
> >>
> >> I found apis to start from a file containing those settings; but I
> >> really just want a programmatic api
> >> to use in batch script etc. without a need for external files.
> >
> > Agreed we should explore making the "frameworkless bootstrap" simpler;
> > booting the ORM today requires some expertise, resulting in people to
> > rely on other frameworks to do the job.
>
> I think documentation could go a long way - I couldn't find anywhere
> in the docs the minimal step for configuring hibernate programmatically.
> All seem to assume you have external files for it.
>
> > However, the possible configuration options we have today are
> > significant; there's good reasons to have them so while an helper
> > would be welcome, I don't expect we'll want to change or simplify the
> > existing boot code, as it's working and doing a great job. This would
> > rather provide a simple, limited alternative.
> >
> > It will be necessary to clarify that the "simple" alternative is also
> > very limiting: for example I could see myself volunteering to create
> > such a little toy, but don't expect it to work in modular
> > environments, containers, pick up transaction managers, integrate with
> > DI frameworks, allow for Datasource injection, etc. etc.. Ok?
>
> well, maybe the existing Configuration api is that "toy" already ?
>
> > A consequence of such limitations would be that runtime performance
> > and efficiency would also be limited; let's be upfront about the
> > intent in the API documentation.
> >
> > I can try toy with a POC but can't promise a quick turnaround on this
> > one; not least I'd need Steve's blessing and review:
> >  - https://hibernate.atlassian.net/browse/HHH-13862
> >
> > Please comment on the JIRA or send a PR if you have a more concrete
> > idea or a draft.
>
> will do - but I don't have much to add for nowlooking forward to see
> what Steve thinks on this.

+1 me too.

I have sketched a POC for that; but had to put it aside for now, would
be good to know if it's worth me spending more time on it.

It's not hard but I wonder:
 - how to get a good balance of simple and limited but useful enough
for "simple things"
 - will we want such a thing to be part of ORM proper, and which package

Main problem is the definition of "simple things" is not very
specific. Secondarily, wouldn't want to have the more limited approach
look like the recommended approach.

Normally we face such issues iteratively: start with the basics, and
enhance according to demand; but in this case I'd prefer to make sure
it doesn't get out of hand: would rather set a precise goal upfront
and stick to it.

For example: my POC only exposes setting configuration elements via
`setProperty(String, String)`; that might be good enough for you but
it implies one can't even inject a Datasource instance - I'm inclined
to think people will have to accept such limitations, or be steered
towards using the existing more powerful bootstrap API.

Another aspect: Quarkus intentionally disables some steps of the ORM
bootstrap process, as it knows its own environment e.g. classloader
structure - this gives it a kick in terms of boot times and memory
use; It would be tempting to expose some form of "explicit
programmatic profiles" that could give similar benefits to all users.
For example a useful profile could be one for Java SE users having a
flat classloader and just needing to run some quick in-memory tests on
H2.

Thanks

>
> >> Here again, the ask is so we can educate and point people to use
> >> statelessSession rather than dropping Hibernate fully and from that
> >> api if needed go do `.doWork()` rather than refer to deprecated
> >> `.connection()`
> >
> > Makes sense, I believe we should be able to do this quickly:
> >  - https://hibernate.atlassian.net/browse/HHH-13861
> >
> > Andrea volunteered to have a look; assigned to him assuming it's
> > straight forward; if it gets tricky we'll have to wait for Steve's
> > opinion.
> >
>
> that one is now fixed and that’s awesome. one less deprecation I'm
> forced to use :)
>

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

Re: [hibernate-dev] Hibernate ORM : format of the version logged on boot

[Sanne Grinovero]

On Mon, 17 Feb 2020 at 14:20, Steve Ebersole  wrote:
>
> I tend to agree with Gail here.  Sure Sanne I understand your view there, but 
> realistically:
> 1) which other ORM jars do you see printing its version?

None, but I'm wondering if we wanted to improve on that.

> 2) when are you expecting that ORM jar versions can be mixed amongst the 
> different modules?

I don't expect that to be "supported", but people might do it, so
having such logs could theoretically help us to spot a misalignment.

I have no strong opinion about this, I just felt more inclined to go
for the more conservative change - especially as I had not heard your
opinion yet: If you prefer to polish this further I have no
objections.

Thanks!


>
> On Thu, Feb 13, 2020 at 10:42 AM Sanne Grinovero  wrote:
>>
>> Thanks all, I'll make the changes then:
>>  - https://hibernate.atlassian.net/browse/HHH-13863
>>
>> Gail, answered to you below - sorry it took so long.
>>
>> On Fri, 7 Feb 2020 at 18:24, Gail Badner  wrote:
>> >
>> > +1 to changing it.
>> >
>> > The name was changed from "core" to "ORM" some years back. Can "core" just 
>> > be dropped now?
>>
>> I'd prefer keeping the qualifier as it's referring to the
>> "hibernate-core" jar, in the sense it's one jar among the various jars
>> in Hibernate ORM as a whole.
>>
>> The reason is that there's tooling coming to help spotting misaligned
>> jars, so say hibernate-core and hibernate-ehcache need to be at the
>> same version, as they both belong to Hibernate ORM as whole.
>> Essentially, we still need a way to identify the parts as they are
>> packaged into different jars, so the qualifier is still useful in some
>> contexts.
>>
>> >
>> > On Fri, Feb 7, 2020 at 6:20 AM Yoann Rodiere  wrote:
>> >>
>> >> +1
>> >>
>> >>
>> >> Yoann Rodière
>> >> Hibernate Team
>> >> yo...@hibernate.org
>> >>
>> >>
>> >> On Fri, 7 Feb 2020 at 14:58, Sanne Grinovero  wrote:
>> >>
>> >> > It's minor cosmetics, but I'd like to change the format of the message
>> >> > we log on boot.
>> >> >
>> >> > Currently we have:
>> >> > INFO  [org.hib.Version] HHH000412: Hibernate Core {5.4.11-SNAPSHOT}
>> >> >
>> >> > I would like to change it into:
>> >> >INFO  [org.hib.Version] HHH000412: Hibernate ORM core version
>> >> > 5.4.11-SNAPSHOT
>> >> >
>> >> > in particular:
>> >> >  - to remove the "{}" wrapping around the number
>> >> >  - add "ORM"
>> >> >  - lowercase "core" and add "version"
>> >> >
>> >> > Looks good? It would be more consistent with our own project
>> >> > naming/branding, and with the format of similar messages being logged
>> >> > by other popular libraries.
>> >> >
>> >> > Thanks,
>> >> > Sanne
>> >> > ___
>> >> > hibernate-dev mailing list
>> >> > hibernate-dev@lists.jboss.org
>> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >> >
>> >> >
>> >> ___
>> >> hibernate-dev mailing list
>> >> hibernate-dev@lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev

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

[hibernate-dev] Release: Hibernate ORM 5.4.12.Final - now with GraalVM metadata!

[Sanne Grinovero]

This was an urgent bugfix release, but we managed to include some
enhancements as well!

Please check out the blog post:
https://in.relation.to/2020/02/14/hibernate-orm-5-4-12/

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

Re: [hibernate-dev] Hibernate ORM : format of the version logged on boot

[Sanne Grinovero]

Thanks all, I'll make the changes then:
 - https://hibernate.atlassian.net/browse/HHH-13863

Gail, answered to you below - sorry it took so long.

On Fri, 7 Feb 2020 at 18:24, Gail Badner  wrote:
>
> +1 to changing it.
>
> The name was changed from "core" to "ORM" some years back. Can "core" just be 
> dropped now?

I'd prefer keeping the qualifier as it's referring to the
"hibernate-core" jar, in the sense it's one jar among the various jars
in Hibernate ORM as a whole.

The reason is that there's tooling coming to help spotting misaligned
jars, so say hibernate-core and hibernate-ehcache need to be at the
same version, as they both belong to Hibernate ORM as whole.
Essentially, we still need a way to identify the parts as they are
packaged into different jars, so the qualifier is still useful in some
contexts.

>
> On Fri, Feb 7, 2020 at 6:20 AM Yoann Rodiere  wrote:
>>
>> +1
>>
>>
>> Yoann Rodière
>> Hibernate Team
>> yo...@hibernate.org
>>
>>
>> On Fri, 7 Feb 2020 at 14:58, Sanne Grinovero  wrote:
>>
>> > It's minor cosmetics, but I'd like to change the format of the message
>> > we log on boot.
>> >
>> > Currently we have:
>> > INFO  [org.hib.Version] HHH000412: Hibernate Core {5.4.11-SNAPSHOT}
>> >
>> > I would like to change it into:
>> >INFO  [org.hib.Version] HHH000412: Hibernate ORM core version
>> > 5.4.11-SNAPSHOT
>> >
>> > in particular:
>> >  - to remove the "{}" wrapping around the number
>> >  - add "ORM"
>> >  - lowercase "core" and add "version"
>> >
>> > Looks good? It would be more consistent with our own project
>> > naming/branding, and with the format of similar messages being logged
>> > by other popular libraries.
>> >
>> > Thanks,
>> > Sanne
>> > ___
>> > hibernate-dev mailing list
>> > hibernate-dev@lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >
>> >
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev

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

Re: [hibernate-dev] api/doc suggestions

[Sanne Grinovero]

Hi Max,

some thoughts inline:

On Sun, 9 Feb 2020 at 08:34, Max Rydahl Andersen  wrote:
>
> Heya,
>
> While working on Quarkus a few of us (Georgios in cc and I in
> particular) been pondering on doing a guide on best approaches on
> how to access data a bit more raw (i.e. raw sql, stateless season, etc.)
> as we got quite a lot of feedback stating Hibernate/JPA was considered
> complex in comparison to things like Spring Data and JDBC.
>
> When you go look its as if Spring Data and JDBC copied a lot of the
> patterns/access patterns we had in Hibernate before neither of those two
> existed :)
>
> Unfortunately, there are though a few gotchas I think would be great if
> we could somehow improve.
>
> Sanne suggested me to post to this list to start the conversation -
> there might come some more once I get going on writing the full guide;
> but wanted to get it started sooner rather than later.
>
> ### Document simplest programatic configuration
> (This might just be "max is stupid" issue - please tell me :)
>
> Trying to do a simple java main method booting Hibernate I could not
> figure out with the "new" metadata API a simple way to just start
> Hibernate.
>
> What is the equivalent way to do this in new metadata api:
>
> ```
> new Configuration().setProperty("hibernate.dialect",
> "org.hibernate.dialect.H2Dialect")
>  .setProperty("hibernate.connection.url",
> "jdbc:h2:./sakila")
>  .setProperty("hibernate.connection.username", "sa")
>  .buildSessionFactory();
> ```
>
> Just setup dialect, give connection info and get a
> sessionfactory/entitymanager ?
>
> I found apis to start from a file containing those settings; but I
> really just want a programmatic api
> to use in batch script etc. without a need for external files.

Agreed we should explore making the "frameworkless bootstrap" simpler;
booting the ORM today requires some expertise, resulting in people to
rely on other frameworks to do the job.

However, the possible configuration options we have today are
significant; there's good reasons to have them so while an helper
would be welcome, I don't expect we'll want to change or simplify the
existing boot code, as it's working and doing a great job. This would
rather provide a simple, limited alternative.

It will be necessary to clarify that the "simple" alternative is also
very limiting: for example I could see myself volunteering to create
such a little toy, but don't expect it to work in modular
environments, containers, pick up transaction managers, integrate with
DI frameworks, allow for Datasource injection, etc. etc.. Ok?

A consequence of such limitations would be that runtime performance
and efficiency would also be limited; let's be upfront about the
intent in the API documentation.

I can try toy with a POC but can't promise a quick turnaround on this
one; not least I'd need Steve's blessing and review:
 - https://hibernate.atlassian.net/browse/HHH-13862

Please comment on the JIRA or send a PR if you have a more concrete
idea or a draft.


> ### Non-documented Deprecation of `setResultTransformer()` and friends
>
> The [approach of using
> `setResultTransformer`](https://in.relation.to/2006/03/17/hibernate-32-transformers-for-hql-and-sql/)
> we've had "forever" and its exactly what spring data and jdbc are using
> in examples where they say data access are easier.
>
> We want to focus and use this kind of API in our Quarkus guides to
> educate this is available.
>
> Unfortunately in Hibernate 5.2+ that api got marked [as
> deprecated](https://github.com/hibernate/hibernate-orm/blob/7a51b12cbb9a33c4569e8fa8cac0e234c65bd9ba/hibernate-core/src/main/java/org/hibernate/query/Query.java#L1101)
> with no other documentation than a `@todo develop a new approach to
> result transformers`.
>
> The actual only proper reason I could find was mentioned in
> https://vladmihalcea.com/hibernate-resulttransformer/ where its pointed
> out that for now we couldn't do a related functional style api for this
> until Hibernate 6.
>
> The @deprecation makes all code using this in many ides get a strike
> through of that code, making people think it is bad to use when it is
> very much not the case.
>
> Any chance that deprecation can either be removed or at least documented
> to be less scary/more informative ?
> (I'll happily make a PR if can be pointed to the new better api?)

I'll leave this question to others: TBH I don't know the plan here.


> ### doWork missing on stateless session
>
> In similar vein `.connection()` on stateless session is marked as
> deprecated with [no alternative nor actual
> docs/info](https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/StatelessSession.java#L169).
>
> on Session the alternative is `doWork`. Any reason why that api isn't
> available on stateless session ?
>
> Here again, the ask is so we can educate and point people to use
> statelessSession rather than 

[hibernate-dev] Hibernate ORM : format of the version logged on boot

[Sanne Grinovero]

It's minor cosmetics, but I'd like to change the format of the message
we log on boot.

Currently we have:
INFO  [org.hib.Version] HHH000412: Hibernate Core {5.4.11-SNAPSHOT}

I would like to change it into:
   INFO  [org.hib.Version] HHH000412: Hibernate ORM core version 5.4.11-SNAPSHOT

in particular:
 - to remove the "{}" wrapping around the number
 - add "ORM"
 - lowercase "core" and add "version"

Looks good? It would be more consistent with our own project
naming/branding, and with the format of similar messages being logged
by other popular libraries.

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

[hibernate-dev] Google Spanner support for Hibernate ORM

[Sanne Grinovero]

Hi all,

Ray Tsang just wrote a nice blog on in.relation.to about the new
support for Google Spanner in Hibernate ORM:

 - https://in.relation.to/2019/12/18/google-cloud-spanner-dialect/

It's Ray's first blog on in.relation.to, you might have heard of him
as he presents frequently at events in his role as Developer Advocate
at Google Cloud Platform, and a Java Champion too.

Also if you don't mind, advertise it on twitter:
 - https://twitter.com/Hibernate/status/1207321287623954432

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

Re: [hibernate-dev] Cache key containing composite ID with a many-to-one

[Sanne Grinovero]

Hi Gail,

going for a disassembled ID would seem logical, but we'll need some
special care to deal with custom implementations of equals/hashcode.

Clearly a composite ID object would require the users to implement a
custom equals(); going for a solution based on a disassembled ID we
would need to either:

A# trust the equals implementation is "the obvious one"

B# hydrate both sides of the equals check for each time there's need
to invoke an equals (and same for hashcode)

I'm afraid only B would be backwards compatible and bullet-proof, and
yet its performance overhead would make it a terrible choice.

Perhaps the best solution is to constrain this, and warn that such a
model is not a good fit for caching?

Unless someone has a better idea; thinking out of the box: could be
interesting to explore not allowing users to implement custom equality
contracts as that's the root of many problems, but that would require
much more careful thought, and for sure a significant breaking change.

Or allow people to implement any custom equals, but ignore them and
apply "the obvious one" consistently.

Thanks,
Sanne



On Wed, 4 Dec 2019 at 19:40, Gail Badner  wrote:
>
> When an entity is cached with a composite ID containing a many-to-one
> association, the cache key will contain the many-to-one associated entity.
> If the associated entity is not enhanced, then it could be an uninitialized
> proxy.
>
> I've created a test case [1] that illustrates this using Infinispan. The
> test case is for 5.1 branch, since hibernate-infinispan is still included
> in that branch. The same would happen for master as well.
>
> Aside from the obvious issue with increased memory requirements to store an
> entity, there are other problems as well.
>
> What I've found so far is that caching a key with an uninitialized entity
> proxy can cause some big problems:
>
> 1) A lookup will never find this key unless the lookup is done with a cache
> key containing the same entity proxy instance.
>
> 2) Calling EntityManager#find with a composite ID containing a detached
> uninitialized entity proxy will result in a LazyInitializationException.
> This does not happen with second-level cache disabled.
>
> 3) Calling EntityManager#find with a composite ID containing a managed
> uninitialized entity proxy will result in the proxy being initialized. This
> does not happen with second-level cache disabled.
>
> I have not looked into what happens when the associated entity is enhanced
> and uninitialized (i.e., enhancement-as-proxy).
>
> IIUC, disassembling the ID that gets stored in the cache key would be far
> more efficient, and would avoid these issues. We would only want to do this
> when a composite ID contains an association. This would require changes in
> some SPIs though, to account for the disassembled ID type.
>
> I've been discussing necessary changes with Scott to cache a
> disassembled ID. Before we get too far down this road, I'd like to get some
> feedback.
>
> In the first place, should an entity instance be stored in a cache key?
>
> Is disassembling primary keys that contain an association the appropriate
> way to go? If so, I'll continue with a POC for doing this.
>
> Thanks,
> Gail
>
> [1]
> https://github.com/gbadner/hibernate-core/blob/753e36edf5137296d28b2a07cee3daffc16c6d1e/hibernate-infinispan/src/test/java/org/hibernate/test/cache/infinispan/CacheKeysWithEagerEntityFactoryTest.java
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev