Design of threadsafe, immutable internal components
by Sanne Grinovero
Hi all,
I'm inspecting some old code, and regularly finding a pattern which
isn't entirely correct; it's not a big deal as it seems to not cause
any problems so far in practice (expect the one I'm working on!), but
I'll share this in hope we can slowly improve such things while
evolving the codebase.
When making an immutable, internal component we'll often have many
fields with a "final" qualifier. This is good and we should definitely
keep doing it.
But also, one needs to ensure that once the constructor of an object
has completed, such objects referenced in the final field should no
longer be mutated (unless of course they are mutated in a thread safe
way as well).
To get more concrete, the following pattern is frequent in our code,
but should not be used:
class A {
private final HashMap state = new HashMap();
A() { //constructor
}
public initState( p ) {
state.put (p, v);
}
}
There's many reasons for this; at this stage my concern is mostly that
the actual state which we're writing in the _state_ field doesn't
benefit from the effect of the final field on visibility, as by
specification the "freeze" of state is applied when the constructor
has concluded.
an additional problem is that such protected methods get to work on a
partially constructed object as the constructor hasn't finished being
invoked yet; this leads to additional subtle errors when the method is
overridden by subclasses or relying on state from superclasses.
A better version could be:
class A {
private final Map state;
A(params) { //constructor
this.state = initState( params );
}
static Map initState( params ) {
HashMap state = new HashMap();
for ( some_loop on params ) {
state.put (p, v);
}
return state;
}
}
If this doesn't work in your case as you need to "collect" some data
by passing A to various other services, like we frequently need, this
would suggest that you need an intermediary object, such as a builder
pattern: collect all things you need, then build the immutable final
representation of the state you need and make sure the builder is
discarded.
Alternatively, that "state" Map could use a ConcurrentHashMap if your
service actually needs runtime state mutation by design.
Please take this in consideration, as it will allow us to write better
maintainable code, unlocks some possible optimisations which are
otherwise hard to implement, and above all is actually correct in
regards to the Java memory model.
In the above example, it's interesting to highlight that the current
code is working fine as we eventually publish references to A over a
barrier, which will publish the state of the post-initialized A.state
, so there's no rush in fixing such things BUT when I need to make
changes to such patterns it's challenging to trace the barriers to
make sure I'm not inadvertently introducing an obscure issue. Would be
best to not rely on such root barriers.
For those who want to know more, a good reference is Chapter 17.5 of
the Java Language Specification.
Thanks!
Sanne
4 years
JDK 16 EA build 21 is available
by Rory O'Donnell
Hi Sanne & Yoann,
OpenJDK 16 Early Access build 21**is now available at
http://jdk.java.net/16
* 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>.
* Schedule (proposed)
2020/12/10 Rampdown Phase One
2021/01/14 Rampdown Phase Two
2021/02/04 Initial Release Candidate
2021/02/18 Final Release Candidate
2021/03/16 General Availability
* Features:
o JEPs targeted to JDK 16, so far:
+ JEP 338: Vector API (Incubator)
<https://openjdk.java.net/jeps/338>
+ JEP 347: Enable C++14 Language Features
<https://openjdk.java.net/jeps/347>
+ JEP 357: Migrate from Mercurial to Git
<https://openjdk.java.net/jeps/357>
+ JEP 369: Migrate to GitHub <https://openjdk.java.net/jeps/369>
+ JEP 376: ZGC: Concurrent Thread-Stack Processing
<https://openjdk.java.net/jeps/376>
+ JEP 386: Alpine Linux Port <https://openjdk.java.net/jeps/386>
+ JEP 387: Elastic Metaspace <https://openjdk.java.net/jeps/387>
+ JEP 388: Windows/AArch64 Port
<https://openjdk.java.net/jeps/388>
**
* Changes in recent builds that maybe of interest:
o Build 21
+ JDK-8236862: Enhance support of Proxy class
+ JDK-8237990: Added Property to Control LDAP Authentication
Mechanisms Allowed to Authenticate Over Clear Connections
+ JDK-8242068: Signed JAR support for RSASSA-PSS and EdDSA
+ JDK-8245417: Improve certificate chain handling
+ JDK-8253952: Refine ZipOutputStream.putNextEntry() to
recalculate ZipEntry's compressed size
o Build 20
+ JDK-8232092: (fs) Files::isWritable returns false on a
writeable root directory (win)
# Reported by JUnit5
+ JDK-8248262: Wrong link target in
ModuleDescriptor#isAutomatic's API documentation
# Reported by JUnit5
+ JDK-8253965: Delete the outdated java.awt.PeerFixer class
+ JDK-8253566: clazz.isAssignableFrom will return false for
interface implementors
# Found by Hibernate Validator
+ JDK-8254177: US/Pacific-New Zone name removed as part of
tzdata2020b
o Build 19
+ JDK-8253761: Wrong URI syntax printed by jar --describe-module
# Reported by JUnit5
Project Lanai Early-Access Build: EA 6 Build 16-lanai+2-229
<http://jdk.java.net/lanai/> (2020/10/4)
* These early-access builds are provided under the GNU General Public
License, version 2, with the Classpath Exception
<http://openjdk.java.net/legal/gplv2+ce.html>.
* These builds are based upon the latest state of the current in
development JDK, and so may contain new features and unresolved bugs
unrelated to Project Lanai. Project Lanai Wiki:
https://wiki.openjdk.java.net/display/lanai/Main
* Please send feedback via e-mail tolanai-dev(a)openjdk.java.net
<mailto:lanai-dev@openjdk.java.net>. To send e-mail to this address
you must firstsubscribe to the mailing list
<https://mail.openjdk.java.net/mailman/listinfo/lanai-dev>.
Project Panama Early-Access Build: Build 16-panama+2-193
<http://jdk.java.net/panama/> (2020/10/1)
* These early-access, open-source builds are provided under the GNU
General Public License, version 2, with the Classpath Exception
<http://openjdk.java.net/legal/gplv2+ce.html>.
* These builds are based on an incomplete version of JDK 16.
* Please send feedback via e-mail topanama-dev(a)openjdk.java.net
<mailto:panama-dev@openjdk.java.net>. To send e-mail to this address
you must firstsubscribe to the mailing list
<http://mail.openjdk.java.net/mailman/listinfo/panama-dev>.
Oracle JRE and JDK Cryptographic Roadmap has been updated [1]
* Oracle has announced plans to add support for x25519 and x448 named
elliptic curve groups to TLS.
* Support is targeted for JDK 11 with the January 2021 CPU release.
Oracle Critical Patch Update released 21-Oct-2020
* https://www.oracle.com/security-alerts/cpuoct2020.html
*__*
Rgds,Rory
[1] https://java.com/en/jre-jdk-cryptoroadmap.html
--
Rgds, Rory O'Donnell
Quality Engineering Manager
Oracle EMEA, Dublin, Ireland
4 years
HCANN evolution
by Sanne Grinovero
Hi all,
While investigating a case of too much memory being held after boot, I
noticed Hibernate Commons Annotations's old design and patterns are a
strong contributor to the problem.
We talked many times about getting rid of it, yet we know it's not
easy as we have a high level of coupling - but I believe we can
achieve it in iterative steps, reducing the coupling.
I now have a draft of patches which remove its capability to load
classes and packages "by name"; this implies it removing any
interaction with classloaders, and associated complexity; this will of
course require some adaptation in ORM but it turns out its own code is
also cleaner as a result (ORM's ClassLoaderService is preferred), so
I'd like to proceed.
Unless there are strong objections, I'll mark all those classes which
I mean to delete as deprecated in HCANN 5.x, and remove them in HCANN
master (6).
Then I'll release the next 5.x and propose the adaptation PR to ORM;
since I'm not actually removing the functionality yet we still have
the option to keep the ORM patches limited to a smaller scope, should
there be any concerns regarding specific details (to be discussed in
PRs), but I don't believe this should be necessary.
I'd also like to release an HCANN 6 preview and have ORM6 use it.
Among other benefits, this will leave the HCANN codebase significantly
smaller and more focused on its core goals; I believe after this
cleanup it looks much better and we might not need to fully get rid of
it, for example it does solve the generics problem quite elegantly, so
there's no need to throw that out too.
Thanks,
Sann
4 years
Re: HCANN evolution
by Sanne Grinovero
On Thu, 22 Oct 2020 at 14:36, Guillaume Smet <guillaume.smet(a)gmail.com> wrote:
>
> On Thu, Oct 22, 2020 at 3:30 PM Sanne Grinovero <sanne(a)hibernate.org> wrote:
>>
>> Sure, I'll do that.
>>
>> Regarding Validator, I believe it doesn't use it?
>
> No, it doesn't!
Great! thanks
4 years, 1 month
Hibernate Search 6.0.0.Beta11 released
by Yoann Rodiere
Hello,
We just published Hibernate Search 6.0.0.Beta11.
This release mainly brings a default analyzer, a way to limit automatic
reindexing to same-entity updates only, a new implementation for AWS IAM
authentication, and a migration helper for applications moving from Search
5 to Search 6.
It also includes an upgrade to Lucene 8.6.2, and Hibernate ORM 5.4.22.Final.
For more information, see our blog:
https://in.relation.to/2020/10/09/hibernate-search-6-0-0-Beta11/
Yoann Rodière
Hibernate Team
yoann(a)hibernate.org
4 years, 1 month
JDK 16 EA build 18 is now available
by Rory O'Donnell
Hi Sanne & Yoann,
OpenJDK 16 Early Access build 18**is now available at http://jdk.java.net/16
* 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 JEPs proposed to target JDK 16
+ JEP 376: ZGC: Concurrent Thread-Stack Processing
<https://openjdk.java.net/jeps/376>
+ JEP 386: Alpine Linux Port <https://openjdk.java.net/jeps/386>
+ JEP 388: Windows/AArch64 Port
<https://openjdk.java.net/jeps/388>
o JEPs targeted to JDK 16, so far:
+ JEP 338: Vector API (Incubator)
<https://openjdk.java.net/jeps/338>
+ JEP 347: Enable C++14 Language Features
<https://openjdk.java.net/jeps/347>
+ JEP 357: Migrate from Mercurial to Git
<https://openjdk.java.net/jeps/357>
+ JEP 369: Migrate to GitHub <https://openjdk.java.net/jeps/369>
+ JEP 387: Elastic Metaspace <https://openjdk.java.net/jeps/387>
* Release Notes are available at http://jdk.java.net/16/release-notes
**
* Changes in recent builds that maybe of interest:
o Build 17
+ JDK-8247281: Object monitors no longer keep strong
references to their associated object
+ JDK-8202473: A type variable with multiple bounds does not
correctly place type annotation
# Reported by ByteBuddy
+ JDK-8234808: jdb quoted option parsing broken
# Reported by Apache Tomcat
o Build 16
+ JDK-8172366: SUN, SunRsaSign, and SunEC Providers Supports
SHA-3 Based Signature Algorithms
+ JDK-8244706: GZIPOutputStream now sets the GZIP OS Header
Field to the correct default value
* Quality Report for September 2020 was published here [1]. Thanks to
everyone who contributed by creating features or enhancements,
logging bugs, or downloading and testing the early-access builds.
*__*
Rgds,Rory
[1]
https://wiki.openjdk.java.net/display/quality/Quality+Outreach+report+Sep...
--
Rgds, Rory O'Donnell
Quality Engineering Manager
Oracle EMEA, Dublin, Ireland
4 years, 1 month
Hibernate Reactive 1.0.0.Alpha10 released
by Sanne Grinovero
Hi all,
We released 1.0.0.Alpha10 of Hibernate Reactive, to be able to upgrade
both Hibernate ORM and Hibernate Reactive in Quarkus. Still work in
progress though!
Thanks
4 years, 1 month
