Toward the first Hibernate Reactive release
by Emmanuel Bernard
Hey everyone,
The work around Hibernate Reactive is coming along nicely. So has some
other work needed on the Vert.x front and Mutiny front. Now is time to
ship a first version to the community. With some of the people working
on it, I've tried to come up with a list of tasks and decisions to make.
And proposed decisions to avoid blockers.
## Communication
Most communication happens on the project Pull Request, a good thing I
think. But the glue between them was missing as far as communication.
I propose we use hibernate-dev@ for this.
## The project name
There is an open PR related to the name of the project
https://github.com/hibernate/hibernate-rx/issues/77
I exchanged with Gavin and Sanne and went back and forth on it.
My preferred name _was_ `Hibernate ORM Reactive` because of the fight we
did to make `Hibernate` != `Hibernate ORM` brand wise. But we have quite
failed to convert the general public :) As a brand, `Hibernate Reactive`
is strong and catchy. The only project besides ORM that could become
reactive is Search (I don't think validator has a strong case). We
likely should swallow our pride and call the project `Hibernate
Reactive`. If HSEARCH reactive comes up, we could use `Hibernate
Reactive Search`.
So unless someone is strongly against it, let's call it `Hibernate
Reactive` which would be our sub umbrella for our reactive work.
Frankly, the other names were too incorrect or suck for a brand. There
is also the strong possibility that we would want to deliver all
Hibernate Reactive subprojects as one to be able to combine them.
That means renaming the doc and the package, the GitHub repository and
the Quarkus Extension. This will only be done after Query support is
initially pushed not to disrupt things too much.
## Query support
I strongly think that we need Query support for the initial release. It
can be an initial Query support. But we need something. This is the one
technical subject that prevents us from releasing Hibernate Reactive
alpha. Davide is working on it and we will know more in a week or two
about the viability status.
As soon as there is shared code (working or not), Gavin offered to help.
## Mutiny
https://github.com/hibernate/hibernate-rx/issues/94
Mutiny will be a first class API for Hibernate Reactive. Gavin is
working on building it.
## One module to rule them all
Today we have an API module and an Impl module. But reality is we don't
know how we will split the project if any. This highly depend on the API
reaction and popularity.
With Mutiny coming in, the API module became a bit complicated.
Gavin proposed to merge everything in one module during the alpha / beta
stage of the project and reevaluate with user feedback. This will only
be done after Query support is initially pushed not to disrupt things
too much.
## Quarkus extension
https://github.com/quarkusio/quarkus/pull/9060
Andy did an awesome work into fleshing out the initial Quarkus
Extension. Even better, it works for native for the main path :)
The main annoyance is that to generate schema, you need a JDBC driver
setting and a JDBC driver in your classpath. We can improve on that but
that's not a trivial amount of work to adapt `SchemaExport` and friends.
## Documentation
Right now we have the readme as documentation. The proposed idea is as
followed:
- we convert the readme content (or get inspired from it) and generate a
Quarkus guide out of it. Their format are really similar.
- best would be to convert the [Quarkus Hibernate ORM
quickstart](https://github.com/quarkusio/quarkus-quickstarts/tree/develop...
to use Hibernate Reactive and base the guide on it.
- a more formal documentation and working for Hibernate Reactive
standalone (outside of Quarkus) can grow from these. See website
section.
## Blog
We need to work on a blog announcing the project.
## Website
We need to adapt hibernate.org to have a Hibernate Reactive project.
Once you make Awestruct work, it should be a relatively quick change to
add the relevant sections. There is likely quite some work on the
various messages and content of the key sections.
Once we have all or most of this, we can release and get user feedback
:)
When? To that, I'd quote a wise man from the future
**Lt. Commander Geordi La Forge:** Look, Mr. Scott, I'd love to explain
everything to you, but the Captain wants this spectrographic analysis
done by 1300 hours.
[La Forge goes back to work; Scotty follows slowly]
**Scotty:** Do you mind a little advice? Starfleet captains are like
children. They want everything right now and they want it their way. But
the secret is to give them only what they need, not what they want.
**Lt. Commander Geordi La Forge:** Yeah, well, I told the Captain I'd
have this analysis done in an hour.
**Scotty:** How long will it really take?
**Lt. Commander Geordi La Forge:** An hour!
**Scotty:** Oh, you didn't tell him how long it would really take, did
ya?
**Lt. Commander Geordi La Forge:** Well, of course I did.
**Scotty:** Oh, laddie. You've got a lot to learn if you want people to
think of you as a miracle worker.
Emmanuel
6 years
- 1
- 0
Jakarta EE 9 / JPA 3: reverting changes from master
by Sanne Grinovero
Hi all,
in previous emails I mentioned I suggested to release a JPA3
compatible version of Hibernate ORM out soon, as I expected this to be
the natural way forward, and soon to be needed by other projects such
as WildFly. I had started working on this myself.
However, the WildFly team hasn't decided if/when they will adopt the
new Jakarta EE APIs, and I've been advised by many that this upgrade
is unlikely to be in high demand:
it brings no new benefits at all, while it introduces quite some
annoying breaking changes.
We have a fairly complete prototype in the draft PR I've sent here:
- https://github.com/hibernate/hibernate-orm/pull/3373
And yet, I think I'll "put it in the freezer". Unfortunately I had
already merged some preparations work in 5.5, such as upgrading to
Validator 7.x: I will revert those changes, apologies for that mess
but I think it's for the best to postpone this for later.
When there will be more interest in this, it should not be too hard to
adapt the work as it's mostly strucutured in the form of replacement
scripts which should apply nicely w/o any conflict even on future
branches.
Thanks,
Sanne
6 years
- 1
- 0
OpenJDK 15 EA build 21 is now available
by Rory O'Donnell
Hi Sanne,
OpenJDK 15 EA build 21 is now available at http://jdk.java.net/15 *
*
* These early-access , open-source builds are provided under the
o GNU General Public License, version 2, with the Classpath
Exception <http://openjdk.java.net/legal/gplv2+ce.html>.
* Features
o Integrated in JDK 15
+ JEP 371: <http://openjdk.java.net/jeps/371> Hidden Classes
+ JEP 372 <https://openjdk.java.net/jeps/372>: Remove the
Nashorn JavaScript Engine
+ JEP 377 <https://openjdk.java.net/jeps/377>: ZGC: A Scalable
Low-Latency Garbage Collector
+ JEP 378 <https://openjdk.java.net/jeps/378>: Text Blocks
o JEPs targeted to JDK 15
+ JEP 379 <https://openjdk.java.net/jeps/379>: Shenandoah: A
Low-Pause-Time Garbage Collector
* Changes in recent builds that maybe of interest:
o build 21
+ JDK-8242848
<https://bugs.openjdk.java.net/browse/JDK-8242848>: Improve
performance of InflaterOutputStream.write()
+ JDK-8243574
<https://bugs.openjdk.java.net/browse/JDK-8243574>:
java.lang.invoke.InvokerBytecodeGenerator.ClassData should
be package-private
# Reported by JaCoCo
o build 20
+ JDK-8237890
<https://bugs.openjdk.java.net/browse/JDK-8237890>:
DatagramPacket::getSocketAddress doesn't specify what
happens if address or port are not set [1]
+ JDK-8228991
<https://bugs.openjdk.java.net/browse/JDK-8228991>: Obsolete
-XX:UseAdaptiveGCBoundary [1]
+ JDK-8242141
<https://bugs.openjdk.java.net/browse/JDK-8242141>: New
System Properties to configure the TLS signature schemes [1]
+ JDK-8172404
<https://bugs.openjdk.java.net/browse/JDK-8172404>: Tools
should warn if weak algorithms are used before restricting them
+ JDK-8238195
<https://bugs.openjdk.java.net/browse/JDK-8238195>:
Lookup::defineClass should link the class to match the
specification
+ JDK-8238358
<https://bugs.openjdk.java.net/browse/JDK-8238358>:
Implementation of JEP 371: Hidden Classes
+ JDK-8241749
<https://bugs.openjdk.java.net/browse/JDK-8241749>: Remove
the Nashorn JavaScript Engine
+ JDK-8242260
<https://bugs.openjdk.java.net/browse/JDK-8242260>: Add
forRemoval=true to already deprecated ContentSigner
+ JDK-
<https://bugs.openjdk.java.net/browse/JDK-8242008>8242008
<https://bugs.openjdk.java.net/browse/JDK-8242008>:
SSLSession inconsistencies
# Reported by Netty
o build 19
+ JDK-8239594
<https://bugs.openjdk.java.net/browse/JDK-8239594>: The
java.net.HttpClient does not override the protocols
specified in the SSLContext default parameters [1]
+ JDK-8172680
<https://bugs.openjdk.java.net/browse/JDK-8172680>: SunJCE
provider now supports SHA-3 based Hmac algorithms
+ JDK-8237474
<https://bugs.openjdk.java.net/browse/JDK-8237474>: Default
SSLEngine should create in server role
+ JDK-8240877
<https://bugs.openjdk.java.net/browse/JDK-8240877>: NPE at
javax.swing.text.html.FormView.appendBuffer with null option
values
# reported by JOSM
Project Loom Early-Access Builds - Build 15-loom+5-125 (2020/4/17)
*
These builds are intended for developers looking to "kick the tyres"
and provide feedback on using the API or by sending bug reports.
Warning: This build is based on an incomplete version of JDK 15
<http://openjdk.java.net/projects/jdk/15/>.
* These early-access , open-source builds are provided under the
o GNU General Public License, version 2, with the Classpath
Exception <http://openjdk.java.net/legal/gplv2+ce.html>.
* Please send feedback via e-mail to loom-dev(a)openjdk.java.net
<mailto:loom-dev@openjdk.java.net>. To send e-mail to this address
you must first subscribe to the mailing list
<http://mail.openjdk.java.net/mailman/listinfo/loom-dev>.
Rgds,Rory
[1] http://jdk.java.net/15/release-notes
--
Rgds, Rory O'Donnell
Quality Engineering Manager
Oracle EMEA, Dublin, Ireland
6 years
- 1
- 0