Re: [hibernate-dev] JDK 9 EA Build 170 is available on jdk.java.net

Hi Rory, thanks, I'll update our ci.hibernate.org build servers today. Status reminder: we had good progress some months back, but since Gradle broke again we're stuck on our flagship project (Hibernate ORM). Some progress can be monitored here: - http://ci.hibernate.org/view/JDK9/ Please bear in mind that even the "green" projects had to disable integration tests with various platforms: our goal is to fix our own code but that doesn't mean that it's going to work in the thousands of frameworks integrating our projects. Mark Reinhold's latest proposal looks like a great step into the right direction. I can't speak for my colleagues: [I don't represent Red Hat Middleware !] but indeed - as an opinion from the Hibernate team - having some ways to mitigate the high time pressure is very well received. Whatever is decided regarding the default value of that flag, we'll certainly keep testing on the strictest setting, and keep stressing integrating frameworks and containers to do the same. Also as a personal opinion, not having the ability to isolate modules in terms of avoiding conflicting package names is going to make progress much harder: several of the projects we integrate with are extremely conservative in breaking APIs, so renaming packages for the sake of making the modules system happy is not going to happen in a long time. Also future evolution of our projects will likely be affected. In my experience I've witnessed several times that excellent libraries are "transferred ownership" across organisations and maintainers, sometimes partially, and when they get split they are typically not in a suitable time to rename all packages. Sure such things get cleaned up, but such events have to be decoupled - often for organisational, practical reasons. Successful OSS projects grow in size and complexity, but they don't necessarily scale in funding when they rely on volunteers, so an organic growth followed by splits is quite natural. The Java ecosystem supported this nicely; good tooling has been accelerating the process and allowing for larger projects but we're at a saturation point for which we're hoping modules would be an enabler for the community to avoid headaches with dependency alignment puzzles. With no isolation of at least the not-exported classes this seems like a missed opportunity. Thanks, Sanne On 19 May 2017 at 11:37, Rory O'Donnell <rory.odonnell(a)oracle.com&gt; wrote: