JDK 15 is in Rampdown Phase One
by Rory O'Donnell
Hi Sanne,
*Per the JDK 15 schedule , we are in Rampdown Phase One* *[1] *
*Please advise if you find any issues while testing the latest Early
Access builds.
*
* Schedule for JDK 15
o *2020/06/11 Rampdown Phase One*
o 2020/07/16 Rampdown Phase Two
o 2020/08/06 Initial Release Candidate
o 2020/08/20 Final Release Candidate
o 2020/09/15 General Availability
* Features included in JDK 15:
o JEP 339: Edwards-Curve Digital Signature Algorithm (EdDSA)
<http://openjdk.java.net/jeps/339>
o JEP 360: Sealed Classes (Preview) <http://openjdk.java.net/jeps/360>
o JEP 371: Hidden Classes <http://openjdk.java.net/jeps/371>
o JEP 372: Remove the Nashorn JavaScript Engine
<http://openjdk.java.net/jeps/372>
o JEP 373: Reimplement the Legacy DatagramSocket API
<https://openjdk.java.net/jeps/373>
o JEP 374: Disable and Deprecate Biased Locking
<http://openjdk.java.net/jeps/374>
o JEP 375: Pattern Matching for instanceof (Second Preview)
<https://openjdk.java.net/jeps/375>
o JEP 377: ZGC: A Scalable Low-Latency Garbage Collector
<http://openjdk.java.net/jeps/377>
o JEP 378: Text Blocks <http://openjdk.java.net/jeps/378>
o JEP 379: Shenandoah: A Low-Pause-Time Garbage Collector
<https://openjdk.java.net/jeps/379>
o JEP 381: Remove the Solaris and SPARC Ports
<https://openjdk.java.net/jeps/381>
o JEP 383: Foreign-Memory Access API (Second Incubator)
<https://openjdk.java.net/jeps/383>
o JEP 384: Records (Second Preview)
<https://openjdk.java.net/jeps/384>
o JEP 385: Deprecate RMI Activation for Removal
<https://openjdk.java.net/jeps/385>
*JDK 15 **Early Access build 28 **is available**at : - jdk.java.net/15/*
These early-access, open-source builds are provided under the GNU
General Public License, version 2, with the Classpath Exception**Release
notes
* Release notes
o http://jdk.java.net/15/release-notes
* Recent fixes that might be of interest
o Build 27
+ JDK-8233215: jpackage doesn't allow enough flexibility for
file type binding
+ JDK-8244582: Remove terminally deprecated Solaris-specific
SO_FLOW_SLA socket option
+ JDK-8245068: Implement Deprecation of RMI Activation
+ JDK-8246770: Atomic::add() with 64 bit value fails to link
on 32-bit platforms
# Reported by JaCoCo
o Build 26
+ JDK-8240871: SSLEngine handshake status immediately after
the handshake can be NOT_HANDSHAKING rather than FINISHED
with TLSv1.3
# Reported by Apache Tomcat
o Build 25
+ JDK-8206925: Support the certificate_authorities extension
+ JDK-8239480: Support for CLDR version 37
+ JDK-8243925: Toolkit#getScreenInsets() returns wrong value
on HiDPI screens (Windows)
*JDK 16 Early Access build 2 ****is available**at : - jdk.java.net/16/*
These early-access, open-source builds are provided under the GNU
General Public License, version 2, with the Classpath Exception.*
*
*_Survey on _**_jinfo, jmap, jstack serviceability tools in JDK:_ *
* Oracle is considering deprecation and (eventual) removal of 3 JDK
tools - jinfo, jmap, jstack.
* The Survey Link
<https://www.questionpro.com/a/TakeSurvey?tt=n%2BDcx/aY3aA%3D> will
remain open through July 15 2020.
Rgds, Rory
[1] https://mail.openjdk.java.net/pipermail/jdk-dev/2020-June/004401.html
--
Rgds, Rory O'Donnell
Quality Engineering Manager
Oracle EMEA, Dublin, Ireland
4 years, 5 months
v6 and load-event
by Steve Ebersole
Historically we made a terrible design mistake with the event system as a
whole. This has both a confusing design impact and a very real performance
impact. The main problem is the smashing together of things that handle
events and things that listen to such events.
In working on a problem in v6 I have come to a point where fixing this
design flaw for load events specifically would be a huge help. So I'm
going to make a proposal for how to specifically change this for load event
handling. The plan at the moment is to not make similar changes to the
other event types for now, though I certainly would like to keep them all
in mind with regard to the overall design for if/when we can get to the
others.
So I'd love feedback specifically regarding (1) general design considering
other event types and (2) issues/concerns specific to load event type.
I created a simple example at
https://gist.github.com/sebersole/2a1c3ac010a166fc91e62b088179678d
Thanks!
4 years, 5 months
Re: [hibernate-dev] My email
by Sanne Grinovero
Sure that's not a problem.
However, 6.x has many open issues still - it might be best to track
things on JIRA as usual:
- https://hibernate.atlassian.net/secure/Dashboard.jspa
Either way is fine in principle, just normally we use the list to
discuss proposals; for example if you plan to contribute a fix and
have questions, or just want to let others know that you're looking at
it then the list is more suitable.
Thanks!
On Wed, 3 Jun 2020 at 11:26, Catalin Tudose <catalin.tudose(a)gmail.com> wrote:
>
> Great, thank you!
> There is a possible issue I discovered with 6.0.0.Alpha5.
> Would that be fine to share it on this list?
>
> On Wed, Jun 3, 2020 at 1:22 PM Sanne Grinovero <sanne(a)hibernate.org> wrote:
>>
>> Hi Catalin,
>>
>> looks like you managed to post to the list!
>>
>> welcome,
>> Sanne
>>
>> On Wed, 3 Jun 2020 at 11:15, Catalin Tudose <catalin.tudose(a)gmail.com> wrote:
>> >
>> > Hello!
>> >
>> > I would like to post to the hibernate-dev(a)lists.jboss.org mailing list!
>> > My e-mail is catalin.tudose(a)gmail.com
>> >
>> > Thank you!
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev(a)lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >
4 years, 5 months
My email
by Catalin Tudose
Hello!
I would like to post to the hibernate-dev(a)lists.jboss.org mailing list!
My e-mail is catalin.tudose(a)gmail.com
Thank you!
4 years, 5 months
Hibernate Reactive: Release day!
by Sanne Grinovero
Hi all,
we're about to test a first automated release.. Hibernate Reactive v. 0.0.1
I expect some of you might be annoyed that they had "one more cool
improvement" which didn't make it; don't be: the release process is
highly automated (thanks to Yoann!) and we will have many more
triggered in the following days as we polish the process.
Thanks,
Sanne
4 years, 5 months
