On 19.05.2017 13:49, Sanne Grinovero wrote: > 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). Yeah :/ Aside from the ongoing discussion about getenv improvements for gradle on core-libs-dev, I hope that Mark's latest proposal will help remove some of the roadblocks in this area. Speaking of which - if you have a spare moment, I think this kind of feedback would be great to have directly on jigsaw-dev. As with many other JDK changes, the potential impact upon framework developers can best be understood by such developers themselves and should be brought back to JDK lists for discussions. In particular when default settings end up changing ;) cheers, dalibor topic > 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: >> Hi Sanne, >> >> *JDK 9 Early Access* build 170 is available at the new location : - >> jdk.java.net/9/ >> >> A summary of all the changes in this build are listed here >> <http://download.java.net/java/jdk9/changes/jdk-9+170.html>;. >> >> Changes which were introduced since the last availability email that >> may >> be of interest : >> >> * b168 - JDK-8175814: Update default HttpClient protocol version and >> optional request version >> o related to JEP 110 : HTTP/2 Client. >> * b169 - JDK-8178380 : Module system implementation refresh (5/2017) >> o changes in command line options >> * b170 - JDK-8177153 : LambdaMetafactory has default >> constructorIncompatible change, >> o release note: JDK-8180035 >> >> *New Proposal - Mark Reinhold has asked for comments on the jigsaw-dev >> mailing list *[1] >> >> * Proposal: Allow illegal reflective access by default in JDK 9 >> >> In short, the existing "big kill switch" of the >> `--permit-illegal-access` >> option [1] will become the default behavior of the JDK 9 >> run-time system, >> though without as many warnings. The current behavior of JDK 9, >> in which >> illegal reflective-access operations from code on the class path >> are not >> permitted, will become the default in a future release. Nothing >> will >> change at compile time. >> >> >> Rgds,Rory >> >> [1] >> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-May/012673.html >> >> -- >> Rgds,Rory O'Donnell >> Quality Engineering Manager >> Oracle EMEA , Dublin, Ireland >> >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev