Hibernate organization membership on GitHub
by Yoann Rodiere
Hello,
As part of the move to Commonhaus, I'm currently going through our GitHub
setup, and I'm noticing we have a lot of users with extensive (and I mean
*extensive*, sometimes admin or even owner) access to our
organization/repositories, but who are no longer regular contributors.
Additionally, we also have organization members on GitHub who are not
technically Hibernate members: they have never actually contributed to
Hibernate, but are there for technical reasons, for example because they're
coworkers who helped out with some infrastructure issue.
While it's fine in principle, because we trust these people, it's very,
very far from security best practices. Account hacking happens, email
addresses get stolen, and the people using these GitHub accounts might one
day be an attacker instead of the person we trust.
According to Commonhaus' automated report, we're currently at 32 people
having admin rights on one Hibernate repository or another. Which I think
we can all agree is much more than necessary.
For that reason, I'd like to propose that:
1. *We create an "Alumni" team in our GitHub organization*, moving to that
team anyone who is actually a member, but hasn't contributed for... let's
say 2 years? Of course this isn't a permanent thing, and we can simply move
alumni back to the relevant team if they become active again.
2. *We move non-members out of our GitHub organization*, or to "external
collaborators" (that's a GitHub feature) if still necessary.
3. *We schedule yearly audits of our GitHub configuration* to review access
rights again in the future, and move people to the Alumni team as necessary.
Note moving people in and out of teams will get them notified, so I would
send another email directly to impacted people before/during the move, to
avoid this being seen as personal/insulting. It's really not.
*Thoughts, opinions, +1s?*
Yoann Rodière
Hibernate team
5 days, 13 hours
New CI machine preview
by Sanne Grinovero
You're all welcome to play with http://54.225.162.168/
however please keep these in mind:
- it's not the final machine: don't put too much effort in creating
nice build scripts as we'll reset it to clean state soon. We *might*
be able to store jobs defined so far, but we might choose not to.
- domain name should be coming: ci.hibernate.org ..not sure when, got
no replies so far from.
- authentication: just click on login, it will use OAuth2 to request
your identity via your GitHub account. Permissions to create new jobs,
edit existing jobs, run a build manually depend on your github account
be part of the Hibernate organization (or not, in which case you have
read only status)
At this stage I'd like to get a feeling if the hardware is powerful
enough, and also we need to select which other plugins we want to use,
I'm looking especially to:
- static analysis reports
- pull requests integration
both are relatively undefined, we can of course start simple and
improve later.. just checking this fits basic needs now.
Sanne
2 weeks
Hibernate Search 8.0.0.Final released
by Marko Bekhta
Hello,
We are excited to announce the release of Hibernate Search 8.0.0.Final.
This version introduces new metric aggregations, compatibility with the
latest Elasticsearch and OpenSearch versions, a new Lucene 10 based
backend, allows projecting multivalued fields to any container, improves
logging by grouping logs into categories, brings a preview of Hibernate
Search's static metamodel for building search queries with compile-time
checks and more.
See our blog for more information:
https://in.relation.to/2025/06/06/hibernate-search-8-0-0-Final/
See our website for more information about the 8.0 series in general:
https://hibernate.org/search/releases/8.0/
Have a nice day,
Marko Bekhta
Hibernate Team
marko(a)hibernate.org
5 months
JDK 25 feature set is now frozen!
by David Delabassee
Welcome to the June installment of the OpenJDK Quality Outreach update.
JDK 25, scheduled for General Availability on September 16, 2025, has entered Rampdown Phase One (RDP1)[1]. The JDK 25 feature set is now frozen (see JDK 25 details below), and only low-risk enhancements will be considered. Please help us identify potential issues in the coming weeks by testing your projects on JDK 25 EA builds. With enough lead time, we can resolve them before JDK 25 transitions to the Release Candidate phase in early August[2].
Be make sure to review the JDK 25 heads-ups below; two of them pertain to changes in file operations on Windows.
Last but certainly not least, you are invited to attend next week’s JCP EC online public meeting, where Alex Buckley will give a presentation on Tip & Tail Development—a topic particularly relevant for open-source project maintainers. See [3] for details, the meeting will be recorded.
[1] https://mail.openjdk.org/pipermail/jdk-dev/2025-June/010191.html
[2] https://openjdk.org/projects/jdk/25/
[3] https://jcp.org/aboutJava/communityprocess/ec-public/materials/2025-06-10...
# Heads-up - JDK 25: java.io.File.delete no longer deletes read-only files on Windows
`File.delete` has been changed on Windows so that it now fails and returns `false` for regular files when the DOS read-only attribute is set. Prior to JDK 25, `File.delete` would delete read-only files by first removing the DOS read-only attribute before attempting deletion. However, because removing the attribute and deleting the file are not a single atomic operation, this could result in the file remaining but with modified attributes if the deletion failed. Applications that depend on the previous behavior should be updated to clear the file attributes before deleting files.
To ease the transition, a system property has been introduced to restore the previous behavior. Running with `-Djdk.io.File.allowDeleteReadOnlyFiles=true` will cause `File.delete` to remove the DOS read-only attribute before attempting deletion, restoring the legacy behavior.
See https://bugs.openjdk.org/browse/JDK-8355954 for more details.
# Heads-up - JDK 25: File operations on Windows now always fail if the used name ends with a space
File operations on a path with a trailing space in a directory or file name, e.g. "C:\\SomeFolder\\SomeFile ", now fail consistently on Windows. For example. `File::mkdir` will return `false`, or `File::createNewFile` will throw `IOException` if an element in the path has a trailing space. Such pathnames are not legal on Windows. Prior to JDK 25, operations on a `File` created from such an illegal abstract pathname could appear to succeed when in fact they did not.
See https://bugs.openjdk.org/browse/JDK-8354450 for more details.
# Heads-up - JDK 25: Separate Metaspace and GC Printing
Historically the printing of Metaspace and GC logs have been combined; this was a result of permanent generation (PermGen) being a part of the GC Heap. However, Metaspace has replaced PermGen and resides in its own native memory location outside of the GC Heap. With Metaspace no longer a part of the GC Heap, the reason for combining the messaging no longer makes sense and could lead to confusion.
Starting with JDK 25, the way logging is tagged in the HotSpot JVM will change: although the content of the logs will remain the same, messages related to Metaspace will now use the existing Metaspace tag.
As part of this update, there are also some user-facing changes to `jcmd`. To better clarify that Metaspace is not part of the GC Heap, Metaspace information is no longer displayed with the `GC.heap_info` command. Instead, details about Metaspace memory usage have been moved to the `VM.metaspace` command.
See https://bugs.openjdk.org/browse/JDK-8356848 for more details.
# JDK 25
The JDK 25 early-access builds 25 are available[4] and are provided under the GNU General Public License v2, with the Classpath Exception. The Release Notes are available here[5].
Please refer to the “Topics of Interest” section at the end of this update for additional information on JDK 25.
## JEPs integrated in JDK 25:
- JEP 470: PEM Encodings of Cryptographic Objects (Preview)
- JEP 502: Stable Values (Preview)
- JEP 503: Remove the 32-bit x86 Port
- JEP 505: Structured Concurrency (5th Preview)
- JEP 506: Scoped Values
- JEP 507: Primitive Types in Patterns, instanceof, and switch (3rd Preview)
- JEP 508: Vector API (10th Incubator)
- JEP 509: JFR CPU-Time Profiling (Experimental)
- JEP 510: Key Derivation Function API
- JEP 511: Module Import Declarations
- JEP 512: Compact Source Files and Instance Main Methods
- JEP 513: Flexible Constructor Bodies
- JEP 514: Ahead-of-Time Command-Line Ergonomics
- JEP 515: Ahead-of-Time Method Profiling
- JEP 518: JFR Cooperative Sampling
- JEP 519: Compact Object Headers
- JEP 520: JFR Method Timing & Tracing
- JEP 521: Generational Shenandoah
## Changes in recent JDK 25 builds that may be of interest:
- JDK-8340321: Disable SHA-1 in TLS/DTLS 1.2 handshake signatures
- JDK-8354276: Strict HTTP header validation
- JDK-8356848: Separate Metaspace and GC printing
- JDK-8355954: java.io.File.delete no longer deletes read-only files on Windows
- JDK-8353440: Disable FTP fallback for non-local file URLs by default
- JDK-8354908: javac mishandles supplementary character in character literal
- JDK-8355360: -d option of jwebserver command should accept relative paths
- JDK-8354084: Streamline XPath API's extension function control
- JDK-8354305: SHAKE128 and SHAKE256 MessageDigest algorithms
- JDK-8343110: Add getChars(int, int, char[], int) to CharSequence and CharBuffer
- JDK-8356154: Respecify java.net.Socket constructors that allow creating UDP sockets to throw IllegalArgumentException
- JDK-8322810: Lambda expression types can't be classes
- JDK-8352612: No way to add back lint categories after "none"
- JDK-8348732: SunJCE and SunPKCS11 have different PBE key encodings
- JDK-8350498: Remove two Camerfirma root CA certificates
- JDK-8350441: ZGC: Overhaul Page Allocation
- JDK-8347337: ZGC: String dedups short-lived strings
- JDK-8350279: HttpClient: Add a new HttpResponse method to identify connections
- JDK-8350753: Deprecate UseCompressedClassPointers
- JDK-8254622: Hide superclasses from conditionally exported packages
- JDK-8346465: Add a check in setData() to restrict the update of Built-In ICC_Profiles
- JDK-8347472: Correct Attribute traversal and writing for Code attributes
- JDK-8351654: Agent transformer bytecodes should be verified
- JDK-8348967: Deprecate security permission classes for removal
- JDK-8353642: Deprecate URL::getPermission method and networking permission classes for removal
- JDK-8353856: Deprecate FlighRecorderPermission class for removal
- JDK-8353614: JFR: jfr print --exact
- JDK-8346109: Create JDK taglet for additional preview notes
- JDK-8285888: Clarify that java.net.http.HttpClient do NOT support Digest authentication
- JDK-8350542: Optional.orElseThrow(Supplier) does not specify behavior when supplier returns null
- JDK-8342206: Convenience method to check if a constant pool entry matches nominal descriptors
Note: For a more exhaustive list of changes, please see here[6].
[4] https://jdk.java.net/25/
[5] https://jdk.java.net/25/release-notes
[6] https://github.com/openjdk/jdk/compare/jdk-25+17...jdk-25+25
# JavaFX 25 Early-Access Builds
These are early access builds of the JavaFX 25 Runtime, built from the openjdk/jfx repository. They enable JavaFX application developers to build and test their applications with JavaFX 25 on JDK 25. Although these builds are designed to work with JDK 25 EA, they are also compatible with JDK 22 and later versions.
The latest early access builds of JavaFX 25 Builds 18 (2025/5/23) are available[7], under the GNU General Public License, version 2, with the Classpath Exception. JavaFX 25 API Javadocs[8] are available too.
[7] https://jdk.java.net/javafx25/
[8] https://download.java.net/java/early_access/javafx25/docs/api/overview-su...
# JavaFX Direct3D 12 Early-Access Builds
These are early access builds of JavaFX from the "direct3d12" branch of the openjdk/jfx-sandbox repository[9], which implement the new Direct3D 12 graphics rendering pipeline for Windows x64. The goal of these EA builds is to solicit feedback as we work toward integrating this functionality into JavaFX. Binaries[10] are provided for convenience, so users do not need to build from source.
Feedback can be reported to the openjfx-dev mailing list[11]. These builds are provided under the GNU General Public License, version 2, with the Classpath Exception, and are based on an incomplete version of JavaFX 25.
[9] https://github.com/openjdk/jfx-sandbox/tree/direct3d12
[10] https://jdk.java.net/javafxdirect3d12/
[11] https://mail.openjdk.org/pipermail/openjfx-dev/
# Topics of Interest
- Java 25 Brings 18 JEPs - Inside Java Newscast
https://inside.java/2025/06/05/newscast-92/
- Strings Just Got Faster in JDK 25
https://inside.java/2025/05/01/strings-just-got-faster/
- What's new for JFR in JDK 25
https://egahlin.github.io/2025/05/31/whats-new-in-jdk-25.html
- Structured Concurrency Revamp in Java 25 - Inside Java Newscast
https://inside.java/2025/05/08/newscast-91/
- Where Is the Java Language Going?
https://inside.java/2025/04/20/javaone-future-java/
- Java for AI
https://inside.java/2025/05/03/javaone-java-ai/
- Pattern Matching in Java: Better Code, Better APIs
https://inside.java/2025/05/24/javaone-pattern-matching/
- Towards a JSON API for the JDK
https://mail.openjdk.org/pipermail/core-libs-dev/2025-May/145905.html
- Modern Java Development with Tip & Tail
https://inside.java/2025/05/17/javaone-tip-tail/
- Java 24, Faster Than Ever
https://inside.java/2025/05/17/javaone-faster-jdk24/
- “Ahead of Time Computation” with Dan Heidinga - Inside Java Podcast
https://inside.java/2025/05/16/podcast-036/
- “Stream Gatherers” with Viktor Klang - Inside Java Podcast
https://inside.java/2025/05/05/podcast-035/
- Garbage Collection in Java: The Performance Benefits of Upgrading
https://inside.java/2025/05/14/javaone-garbage-collection/
- JavaFX 24 and Beyond
https://inside.java/2025/05/10/javaone-javafx/
- JDK 24 Security Enhancements
https://seanjmullan.org/blog/2025/04/07/jdk24
~
This concludes the update for now. Should you experience any difficulties while testing your projects with the latest JDK early-access builds, just ping me.
PS: If you no longer wish to receive OpenJDK Quality Outreach updates, please let me know.
--David
5 months
Re: Hibernate organization membership on GitHub
by Steve Ebersole
+1
On Wed, Jun 4, 2025 at 1:53 PM Steve Ebersole <steven.ebersole(a)gmail.com>
wrote:
> +1
>
> On Wed, Jun 4, 2025 at 7:36 AM Davide D'Alto <daltodavide(a)gmail.com>
> wrote:
>
>> +1
>>
>> On Wed, Jun 4, 2025 at 2:14 PM Sanne Grinovero via hibernate-dev <
>> hibernate-dev(a)lists.jboss.org> wrote:
>>
>> > +1
>> >
>> >
>> > On Wed, 4 Jun 2025 at 11:32, Yoann Rodiere via hibernate-dev <
>> > hibernate-dev(a)lists.jboss.org> wrote:
>> >
>> > > Hello,
>> > >
>> > > As part of the move to Commonhaus, I'm currently going through our
>> GitHub
>> > > setup, and I'm noticing we have a lot of users with extensive (and I
>> mean
>> > > *extensive*, sometimes admin or even owner) access to our
>> > > organization/repositories, but who are no longer regular contributors.
>> > >
>> > > Additionally, we also have organization members on GitHub who are not
>> > > technically Hibernate members: they have never actually contributed to
>> > > Hibernate, but are there for technical reasons, for example because
>> > they're
>> > > coworkers who helped out with some infrastructure issue.
>> > >
>> > > While it's fine in principle, because we trust these people, it's
>> very,
>> > > very far from security best practices. Account hacking happens, email
>> > > addresses get stolen, and the people using these GitHub accounts might
>> > one
>> > > day be an attacker instead of the person we trust.
>> > >
>> > > According to Commonhaus' automated report, we're currently at 32
>> people
>> > > having admin rights on one Hibernate repository or another. Which I
>> think
>> > > we can all agree is much more than necessary.
>> > >
>> > > For that reason, I'd like to propose that:
>> > >
>> > > 1. *We create an "Alumni" team in our GitHub organization*, moving to
>> > that
>> > > team anyone who is actually a member, but hasn't contributed for...
>> let's
>> > > say 2 years? Of course this isn't a permanent thing, and we can simply
>> > move
>> > > alumni back to the relevant team if they become active again.
>> > > 2. *We move non-members out of our GitHub organization*, or to
>> "external
>> > > collaborators" (that's a GitHub feature) if still necessary.
>> > > 3. *We schedule yearly audits of our GitHub configuration* to review
>> > access
>> > > rights again in the future, and move people to the Alumni team as
>> > > necessary.
>> > >
>> > > Note moving people in and out of teams will get them notified, so I
>> would
>> > > send another email directly to impacted people before/during the
>> move, to
>> > > avoid this being seen as personal/insulting. It's really not.
>> > >
>> > > *Thoughts, opinions, +1s?*
>> > >
>> > > Yoann Rodière
>> > > Hibernate team
>> > > _______________________________________________
>> > > hibernate-dev mailing list -- hibernate-dev(a)lists.jboss.org
>> > > To unsubscribe send an email to hibernate-dev-leave(a)lists.jboss.org
>> > > Privacy Statement: https://www.redhat.com/en/about/privacy-policy
>> > > List Archives:
>> > >
>> >
>> https://lists.jboss.org/archives/list/hibernate-dev@lists.jboss.org/messa...
>> > >
>> > _______________________________________________
>> > hibernate-dev mailing list -- hibernate-dev(a)lists.jboss.org
>> > To unsubscribe send an email to hibernate-dev-leave(a)lists.jboss.org
>> > Privacy Statement: https://www.redhat.com/en/about/privacy-policy
>> > List Archives:
>> >
>> https://lists.jboss.org/archives/list/hibernate-dev@lists.jboss.org/messa...
>> >
>> _______________________________________________
>> hibernate-dev mailing list -- hibernate-dev(a)lists.jboss.org
>> To unsubscribe send an email to hibernate-dev-leave(a)lists.jboss.org
>> Privacy Statement: https://www.redhat.com/en/about/privacy-policy
>> List Archives:
>> https://lists.jboss.org/archives/list/hibernate-dev@lists.jboss.org/messa...
>>
>
5 months, 1 week
