Building a Second Level Cache Provider
by Ju＠N
Hello devs,
I’m trying to build a new hibernate second level cache provider and I’m
having a difficult time trying to find documentation or guides about how to
do it properly. So far the only thing I’ve found is the package description
in the javadocs for *org.hibernate.cache.spi.support* and
*org.hibernate.cache.spi*… it’s a good start and I’ve been able to set up a
new dummy provider locally, but I’m interested in more technical details
like: when and how are the actual methods invoked?, things to consider when
making the cache distributed, etc.
As a side note, is there any public battery of test that I can use to
verify that my implemented provider works as expected when integrated with
Hibernate?.
Any pointers would be greatly appreciated.
Cheers.
--
Ju@N
4 years, 9 months
Release Announcement: General Availability of Java 14 / JDK 14
by Rory O'Donnell
Hi Sanne,
**Release Announcement: General Availability of Java 14 / JDK 14 [1] * *
* JDK 14, the reference implementation of Java 14, is now Generally
Available.
* GPL-licensed OpenJDK builds from Oracle are available here:
https://jdk.java.net/14
* JDK 14 Release notes
<https://www.oracle.com/technetwork/java/javase/14-relnote-issues-5809570....>
JDK 14 includes sixteen features [2]:
305: Pattern Matching for instanceof (Preview)
343: Packaging Tool (Incubator)
345: NUMA-Aware Memory Allocation for G1
349: JFR Event Streaming
352: Non-Volatile Mapped Byte Buffers
358: Helpful NullPointerExceptions
359: Records (Preview)
361: Switch Expressions (Standard)
362: Deprecate the Solaris and SPARC Ports
363: Remove the Concurrent Mark Sweep (CMS) Garbage Collector
364: ZGC on macOS
365: ZGC on Windows
366: Deprecate the ParallelScavenge + SerialOld GC Combination
367: Remove the Pack200 Tools and API
368: Text Blocks (Second Preview)
370: Foreign-Memory Access API (Incubator)
Thanks to everyone who contributed to JDK 14, whether by creating
features or enhancements, logging bugs, or downloading and testing the
early-access builds.
OpenJDK 15 EA build 14 is now available at http://jdk.java.net/15 *
*
* 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>.
* Significant changes since the last availability email:
o Build 13 - JDK-8238555
<https://bugs.openjdk.java.net/browse/JDK-8238555>: Allow
Initialization of SunPKCS11 with NSS when there are external
FIPS modules in the NSSDB
o Build 10 - JDK-8237776
<https://bugs.openjdk.java.net/browse/JDK-8237776>: Shenandoah:
Wrong result with Lucene test
+ Reported by Apache Lucene.
o Build 9 - JDK-8222793
<https://bugs.openjdk.java.net/browse/JDK-8222793>: Javadoc tool
ignores "-locale" param and uses default locale for all messages
and texts
+ Reported by Apache Lucene.
Project Metropolis Early-Access Builds - Build 14-metropolis+1-17
<http://jdk.java.net/metropolis/> (2020/3/5)
* These builds are intended for developers looking to test and provide
feedback on using /Graal,/ in form of native library
/(libjvmcicompiler.so)/, instead of C2 as HotSpot high optimizing
JIT compiler.
* 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>.
* Please send feedback via e-mail to metropolis-dev(a)openjdk.java.net
<mailto:metropolis-dev@openjdk.java.net>. To send e-mail to this
address you must first subscribe to the mailing list
<https://mail.openjdk.java.net/mailman/listinfo/metropolis-dev>.
Regards,
Rory
[1] https://mail.openjdk.java.net/pipermail/jdk-dev/2020-March/004089.html
[2] https://openjdk.java.net/projects/jdk/14
--
Rgds, Rory O'Donnell
Quality Engineering Manager
Oracle EMEA, Dublin, Ireland
4 years, 9 months
Re: [hibernate-dev] Jakarta EE: JPA 3.0 is coming
by Sanne Grinovero
On Wed, 11 Mar 2020 at 08:39, Yoann Rodiere <yrodiere(a)redhat.com> wrote:
> > Yet I'm convinced that having a release
> > which provides full JPA 3.0 TCK between 5 and 6 (or however it gets
> > renamed) would be no good to us, as it would create an adoption
> > barrier for both cathegories of people: the ones not interested to
> > migrate away from JPA2, and the ones not interested to migrate beyond
> > JPA3.
>
> I get that, but I'm definitely not as hopeful as you are as to the
> reliability of those bytecode hacks you mentioned. But I guess that's an
> uphill battle.
>
I'm not a fan of bytecode hacks either, so maybe let's just see what a POC
looks like before tearing it down?
What's to stop you from supporting JPA2.0 in ORM 7, with the same hacks you
> mentioned for JPA3?
>
Right, and in fact I mentioned as one of the possibilities for ORM6 to be
able to read and interpret the "legacy" annotations from JPA2.
I believe that's important to not get in the way of adoption but rather
actively help with some flexibility, otherwise people will have a very hard
time to upgrade to 6, and that's something that risks becoming a
significant burden on us all.
Thanks,
Sanne
> - People who want JPA3 only have a hack-free ORM 7 that happens to
> support JPA2 annotations.
> - People who want JPA2 can migrate to ORM 7, and we'll provide hacks
> to make it work.
>
> At least we wouldn't be penalizing people who want to migrate to JPA3 with
> potentially unreliable bytecode hacks. Only people who want the latest and
> greatest on an older API (which is, after all, quite an unreasonable
> request) would have to put up with that.
> And we'll be able to completely ignore these hacks in ORM 8 after we
> rebased it on 7, since ORM 8 will drop support for JPA2 (I hope?).
>
> Yoann Rodière
>
> Sr. Software Engineer, Middleware Engineering, Hibernate team
>
> Red Hat <https://www.redhat.com>
>
> <https://www.redhat.com>
>
>
> On Wed, 11 Mar 2020 at 00:17, Guillaume Smet <guillaume.smet(a)gmail.com>
> wrote:
>
>> On Tue, Mar 10, 2020 at 7:12 PM Sanne Grinovero <sanne(a)hibernate.org>
>> wrote:
>>
>> > The "big bang" approach that Validator implemented is an option as
>> > well; but the context is a bit different as we're having an actual
>> > major release being developed, and the matter of possible time
>> > pressure.
>> >
>>
>> Thus the proposal of Yoann and me to just rename the current 6 to a later
>> version and release a new major version that only contains the Jakarta
>> package change.
>>
>> That way, we don't end up doing additional work and having weird versions
>> partially supporting both.
>>
>> --
>> Guillaume
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>>
4 years, 9 months
Study on annotating implementation choices, design choices and technical debt
by Fiorella Zampetti
Dear all,
As software engineering research teams at the University of Sannio
(Italy) and Eindhoven University of Technology (The Netherlands) we
are interested in investigating the protocol used by developers while
they have to annotate implementation and design choices during their
normal development activities. More specifically, we are looking at
whether, where and what kind of annotations developers usually use
trying to be focused more on those annotations mainly aimed at
highlighting that the code is not in the right shape (e.g., comments
for annotating delayed or intended work activities such as TODO,
FIXME, hack, workaround, etc). In the latter case, we are looking at
what is the content of the above annotations, as well as how they
usually behave while evolving the code that has been previously
annotated.
When answering the survey, in case your annotation practices are
different in different open source projects you may contribute, please
refer to how you behave for the projects where you have been
contacted.
Filling out the survey will take about 5 minutes.
Please note that your identity and personal data will not be
disclosed, while we plan to use the aggregated results and anonymized
responses as part of a scientific publication.
If you have any questions about the questionnaire or our research,
please do not hesitate to contact us.
You can find the survey link here:
https://forms.gle/u18bWCehBQoNPPog6
Thanks and regards,
Fiorella Zampetti (fzampetti(a)unisannio.it)
Gianmarco Fucci (gianmarcofucci94(a)gmail.com)
Alexander Serebrenik (a.serebrenik(a)tue.nl)
Massimiliano Di Penta (dipenta(a)unisannio.it)
4 years, 9 months
ORM 6 : hibernate-orm-modules & Antlr 4
by Steve Ebersole
I am working on re-enabling the `hibernate-orm-modules` module but am
running into a problem being able to resolve Antlr 4 classes. I'm sure the
problem is related to the entry `<module name="org.antlr"/>` in
`hibernate-core.xml` but I am not sure how to fix that. Any ideas?
4 years, 9 months
Jakarta EE: JPA 3.0 is coming
by Sanne Grinovero
Hi all,
as a consequence of having moved all Java EE technologies to the
Jakarta EE project at the Eclipse foundation, the API needs to change
so to address the Oracle trademark requirements.
The new JPA project lives here:
- https://github.com/eclipse-ee4j/jpa-api
For context, to make it simpler for people to adopt the new API the
Jakarta EE team decided to not allow any other change to the API; this
would make it possible for people to migrate their existing code bases
by running a simple "search and replace all". This implies that even
though it's a new major version, it's sadly not a good time to
challenge any API or spec working as this is intentionally frozen.
And (our very own!) Scott Marlow helped with the primary change, which
you can see here having quite an impact:
- https://github.com/eclipse-ee4j/jpa-api/pull/231
It's just a small change of renaming all packages "javax.persistence"
to "jakarta.persistence" .. but it has wide impact all over.
We should start thinking how to make support for JPA 3 happen in
Hibernate ORM; there's of course many options, but we need to take
into account some points:
1)We can't spend years of brilliant minds on this
2)We don't want to make the migration too hard to users
3)We normally promise backwards compatibility within minor releases of
our projects
4)While Hibernate ORM 6 is making great progress, it's a very large
quest to finish it. It's not wise to try to time-box it, while we
might need to deliver JPA 3 at some (TBD) reasonable deadline.
5)Whatever we do, it shall not have a major burden on the team working
on ORM6 as that's our most important project.
I hope we agree on these points?
So I think I will spend some time exploring the fesability of a JPA
3.0 in some 5.x branch, while aiming at maintaining backwards
compatibility.
To address requirement 1# , I'll just explore this without making a
commitment to the plan.. also I think it would be interesting to
explore a partial migration, for example I suppose it might be
possible for us to "accept" the use of mapping annotations from JPA
3.0 (on top of the ones from JPA 2.0) while not exposing the full
proper API yet.
Considering the API is literally the same contract, if you except the
package name, it might be feasible to expose the full JPA 3.0 in a
backwards compatible way as well but this might require:
- use of bridge methods, e.g. bytecode manipulation at build time [1]
- depend on both JPA API packages
In particular I wonder, how would you all feel if (for example)
Hibernate ORM 5.5.x were to depend on both JPA 2 and JPA 3 API
artifacts?
And additional change to take into account is that the JPA3 API now
defines a module-info resource; it would be nice to try taking
advantage of that but it's of course more complicated if we have a
hybrid JPA 2/3 implementation. I guess that aspect will have to wait
for ORM6, but also that ORM6 being rebased on this work could benefit
from using the JPA3 groundwork.
Thanks,
Sanne
1 - https://github.com/dmlloyd/bridger
4 years, 9 months
