Tags
Authors
Without doubt, the module system (JPMS) is the most prominent feature of Java 9. But there are many other useful additions to the JDK, which have not been discussed as widely yet.
One of them is the new ToolProvider SPI, which defines a uniform way to invoke all the tools coming with the JDK (e.g. jar, jlink etc.) in a programmatic way.
E.g. imagine you’d like to create a JAR archive from within your Java application.
Before Java 9, you had two options to do so:
-
Start a separate process to run the
jarbinary -
Find out which classes are used by the
jarcommand internally and invoke them directly
Neither option is ideal.
The former incurs some overhead for forking an OS level process and it requires a bit of coding to locate the binary to execute in the Java home directory and to correctly capture any output of the forked process.
The second option doesn’t come with the disadvantages of forking a new process, but it requires knowledge about the implementation of the tool to execute.
So for instance in the case of the jar command, you’d have to know that java.util.jar.JarOutputStream is used to produce JAR files.
Originally started as a Google Summer of Code project by Mincong Huang, Hibernate Search 5.9 will feature integration with JSR 352, "Batch Applications for the Java Platform". This integration provides a new implementation of mass indexing (indexing a high volume of entities) as a JSR 352 job.
Yesterday we released 5.9.0.Beta1 so you can try it out already!
Why is it nice? How to use it? Let’s find out!
We just published 5.9.0.Beta1, the first beta release for the 5.9 branch. This release brings several bug fixes, but most importantly a new mass indexer based on the JSR 352 specification, "Batch Applications for the Java Platform"!
Welcome to the Hibernate community newsletter in which we share blog posts, forum, and StackOverflow questions that are especially relevant to our users.
We just released the 6.0.5.Final version of Hibernate Validator containing a couple of important bugfixes and some enhancements.
This is a recommended upgrade for everyone using Hibernate Validator 6.0.x and it is a drop-in replacement of 6.0.4.Final.
Welcome to the Hibernate community newsletter in which we share blog posts, forum, and StackOverflow questions that are especially relevant to our users.
As you may know, Bean Validation 2.0 has been released a couple of months ago and Hibernate Validator 6.0 is its reference implementation.
Hibernate Validator is not the only Bean Validation implementation out there, we have one (friendly) competitor called Apache BVal.
Apache BVal has not caught up with Bean Validation 2.0 yet but, as the last benchmark in the Bean Validation field is dated from 2010 (remember "Machete don’t text"?), I thought it was high time to revisit this benchmark and get some fresh numbers.
Especially with all the optimization work we made for 6.0.
We just published three bugfix releases of Hibernate Search: 5.6.4.Final, 5.7.3.Final and 5.8.2.Final.
Those releases include in particular an upgrade of the Lucene dependency to 5.5.5,
which fixes CVE-2017-12629.
This vulnerability should only affect you if you use org.apache.lucene.queryparser.xml.CoreParser
and feed it with input from untrusted sources: this class is not used by Hibernate Search itself.
However, the upgrade is recommended even if you don’t use this class.
Welcome to the Hibernate community newsletter in which we share blog posts, forum, and StackOverflow questions that are especially relevant to our users.
Another week, another Hibernate Validator release. You might ask why we release a new maintenance version of the 6.0 branch so soon: it is mostly to provide a patch for WildFly 11 Final but it is also packed with nice enhancements!
This is a recommended upgrade for everyone using Hibernate Validator 6.0.x and it is a drop-in replacement of 6.0.3.Final.
