[hibernate-dev] Re: JDK 15 is now in the Initial Release Candidate Phase

[Rory O'Donnell]

Hi Yoann,

Thanks for the update!

Rgds,Rory

On 17/08/2020 12:34, Yoann Rodiere wrote:

Hi Rory,

I confirm that Hibernate ORM and Hibernate Search build and run fine 
on JDK15-ea+36.


Still no guarantee for JDK16, as Gradle is still unable to work 
properly with JDK16 [1].


[1] https://github.com/gradle/gradle/issues/13774 



Regards,


Yoann Rodière
Hibernate Team
yo...@hibernate.org 


On Fri, 7 Aug 2020 at 10:38, Rory O'Donnell > wrote:



Hi Sanne & Yoann,

*Per the JDK 15 schedule  , we are now in the Initial Release
Candidate
Phase
*


***Please advise if you have any open high priority issues.***

  * Schedule for JDK 15
      o *2020/08/06 Initial Release Candidate*
      o 2020/08/20 Final Release Candidate
      o 2020/09/15 General Availability

**

  * The overall feature set is frozen.
      o Per the JDK Release Process [1] we now turn our focus to
P1 bugs.
  * Features included in JDK 15:
      o JEP 339: Edwards-Curve Digital Signature Algorithm (EdDSA)
        
      o JEP 360: Sealed Classes (Preview)

      o JEP 371: Hidden Classes 
      o JEP 372: Remove the Nashorn JavaScript Engine
        
      o JEP 373: Reimplement the Legacy DatagramSocket API
        
      o JEP 374: Disable and Deprecate Biased Locking
        
      o JEP 375: Pattern Matching for instanceof (Second Preview)
        
      o JEP 377: ZGC: A Scalable Low-Latency Garbage Collector
        
      o JEP 378: Text Blocks 
      o JEP 379: Shenandoah: A Low-Pause-Time Garbage Collector
        
      o JEP 381: Remove the Solaris and SPARC Ports
        
      o JEP 383: Foreign-Memory Access API (Second Incubator)
        
      o JEP 384: Records (Second Preview)
        
      o JEP 385: Deprecate RMI Activation for Removal
        

*JDK 15 **Early Access build 35 *is now available at
http://jdk.java.net/15



  * Release notes
      o http://jdk.java.net/15/release-notes


  * Recent fixes that might be of interest
      o Build 34
          + JDK-8246094: [macos] Sound Recording and playback is
not working

*JDK 16 Early Access build 9 ***is now available at
http://jdk.java.net/16



  * JEP Candidate
      o JEP 388: Windows/AArch64 Port

  * JEPs targeted to JDK 16, so far:
      o JEP 369: Migrate to GitHub 
      o JEP 357: Migrate from Mercurial to Git
        
      o JEP 347: Enable C++14 Language Features
        

**

  * Recent fixes that might be of interest
      o

        Build 9

          + JDK-8243320: Add SSL root certificates to Oracle Root
CA program
          + JDK-8243321: Add Entrust root CA - G4 to Oracle Root
CA program
      o Build 8
          + JDK-8246094: [macos] Sound Recording and playback is
not working
          + JDK-8248655: Support supplementary characters in
String case
            insensitive operations
      o Build 7
          + JDK-8246032: Implementation of JEP 347: Enable C++14
            Language Features


*__*
Rgds,Rory

[1] http://openjdk.java.net/jeps/3

-- 
Rgds, Rory O'Donnell

Quality Engineering Manager
Oracle EMEA, Dublin, Ireland

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

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

[Yoann Rodiere]

 I can understand the argument "people who want to be on older versions of
Java can use older versions of Hibernate ORM/Search".
However, this strategy will only benefit the projects if we *actually* stop
working on much older versions... Experience taught me that's unlikely, and
it's even more unlikely if we don't release a stable 6.0 (ORM and Search)
very soon, but I guess we can try. So... okay.

The fact remains that major integrators of our libraries are still on Java
8, and will be for the foreseeable future:

   - Spring still supports Java 8, and I very much doubt they will drop
   such support anytime soon.
   - Quarkus still supports Java 8, but I understand you plan to remove
   that support soon (end of year, maybe?)
   - Wildfly is probably not a problem right now, due to the strict
   backward compatibility requirements that rule out an upgrade to 6.0 anyway.
   - Infinispan is only now starting to talk about moving their build to
   Java 11 [1] (no idea if they intend to remove runtime support for Java 8,
   since that's a separate issue). But they're only talking about the server
   part, and even if they solve that, there's still Infinispan Embedded.
   - I may be forgetting someone?

For Quarkus/Spring, well... I suppose it comes down to what we discussed
above about users. With what you're proposing, if a framework supports Java
8, they will not be able to upgrade at all. If we're talking about one
year, that's manageable. If we're talking about leaving a whole framework
worth of users on an older version of ORM/Search for ten years, that's
terrible. The reality will be somewhere in the middle, and *I* certainly
don't know where.

For Infinispan, it's very much a blocking problem, since they are already
on Hibernate Search 6 and can't really pick a different version of our
library depending on the version of the Java runtime. We should probably
solve that before we take any decision, at least for Search.

[1]
https://infinispan.zulipchat.com/#narrow/stream/118645-infinispan/topic/JDK.2011


Yoann Rodière
Hibernate Team
yo...@hibernate.org


On Wed, 5 Aug 2020 at 18:02, Sanne Grinovero  wrote:

> Sure, we can wait to drop Java 8 if you all feel strongly about it,
> but give my proposal a chance :)
>
> Let me address a couple random points:
>
> Java version 9 and 10 are not useful versions to support: only 8 and
> 11 have long term support, so 9 and 10 are already out of support. All
> surveys I've seen show that 9 and 10 have been largely ignored by
> production users and enterprise professionals: they either use 8 or
> 11, or occasionally people the very latest.
>
> So if there's any interest in taking advantage from any benefit which
> came in 9 onward (such as multi-release jars as mentioned by Steve),
> you might as well skip to 11.
>
> Specifically, multi-release jars have loads of tooling issues still,
> both for us and our end users (e.g. the IDE to show source code), and
> a big problem to support as people might end up using mismatched
> versions of the code.
>
> As I mentioned there are no extremely compelling reasons to jump to
> 11, but it does simplify some things, which - when used pervasively -
> simplify our own code and maintenance while introducing small runtime
> benefits as well, such as consuming slightly less memory with the
> improvements to collections and streams.
>
> Regarding users, I'm simply fine with letting people use our 5.x
> series for as long as they wish. You should all keep in mind that we
> have a very high number of users, and with a small team it's just not
> smart from our part to have them all try to jump on our latest: we
> risk getting drowned in feedback, it's better to be selective with our
> users and "pick" the ones which are more innovative. The ones still
> requiring Java 8 will eventually upgrade as well, I'm just not worried
> that we need to encourage them to upgrade right away.
>
> Last but not least, even if supporting Java 8 comes relatively easy
> for us, it's an additional burden and it's one we could avoid.
> Certainly easier to drop it than starting to waste our time on obscure
> issues caused by multi-release jars and such tools, or having to
> maintain compatibility including at dependency tree (xml-bind apis,
> and all those modules being different).
>
> It's an opportunity to simplify, I'd take it. For users, it's more
> important to set clear expectations and communicate this early.
>
> Thanks,
> Sanne
>
>
> On Fri, 24 Jul 2020 at 17:35, Steve Ebersole  wrote:
> >
> > I also think ORM 6 is not the time to do this.  Especially moving to Java
> > 11.
> >
> > I think it is worthwhile though to discuss possibly moving to Java 9 to
> > take advantage of multi-release jars as Christian mentioned.  But Java 9
> > has its own set of difficulties for adoption with modules.  It is a
> > tough call.
> >
> >
> > On Fri, Jul 24, 2020 at 10:09 AM Yoann Rodiere 
> wrote:
> >
> > > Hi,
> > >
> > > I share Christian's concerns; Hibernate Sea

[hibernate-dev] Regarding lazy initialization of ArrayList

[Nathan Xu]

This is my first message posted here after I finally succeeded in
subscribing to Hibernate dev mail list.

As well known, we utilized the following 'lazy initialization' pattern
extensively in our codebase to save memory:

if ( activeFactoryNames == null ) {
 activeFactoryNames = new ArrayList<>();
}

However, even since JDK7, ArrayList has gone through refactoring to
keep from allocating

memory for 10 elements in advance, if the instance was created by
default constructor and the allocation of memory

is only done when some element is really added in future. Namely,
ArrayList has the lazy initialization feature built-in.

E.g., see 
https://stackoverflow.com/questions/33688753/jdk-api-documentation-is-incorrect-for-arraylist-constructor-is-that-a-bug

for details. You can also browse the source code of ArrayList to confirm.

[image: Screen Shot 2020-08-18 at 4.06.58 PM.png]

Needless to say, the lazy initialization pattern has serious NPE issue
if it is not coded carefully (which is tedious and error-prone per
se).

As an active Hibernate v6 contributor, I am troubled by such NPE issue
again and again.

Is it a good timing to get rid of the above lazy initialization pattern for now?

Hopefully my message is good food for thought. No finger pointing. Just curious.
___
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

[Christian Beikov]

Hey Nathan,

I like the idea in general and but you have to be careful with changing 
this as I assume this was done to save memory by creating the list, only 
when at least one element would be added to the list. I guess if we 
always initialize the list, we'd have to do something like the following 
in the end `this.activeFactoryNames = activeFactoryNames.isEmpty() ? 
Collections.emptyList() : activeFactoryNames` which is probably not that 
bad, assuming we probably already do something similar.


I don't think anyone would object to such an improvement regarding NPE 
safety as long as the final memory consumption stays the same. It would 
be a pity though if we unnecessarily created lots of empty ArrayLists.


Am 18.08.2020 um 22:18 schrieb Nathan Xu:
This is my first message posted here after I finally succeeded in 
subscribing to Hibernate dev mail list.


As well known, we utilized the following 'lazy initialization' pattern 
extensively in our codebase to save memory:


if ( activeFactoryNames == null ) {
     activeFactoryNames = new ArrayList<>();
}
However, even since JDK7, ArrayList has gone through refactoring to 
keep from allocating
memory for 10 elements in advance, if the instance was created by 
default constructor and the allocation of memory
is only done when some element is really added in future. Namely, 
ArrayList has the lazy initialization feature built-in.
E.g., see 
https://stackoverflow.com/questions/33688753/jdk-api-documentation-is-incorrect-for-arraylist-constructor-is-that-a-bug 


for details. You can also browse the source code of ArrayList to confirm.
Screen Shot 2020-08-18 at 4.06.58 PM.png
Needless to say, the lazy initialization pattern has serious NPE issue 
if it is not coded carefully (which is tedious and error-prone per se).
As an active Hibernate v6 contributor, I am troubled by such NPE issue 
again and again.
Is it a good timing to get rid of the above lazy initialization 
pattern for now?
Hopefully my message is good food for thought. No finger pointing. 
Just curious.


___
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