Defaultable service strategies
by Steve Ebersole
Thoughts on allowing certain services to be defaulted to the single
implementor registered with the `StrategySelector` service when there is
just one?
For example, when resolving the RegionFactory unless both (a)
`hibernate.cache.region.factory_class` and (b) one of
`hibernate.cache.use_second_level_cache` or
`hibernate.cache.use_query_cache` are defined caching support will be
disabled. What I am proposing would kick in in this case and check to see
if there is just a single RegionFactory registered with the
StrategySelector and if so use that one.
It would allow Hibernate to more seamlessly operate as a JPA provider too,
as currently to use caching with JPA and Hibernate users have to do the
normal JPA stuff and then also define these Hibernate settings. It would
be nicer if they could just do the JPA stuff.
7 years, 9 months
[HV] Retiring HibernateValidatorContext#parameterNameProvider()
by Guillaume Smet
Hi,
So I know we like to have API compatibility discussions these days, so
let's start a new one.
FWIW, this discussions doesn't come out of the blue, it's based on
discussions we had for one of Marko's PRs.
In HV, you can set the parameter name provider at the VF level and you can
also override it on a per Validator basis using
HibernateValidatorContext#parameterNameProvider().
To be honest, I'm a bit skeptical about the usefulness of overriding this
setting at the Validator level: it really seems to be a global setting,
especially because it has an influence on what could be considered a
metadata and metadata are considered static in HV.
At the moment, the parameter name is resolved at runtime each time it's
required due to this feature.
I would like to deprecate the feature for now and possibly remove it in a
future version (I thought about maybe keeping the method for a while but
logging a warning stating it's not doing anything anymore?).
We expect some runtime performance enhancement (this is not the reason of
this post) but it seems we could also get rid of storing the Executable in
the metadata and reduce our memory footprint for executables, which would
be nice.
Thoughts?
--
Guillaume
7 years, 9 months
Problem with releasing 5.1.13.Final
by Gail Badner
I am able to build the documentation using Andrea's suggestion and now I'm
struggling with gradle.
I released the staging repository on nexus last night to make a deadline.
I also updated the version in build.gradle to 5.1.14-SNAPSHOT, which was
probably a mistake.
Today I went back to build the distributions. The problem is that after
setting the version back to 5.1.13.Final in build.gradle, gradle
automatically recompiles and rebuilds the jars.
That is (obviously) a problem because they won't be the same as what was
uploaded to nexus.
I've been trying some things out on a copy of the directory so I still have
the original jars intact.
I've tried --no-rebuild, but it doesn't seem to work.
Worst case, I suppose I can re-release as 5.1.14.Final on Wednesday, but I
really don't want to do that.
Any suggestions?
Thanks!
Gail
7 years, 9 months
[in.relation.to] Only display post summary in list pages
by Guillaume Smet
Hi,
It's been bugging me for a while and I took some time this morning to do
some changes to the post list pages of the blog.
We currently display the whole articles whereas I thought it would be
better to only display a summary of them and get people to the full article
with a button.
I pushed the changes on http://staging.in.relation.to/ .
It's based on the Asciidoctor preamble (most of the time) so it takes the
paragraphs that are before the first title. It's not perfect but it works
pretty well for most of the posts. We should probably try to write our
posts so that the summary looks good.
Thoughts?
--
Guillaume
7 years, 9 months
Release Announcement: General Availability of JDK 10
by Rory O'Donnell
Hi Sanne,
A number of items to share with you today :
*1) JDK 10 General Availability *
JDK 10, the first release produced under the six-month rapid-cadence
release model [1][2], is now Generally Available.
We've identified no P1 bugs since we promoted build 46 almost two weeks
ago, so that is the official GA release, ready for production use.
GPL'd binaries from Oracle are available here: http://jdk.java.net/10
This release includes twelve features:
* 286: Local-Variable Type Inference <http://openjdk.java.net/jeps/286>
* 296: Consolidate the JDK Forest into a Single Repository
<http://openjdk.java.net/jeps/296>
* 304: Garbage-Collector Interface <http://openjdk.java.net/jeps/304>
* 307: Parallel Full GC for G1 <http://openjdk.java.net/jeps/307>
* 310: Application Class-Data Sharing <http://openjdk.java.net/jeps/310>
* 312: Thread-Local Handshakes <http://openjdk.java.net/jeps/312>
* 313: Remove the Native-Header Generation Tool (javah)
<http://openjdk.java.net/jeps/313>
* 314: Additional Unicode Language-Tag Extensions
<http://openjdk.java.net/jeps/314>
* 316: Heap Allocation on Alternative Memory Devices
<http://openjdk.java.net/jeps/316>
* 317: Experimental Java-Based JIT Compiler
<http://openjdk.java.net/jeps/317>
* 319: Root Certificates <http://openjdk.java.net/jeps/319>
* 322: Time-Based Release Versioning <http://openjdk.java.net/jeps/322>
*2) JDK 11 EA build 5, under both the GPL and Oracle EA licenses, are
now available at **http://jdk.java.net/11**.*
* Schedule, status & features
o http://openjdk.java.net/projects/jdk/11/
* Release Notes:
o http://jdk.java.net/11/release-notes
* Summary of changes
o https://download.java.net/java/early_access/jdk11/5/jdk-11+5.html
*3) The Z Garbage Collector Project, early access builds available : *
The first EA binary from from The Z Garbage Collector Project, also
known as ZGC, is now available. ZGC is a scalable low latency garbage
collector. For information on how to enable and use ZGC, please see the
project wiki.
* Project page: http://openjdk.java.net/projects/zgc/
* Wiki: https://wiki.openjdk.java.net/display/zgc/Main
*4) Quality Outreach Report for **March 2018 **is available
*
* https://wiki.openjdk.java.net/display/quality/Quality+Outreach+report+Mar...
*5) **Java Client Roadmap Update
*
* We posted a blog [3] and related white paper [4] detailing our plans
for the Java Client.
Rgds,Rory
[1] https://mreinhold.org/blog/forward-faster
[2]
http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html
[3] Blog:
https://blogs.oracle.com/java-platform-group/the-future-of-javafx-and-oth...
[4] Whitepaper:
http://www.oracle.com/technetwork/java/javase/javaclientroadmapupdate2018...
--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland
7 years, 9 months
JPA Events
by Petar Tahchiev
Hi guys,
I opened an issue in the JPA spec here yesterday:
https://github.com/javaee/jpa-spec/issues/167
because @PreUpdate and @PrePersist events are not fired when I save a
collection on the owner. Since then, a discussion with Oliver Gierke from
the SpringDATA team started and I wanted to know your opinion on this.
Basically the question is: if you have Product with a Collection<String>
attribute and you update the collection, shall @PreUpdate event be fired.
As Oliver mentioned the JPA spec says:
-------
The PreUpdate and PostUpdate callbacks occur before and after the database
update operations to entity data respectively.
-------
so to me it is obvious that when an attribute of the Product is changed
then this means that @PreUpdate event for the Product must be fired.
What do you think? Should I open a bug in Hibernate?
--
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611
7 years, 9 months
