From yoann at hibernate.org Fri Feb 1 03:05:54 2019 From: yoann at hibernate.org (Yoann Rodiere) Date: Fri, 1 Feb 2019 09:05:54 +0100 Subject: [hibernate-dev] Hibernate Search 6.0.0.Alpha2 and 5.11.1.Final released Message-ID: Hello, We just published Hibernate Search 6.0.0.Alpha2, the second development release of the 6.0 branch, and 5.11.1.Final, the first bugfix release of the 5.11 branch. For 5.11, the release mainly includes an upgrade to Hibernate ORM 5.4.1.Final. More information on the blog: http://in.relation.to/2019/02/01/hibernate-search-6-0-0-Alpha2-and-5-11-1-Final/ Cheers, Yoann Rodi?re Hibernate NoORM Team yoann at hibernate.org From f.petrulio at studenti.unisa.it Tue Feb 5 04:28:43 2019 From: f.petrulio at studenti.unisa.it (FERNANDO PETRULIO) Date: Tue, 5 Feb 2019 10:28:43 +0100 Subject: [hibernate-dev] Survey for Research on Lambda Expressions Message-ID: Dear Hibernate devs, I'm a researcher from UZH and my team and I are conducting a study on Lambda Expressions and Functional Interface in APIs.Hibernate project is one of our targets and we would gather some information and opinion about this topic from you. So I would be really happy if you filled the survey at the following link: https://www.surveygizmo.com/s3/4781913/704005e13cdb Kind Regards, Fernando Petrulio. From yoann at hibernate.org Wed Feb 6 07:18:06 2019 From: yoann at hibernate.org (Yoann Rodiere) Date: Wed, 6 Feb 2019 13:18:06 +0100 Subject: [hibernate-dev] Goodbye HipChat, hello Zulip! Message-ID: Hi, As you may already know, HipChat Cloud will cease to operate in about ten days. We need a replacement for our real-time chat, and we chose Zulip. An instance has been set up and configured. You can sign up and login with the link below; please do! https://hibernate.zulipchat.com/ Zulip takes an opinionated approach to chat, so you are encouraged to read this: https://hibernate.zulipchat.com/help/about-streams-and-topics Please keep in mind that Zulip will only subscribe you to the hibernate-user stream by default, so you need to subscribe explicitly to other streams you are interested in (hibernate-orm-dev, ...). If you need to test Zulip features, you can use the "sandbox" stream, which is there exactly for this purpose. If you have any questions, please let me know - on Zulip, of course. Or if you have trouble connecting, you can always send me an email. Please avoid HipChat or Gitter, though, for obvious reasons ;) Thanks, Yoann Rodi?re Hibernate NoORM Team yoann at hibernate.org From gbadner at redhat.com Wed Feb 6 18:45:13 2019 From: gbadner at redhat.com (Gail Badner) Date: Wed, 6 Feb 2019 15:45:13 -0800 Subject: [hibernate-dev] HHH-13076 Message-ID: I was looking into backporting HHH-13076 for 5.3.8. Looking at the fix [1], I see that starting a JDBC transaction that is already started will fail, even if hibernate.jpa.compliance.transaction=false. AFAICT, this didn't happen in 5.1. Was there a reason in particular why this was done? Thanks, Gail [1] https://github.com/hibernate/hibernate-orm/commit/a15dfe0e056c55664846b621c0d880ef2e367fff From andrea at hibernate.org Thu Feb 7 03:24:33 2019 From: andrea at hibernate.org (andrea boriero) Date: Thu, 7 Feb 2019 08:24:33 +0000 Subject: [hibernate-dev] HHH-13076 In-Reply-To: References: Message-ID: Hi Gail, the fix re-introduces the old behaviour (pre 5.0), the change in 5.0 and 5.1 was an oversight. On Wed, 6 Feb 2019 at 23:45, Gail Badner wrote: > I was looking into backporting HHH-13076 for 5.3.8. > > Looking at the fix [1], I see that starting a JDBC transaction that is > already started will fail, even > if hibernate.jpa.compliance.transaction=false. > > AFAICT, this didn't happen in 5.1. Was there a reason in particular why > this was done? > > Thanks, > Gail > > [1] > https://github.com/hibernate/hibernate-orm/commit/a15dfe0e056c55664846b621c0d880ef2e367fff > From guillaume.smet at gmail.com Tue Feb 12 11:38:53 2019 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Tue, 12 Feb 2019 17:38:53 +0100 Subject: [hibernate-dev] Hibernate NoORM IRC meeting minutes Message-ID: Hi, Here are the minutes of this week's NoORM IRC meeting. 15:23 < jbott> Meeting ended Tue Feb 12 14:23:33 2019 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 15:23 < jbott> Minutes: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2019/hibernate-dev.2019-02-12-14.00.html 15:23 < jbott> Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2019/hibernate-dev.2019-02-12-14.00.txt 15:23 < jbott> Log: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2019/hibernate-dev.2019-02-12-14.00.log.html Have a nice day. -- Guillaume From sanne at hibernate.org Tue Feb 12 15:36:38 2019 From: sanne at hibernate.org (Sanne Grinovero) Date: Tue, 12 Feb 2019 20:36:38 +0000 Subject: [hibernate-dev] Should we support out of date non-LTS Java versions? Message-ID: Hi all, I just tested if we still need the dependency to 'javax.activation:javax.activation-api:1.2.0' from Hibernate ORM / master, as I was suspecting the original reasons to add it might be out of date. I guessed almost right, as it turns out we don't need this dependency for Java 11, nor it was ever needed for Java 8 either: it was introduced to solve a specific Java 9 compatibility issue. I verified it's still needed for Java 9 compatibility. Personally that makes me think I'd rather remove the dependency, people should no longer use Java 9; Java 9 has been "out of support" since a while now: I expect people to either be on the latest stable release Java 11 - or on the previous stable release aka Java 8 (others might be toying with 12 and/or 13 but that's not relevant). Clearly since we have no more 5.x minor releases planned, I'm thinking of dropping a JVM version in a micro (!) - but considering this is an unsupported non-LTS JVM I'm not considering this to be an outrageous idea as we'd normally treat such a suggestion. Please don't take this as nitpicking about removing a single dependecy: that's easy enough for people to ignore and workaround by re-adding it explicitly; it's more important to focus on us creating a clear policy for the future. Can we establish how we'll treat support for any other future non-Long-Term-Support JVM version? Next time we might have a more tricky issue, and I think we should make our intentions and policy clear so to have freedom to drop support for experimental Java releases as we see fit, provided they are out of date. I couldn't test JDK 10 - but that doesn't matter as the details of this specific issue are irrelevant to the main point of agreeing on a general policy. Comments? Thanks, Sanne From yoann at hibernate.org Wed Feb 13 06:36:25 2019 From: yoann at hibernate.org (Yoann Rodiere) Date: Wed, 13 Feb 2019 12:36:25 +0100 Subject: [hibernate-dev] Should we support out of date non-LTS Java versions? In-Reply-To: References: Message-ID: Hi, I think we should make it clear that only LTS JVMs are actually supported, and non-LTS JVMs are only supported on a "best effort" basis, with some focus on the very latest non-LTS JVM. I doubt we have the appropriate resources to do anything more than that. To be more specific, I would see things this way: - We may remove compatibility with an LTS JVM in a major release. - We will always, systematically remove compatibility with older non-LTS JVMs in every major or minor release, except the very latest JVM (which might be a non-LTS): we don't even test them anymore, and we don't list them as compatible on our website. - We may remove compatibility with a non-LTS JVM in a micro release, but we try not to actively do it... Specifically in the case of your dependency removal in a micro: that doesn't seem very useful to users, and doesn't solve a bug, so I wouldn't do it. Also, changing dependencies in a micro doesn't feel quite right: I'd expect micros to be drop-in replacements, and I can imagine adding/removing dependencies to cause trouble in build tools/build configuration. But I wouldn't make it a hard rule, either: we may be forced to do it one day because of a bug, and such a small break is still better than a bug. Yoann Rodi?re Hibernate NoORM Team yoann at hibernate.org On Wed, 13 Feb 2019 at 03:47, Sanne Grinovero wrote: > Hi all, > > I just tested if we still need the dependency to > 'javax.activation:javax.activation-api:1.2.0' from Hibernate ORM / > master, as I was suspecting the original reasons to add it might be > out of date. > > I guessed almost right, as it turns out we don't need this dependency > for Java 11, nor it was ever needed for Java 8 either: it was > introduced to solve a specific Java 9 compatibility issue. > > I verified it's still needed for Java 9 compatibility. Personally that > makes me think I'd rather remove the dependency, people should no > longer use Java 9; > > Java 9 has been "out of support" since a while now: I expect people to > either be on the latest stable release Java 11 - or on the previous > stable release aka Java 8 (others might be toying with 12 and/or 13 > but that's not relevant). > > Clearly since we have no more 5.x minor releases planned, I'm thinking > of dropping a JVM version in a micro (!) - but considering this is an > unsupported non-LTS JVM I'm not considering this to be an outrageous > idea as we'd normally treat such a suggestion. > > Please don't take this as nitpicking about removing a single > dependecy: that's easy enough for people to ignore and workaround by > re-adding it explicitly; it's more important to focus on us creating a > clear policy for the future. > > Can we establish how we'll treat support for any other future > non-Long-Term-Support JVM version? > > Next time we might have a more tricky issue, and I think we should > make our intentions and policy clear so to have freedom to drop > support for experimental Java releases as we see fit, provided they > are out of date. > > I couldn't test JDK 10 - but that doesn't matter as the details of > this specific issue are irrelevant to the main point of agreeing on a > general policy. > > Comments? > > Thanks, > Sanne > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From steve at hibernate.org Wed Feb 13 08:28:37 2019 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 13 Feb 2019 07:28:37 -0600 Subject: [hibernate-dev] Should we support out of date non-LTS Java versions? In-Reply-To: References: Message-ID: +1 to everything Yoann said. On Wed, Feb 13, 2019, 5:42 AM Yoann Rodiere wrote: > Hi, > > I think we should make it clear that only LTS JVMs are actually supported, > and non-LTS JVMs are only supported on a "best effort" basis, with some > focus on the very latest non-LTS JVM. > I doubt we have the appropriate resources to do anything more than that. > > To be more specific, I would see things this way: > > - We may remove compatibility with an LTS JVM in a major release. > - We will always, systematically remove compatibility with older non-LTS > JVMs in every major or minor release, except the very latest JVM (which > might be a non-LTS): we don't even test them anymore, and we don't list > them as compatible on our website. > - We may remove compatibility with a non-LTS JVM in a micro release, but > we try not to actively do it... > > Specifically in the case of your dependency removal in a micro: that > doesn't seem very useful to users, and doesn't solve a bug, so I wouldn't > do it. Also, changing dependencies in a micro doesn't feel quite right: I'd > expect micros to be drop-in replacements, and I can imagine adding/removing > dependencies to cause trouble in build tools/build configuration. > But I wouldn't make it a hard rule, either: we may be forced to do it one > day because of a bug, and such a small break is still better than a bug. > > Yoann Rodi?re > Hibernate NoORM Team > yoann at hibernate.org > > > On Wed, 13 Feb 2019 at 03:47, Sanne Grinovero wrote: > > > Hi all, > > > > I just tested if we still need the dependency to > > 'javax.activation:javax.activation-api:1.2.0' from Hibernate ORM / > > master, as I was suspecting the original reasons to add it might be > > out of date. > > > > I guessed almost right, as it turns out we don't need this dependency > > for Java 11, nor it was ever needed for Java 8 either: it was > > introduced to solve a specific Java 9 compatibility issue. > > > > I verified it's still needed for Java 9 compatibility. Personally that > > makes me think I'd rather remove the dependency, people should no > > longer use Java 9; > > > > Java 9 has been "out of support" since a while now: I expect people to > > either be on the latest stable release Java 11 - or on the previous > > stable release aka Java 8 (others might be toying with 12 and/or 13 > > but that's not relevant). > > > > Clearly since we have no more 5.x minor releases planned, I'm thinking > > of dropping a JVM version in a micro (!) - but considering this is an > > unsupported non-LTS JVM I'm not considering this to be an outrageous > > idea as we'd normally treat such a suggestion. > > > > Please don't take this as nitpicking about removing a single > > dependecy: that's easy enough for people to ignore and workaround by > > re-adding it explicitly; it's more important to focus on us creating a > > clear policy for the future. > > > > Can we establish how we'll treat support for any other future > > non-Long-Term-Support JVM version? > > > > Next time we might have a more tricky issue, and I think we should > > make our intentions and policy clear so to have freedom to drop > > support for experimental Java releases as we see fit, provided they > > are out of date. > > > > I couldn't test JDK 10 - but that doesn't matter as the details of > > this specific issue are irrelevant to the main point of agreeing on a > > general policy. > > > > Comments? > > > > Thanks, > > Sanne > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From amits.84 at gmail.com Fri Feb 15 09:03:33 2019 From: amits.84 at gmail.com (Amit Shah) Date: Fri, 15 Feb 2019 19:33:33 +0530 Subject: [hibernate-dev] Upgrading Hibernate Causes null index column for collection error for List Message-ID: We are trying to upgrade hibernate from version 4.3.5 to 5.4.0. With this the jpa version also changes from hibernate-jpa-2.1 to jpa-2.2. After the upgrade we get the following error when using the List<> collection with @OrderColumn "javax.persistence.PersistenceException: org.hibernate.HibernateException: null index column for collection" It is a unidirectional one-to-mapping with following annotations @Entity at Table(name = "DS_GENERIC")@PrimaryKeyJoinColumn(name = "DSG_DS_ID")public class GenericConnection extends DataSourceConnection { @OneToMany(cascade = ALL, orphanRemoval = true, fetch = FetchType.EAGER) @JoinColumn(name = "DSC_DS_ID", nullable = false) @OrderColumn(name = "DSC_ORDER", updatable = false, insertable = false) List credentials = new ArrayList<>(); } @Entity at Table(name = "DS_CREDENTIALS")public class Credentials { @Id @GeneratedValue(generator = "uid-generator") @Column(name = "DSC_ID", updatable = false) private Long id; //...} The below test code fails //construct the connection object with credentials entityManager.persist(connection); entityManager.find(DataSourceConnection.class, id); //this call fails with the above error Note that this code worked fine with hibernate 4.3.5 and one workaround that also works is converting List to Set as below @OneToMany(cascade = ALL, orphanRemoval = true, fetch = FetchType.EAGER)@JoinColumn(name = "DSC_DS_ID", nullable = false)@OrderBy("DSC_ID")Set credentials = new HashSet<>(); I do not understand the root cause of this failure. Any inputs would be appreciated. Thanks. P.S - I have posted this query on stackoverflow too From rory.odonnell at oracle.com Mon Feb 18 06:37:10 2019 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Mon, 18 Feb 2019 11:37:10 +0000 Subject: [hibernate-dev] JDK 12: First Release Candidate available Message-ID: <787be10f-419f-3ca6-4460-bff5572efa42@oracle.com> Hi Sanne, **OpenJDK builds *- JDK 12 Early Access build 32 **is now available **at : - jdk.java.net/12/* **JDK 12:? First Release Candidate [1]** * Per the JDK 12 schedule [2], we are now in Release Candidate Phase. * The stabilization repository, jdk/jdk12, is open for P1 bug fixes per the JDK Release Process (JEP 3) [3]. * All changes require approval via the Fix-Request Process [4]. * Release note additions since last email o Build 31 - can_pop_frame and can_force_early_return capabilities are disabled if JVMCI compiler is used (JDK-8218025 ) The JVMTI |can_pop_frame| and |can_force_early_return| capabilities are disabled if a JVMCI compiler (like Graal) is used. As a result the corresponding functionality (|PopFrame| and |ForceEarlyReturnXXX| functions) is not available to JVMTI agents. This issue is being fixed via JDK-8218885 [https://bugs.openjdk.java.net/browse/JDK-8218885 ]. o Build 28: JDK-8212233 : javadoc fails on jdk12 with "The code being documented uses modules but the packages defined in $URL are in the unnamed module." * Changes in this build. **OpenJDK builds *- JDK 13 Early Access build 8 is **now available **at : - jdk.java.net/13/* * These early-access, open-source builds are provided under the o GNU General Public License, version?2, with the Classpath Exception . * Release Notes updates * Build 8 o GraphicsEnvironment.getCenterPoint()/getMaximumWindowBounds() are unified across the platforms (JDK-8214918 ) o The experimental FIPS 140 compliant mode has been removed from the SunJSSE provider. (JDK-8217835 ) * Build 7 o Change DOM parser to not resolve EntityReference and add Text node with DocumentBuilderFactory.setExpandEntityReferences(false) (JDK-8206132 ) * Build 6 o Base64.Encoder and Base64.Decoder methods can throw OutOfMemoryError (JDK-8210583 ) * Changes in this build * FOSS Bugs fixed in recent builds o Build 6 : JDK-8216970 : condy causes JVM crash o Build 7: JDK-8215577 : Remove javadoc support for HTML 4 Rgds,Rory [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2019-February/002623.html [2] http://openjdk.java.net/projects/jdk/12/#Schedule [3] http://openjdk.java.net/jeps/3 [4] http://openjdk.java.net/jeps/3#Fix-Request-Process -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland From sanne at hibernate.org Mon Feb 18 07:39:52 2019 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 18 Feb 2019 12:39:52 +0000 Subject: [hibernate-dev] JDK 12: First Release Candidate available In-Reply-To: <787be10f-419f-3ca6-4460-bff5572efa42@oracle.com> References: <787be10f-419f-3ca6-4460-bff5572efa42@oracle.com> Message-ID: Hi Rory, we've tested JDK 12 build 32 and it's working fine for Hibernate ORM; some more Hibernate projects are being tested soon - we'll let you know. While testing for this, we've hit an annoying build problem with Javadoc though; I've commented here: - https://bugs.openjdk.java.net/browse/JDK-8212233?focusedCommentId=14245762 Most notably this isn't a big deal for Java 12 as we just need to add a flag, but it's affecting Java 11 too. On the 11 version it's more annoying because the build parameters might need to change depending on specific micro versions, and it's tricky to handle that with our current crop of build tools, so I would rather see Java 11 revert to its original semantics - possibly downgrade this to a build warning? Not to mention that there's a flag in Java 12 to get it to work, while Java 11 doesn't have any known workaround - our solution is to keep building on the first release of Java 11, which was unaffected. I'd rather see this relaxed in the next micro though, as we can't otherwise cover those. Thanks, Sanne On Mon, 18 Feb 2019 at 12:33, Rory O'Donnell wrote: > > Hi Sanne, > > **OpenJDK builds *- JDK 12 Early Access build 32 **is now available **at > : - jdk.java.net/12/* > **JDK 12: First Release Candidate [1]** > > * Per the JDK 12 schedule [2], we are now in Release Candidate Phase. > * The stabilization repository, jdk/jdk12, is open for P1 bug fixes > per the JDK Release Process (JEP 3) [3]. > * All changes require approval via the Fix-Request Process [4]. > * > Release note additions since last email > > o > Build 31 - can_pop_frame and can_force_early_return capabilities > are disabled if JVMCI compiler is used (JDK-8218025 > ) The JVMTI > |can_pop_frame| and |can_force_early_return| capabilities are > disabled if a JVMCI compiler (like Graal) is used. As a result > the corresponding functionality (|PopFrame| and > |ForceEarlyReturnXXX| functions) is not available to JVMTI > agents. This issue is being fixed via JDK-8218885 > > [https://bugs.openjdk.java.net/browse/JDK-8218885 > ]. > > o Build 28: JDK-8212233 > : javadoc > fails on jdk12 with "The code being documented uses modules but > the packages defined in $URL are in the unnamed module." > * Changes in this build. > > > **OpenJDK builds *- JDK 13 Early Access build 8 is **now available **at > : - jdk.java.net/13/* > > * These early-access, open-source builds are provided under the > o GNU General Public License, version 2, with the Classpath > Exception . > * Release Notes updates > * Build 8 > o GraphicsEnvironment.getCenterPoint()/getMaximumWindowBounds() > are unified across the platforms (JDK-8214918 > ) > o The experimental FIPS 140 compliant mode has been removed from > the SunJSSE provider. (JDK-8217835 > ) > * Build 7 > o Change DOM parser to not resolve EntityReference and add Text > node with > DocumentBuilderFactory.setExpandEntityReferences(false) > (JDK-8206132 ) > * Build 6 > o Base64.Encoder and Base64.Decoder methods can throw > OutOfMemoryError (JDK-8210583 > ) > * Changes in this build > > * FOSS Bugs fixed in recent builds > o Build 6 : JDK-8216970 > : condy > causes JVM crash > o Build 7: JDK-8215577 > : Remove > javadoc support for HTML 4 > > > Rgds,Rory > > [1] > https://mail.openjdk.java.net/pipermail/jdk-dev/2019-February/002623.html > [2] http://openjdk.java.net/projects/jdk/12/#Schedule > [3] http://openjdk.java.net/jeps/3 > [4] http://openjdk.java.net/jeps/3#Fix-Request-Process > > -- > Rgds,Rory O'Donnell > Quality Engineering Manager > Oracle EMEA , Dublin, Ireland > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From rory.odonnell at oracle.com Mon Feb 18 07:43:26 2019 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Mon, 18 Feb 2019 12:43:26 +0000 Subject: [hibernate-dev] JDK 12: First Release Candidate available In-Reply-To: References: <787be10f-419f-3ca6-4460-bff5572efa42@oracle.com> Message-ID: Good to hear testing is going well. Also, thanks for updating the bug Sanne ! Rgds,Rory On 18/02/2019 12:39, Sanne Grinovero wrote: > Hi Rory, > > we've tested JDK 12 build 32 and it's working fine for Hibernate ORM; > some more Hibernate projects are being tested soon - we'll let you > know. > > While testing for this, we've hit an annoying build problem with > Javadoc though; I've commented here: > - https://bugs.openjdk.java.net/browse/JDK-8212233?focusedCommentId=14245762 > > Most notably this isn't a big deal for Java 12 as we just need to add > a flag, but it's affecting Java 11 too. On the 11 version it's more > annoying because the build parameters might need to change depending > on specific micro versions, and it's tricky to handle that with our > current crop of build tools, so I would rather see Java 11 revert to > its original semantics - possibly downgrade this to a build warning? > > Not to mention that there's a flag in Java 12 to get it to work, while > Java 11 doesn't have any known workaround - our solution is to keep > building on the first release of Java 11, which was unaffected. I'd > rather see this relaxed in the next micro though, as we can't > otherwise cover those. > > Thanks, > Sanne > > On Mon, 18 Feb 2019 at 12:33, Rory O'Donnell wrote: >> Hi Sanne, >> >> **OpenJDK builds *- JDK 12 Early Access build 32 **is now available **at >> : - jdk.java.net/12/* >> **JDK 12: First Release Candidate [1]** >> >> * Per the JDK 12 schedule [2], we are now in Release Candidate Phase. >> * The stabilization repository, jdk/jdk12, is open for P1 bug fixes >> per the JDK Release Process (JEP 3) [3]. >> * All changes require approval via the Fix-Request Process [4]. >> * >> Release note additions since last email >> >> o >> Build 31 - can_pop_frame and can_force_early_return capabilities >> are disabled if JVMCI compiler is used (JDK-8218025 >> ) The JVMTI >> |can_pop_frame| and |can_force_early_return| capabilities are >> disabled if a JVMCI compiler (like Graal) is used. As a result >> the corresponding functionality (|PopFrame| and >> |ForceEarlyReturnXXX| functions) is not available to JVMTI >> agents. This issue is being fixed via JDK-8218885 >> >> [https://bugs.openjdk.java.net/browse/JDK-8218885 >> ]. >> >> o Build 28: JDK-8212233 >> : javadoc >> fails on jdk12 with "The code being documented uses modules but >> the packages defined in $URL are in the unnamed module." >> * Changes in this build. >> >> >> **OpenJDK builds *- JDK 13 Early Access build 8 is **now available **at >> : - jdk.java.net/13/* >> >> * These early-access, open-source builds are provided under the >> o GNU General Public License, version 2, with the Classpath >> Exception . >> * Release Notes updates >> * Build 8 >> o GraphicsEnvironment.getCenterPoint()/getMaximumWindowBounds() >> are unified across the platforms (JDK-8214918 >> ) >> o The experimental FIPS 140 compliant mode has been removed from >> the SunJSSE provider. (JDK-8217835 >> ) >> * Build 7 >> o Change DOM parser to not resolve EntityReference and add Text >> node with >> DocumentBuilderFactory.setExpandEntityReferences(false) >> (JDK-8206132 ) >> * Build 6 >> o Base64.Encoder and Base64.Decoder methods can throw >> OutOfMemoryError (JDK-8210583 >> ) >> * Changes in this build >> >> * FOSS Bugs fixed in recent builds >> o Build 6 : JDK-8216970 >> : condy >> causes JVM crash >> o Build 7: JDK-8215577 >> : Remove >> javadoc support for HTML 4 >> >> >> Rgds,Rory >> >> [1] >> https://mail.openjdk.java.net/pipermail/jdk-dev/2019-February/002623.html >> [2] http://openjdk.java.net/projects/jdk/12/#Schedule >> [3] http://openjdk.java.net/jeps/3 >> [4] http://openjdk.java.net/jeps/3#Fix-Request-Process >> >> -- >> Rgds,Rory O'Donnell >> Quality Engineering Manager >> Oracle EMEA , Dublin, Ireland >> >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA, Dublin,Ireland From gbadner at redhat.com Mon Feb 18 19:19:33 2019 From: gbadner at redhat.com (Gail Badner) Date: Mon, 18 Feb 2019 16:19:33 -0800 Subject: [hibernate-dev] Upgrading Hibernate Causes null index column for collection error for List In-Reply-To: References: Message-ID: Hi Amit, This mailing list is for people working on Hibernate development. If you think you have found a bug, then please create a jira issue ( https://hibernate.atlassian.net/) and attach a test case that reproduces your issue. Regards, Gail On Fri, Feb 15, 2019 at 6:05 AM Amit Shah wrote: > We are trying to upgrade hibernate from version 4.3.5 to 5.4.0. With this > the jpa version also changes from hibernate-jpa-2.1 to jpa-2.2. After the > upgrade we get the following error when using the List<> collection with > @OrderColumn > > "javax.persistence.PersistenceException: org.hibernate.HibernateException: > null index column for collection" > > It is a unidirectional one-to-mapping with following annotations > > @Entity at Table(name = "DS_GENERIC")@PrimaryKeyJoinColumn(name = > "DSG_DS_ID")public class GenericConnection extends > DataSourceConnection { > > @OneToMany(cascade = ALL, orphanRemoval = true, fetch = > FetchType.EAGER) > @JoinColumn(name = "DSC_DS_ID", nullable = false) > @OrderColumn(name = "DSC_ORDER", updatable = false, insertable = false) > List credentials = new ArrayList<>(); > } > @Entity at Table(name = "DS_CREDENTIALS")public class Credentials { > > @Id > @GeneratedValue(generator = "uid-generator") > @Column(name = "DSC_ID", updatable = false) > private Long id; > > //...} > > The below test code fails > > //construct the connection object with credentials > entityManager.persist(connection); > entityManager.find(DataSourceConnection.class, id); //this call fails > with the above error > > Note that this code worked fine with hibernate 4.3.5 and one workaround > that also works is converting List to Set as below > > @OneToMany(cascade = ALL, orphanRemoval = true, fetch = > FetchType.EAGER)@JoinColumn(name = "DSC_DS_ID", nullable = > false)@OrderBy("DSC_ID")Set credentials = new > HashSet<>(); > > I do not understand the root cause of this failure. Any inputs would be > appreciated. > > Thanks. > > P.S - I have posted this query on stackoverflow too > < > https://stackoverflow.com/questions/54686603/upgrading-hibernate-causes-null-index-column-for-collection-error-for-list > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From sanne at hibernate.org Wed Feb 20 06:41:27 2019 From: sanne at hibernate.org (Sanne Grinovero) Date: Wed, 20 Feb 2019 11:41:27 +0000 Subject: [hibernate-dev] Should we support out of date non-LTS Java versions? In-Reply-To: References: Message-ID: Looks like we all agree on these guidelines, and since a week is passed I assume everyone else is fine too :) and thanks Yoann for updating the compatibility notes on the website! One first consequence is that the JDK9 and JDK10 jobs on CI are being abandoned; apparently they already aren't run regularly. We could eventually remove them, but I'll leave them for a while as they are still useful to diagnose some stuff occasionally. Sanne On Wed, 13 Feb 2019 at 15:13, Steve Ebersole wrote: > > +1 to everything Yoann said. > > > On Wed, Feb 13, 2019, 5:42 AM Yoann Rodiere wrote: > > > Hi, > > > > I think we should make it clear that only LTS JVMs are actually supported, > > and non-LTS JVMs are only supported on a "best effort" basis, with some > > focus on the very latest non-LTS JVM. > > I doubt we have the appropriate resources to do anything more than that. > > > > To be more specific, I would see things this way: > > > > - We may remove compatibility with an LTS JVM in a major release. > > - We will always, systematically remove compatibility with older non-LTS > > JVMs in every major or minor release, except the very latest JVM (which > > might be a non-LTS): we don't even test them anymore, and we don't list > > them as compatible on our website. > > - We may remove compatibility with a non-LTS JVM in a micro release, but > > we try not to actively do it... > > > > Specifically in the case of your dependency removal in a micro: that > > doesn't seem very useful to users, and doesn't solve a bug, so I wouldn't > > do it. Also, changing dependencies in a micro doesn't feel quite right: I'd > > expect micros to be drop-in replacements, and I can imagine adding/removing > > dependencies to cause trouble in build tools/build configuration. > > But I wouldn't make it a hard rule, either: we may be forced to do it one > > day because of a bug, and such a small break is still better than a bug. > > > > Yoann Rodi?re > > Hibernate NoORM Team > > yoann at hibernate.org > > > > > > On Wed, 13 Feb 2019 at 03:47, Sanne Grinovero wrote: > > > > > Hi all, > > > > > > I just tested if we still need the dependency to > > > 'javax.activation:javax.activation-api:1.2.0' from Hibernate ORM / > > > master, as I was suspecting the original reasons to add it might be > > > out of date. > > > > > > I guessed almost right, as it turns out we don't need this dependency > > > for Java 11, nor it was ever needed for Java 8 either: it was > > > introduced to solve a specific Java 9 compatibility issue. > > > > > > I verified it's still needed for Java 9 compatibility. Personally that > > > makes me think I'd rather remove the dependency, people should no > > > longer use Java 9; > > > > > > Java 9 has been "out of support" since a while now: I expect people to > > > either be on the latest stable release Java 11 - or on the previous > > > stable release aka Java 8 (others might be toying with 12 and/or 13 > > > but that's not relevant). > > > > > > Clearly since we have no more 5.x minor releases planned, I'm thinking > > > of dropping a JVM version in a micro (!) - but considering this is an > > > unsupported non-LTS JVM I'm not considering this to be an outrageous > > > idea as we'd normally treat such a suggestion. > > > > > > Please don't take this as nitpicking about removing a single > > > dependecy: that's easy enough for people to ignore and workaround by > > > re-adding it explicitly; it's more important to focus on us creating a > > > clear policy for the future. > > > > > > Can we establish how we'll treat support for any other future > > > non-Long-Term-Support JVM version? > > > > > > Next time we might have a more tricky issue, and I think we should > > > make our intentions and policy clear so to have freedom to drop > > > support for experimental Java releases as we see fit, provided they > > > are out of date. > > > > > > I couldn't test JDK 10 - but that doesn't matter as the details of > > > this specific issue are irrelevant to the main point of agreeing on a > > > general policy. > > > > > > Comments? > > > > > > Thanks, > > > Sanne > > > _______________________________________________ > > > hibernate-dev mailing list > > > hibernate-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev