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

[Rory O'Donnell]

Hi Sanne,

I would second Dalibor's request to share your feedback!

Thanks,Rory


On 19/05/2017 13:06, dalibor topic wrote:
> 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 at oracle.com> 
>> 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 at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

-- 
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland