Skip to content

HHH-14082 Hibernate cannot determine its core version in modular configuration #10726

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

HHH-14082 Hibernate cannot determine its core version in modular configuration #10726

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 3 additions & 2 deletions hibernate-core/src/main/java/org/hibernate/Version.java
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -8,6 +8,7 @@
import org.hibernate.internal.build.AllowSysOut;

import java.lang.invoke.MethodHandles;
import java.lang.module.ModuleDescriptor;

import static org.jboss.logging.Logger.getMessageLogger;

Expand All @@ -21,8 +22,8 @@ public final class Version {
private static final String VERSION = initVersion();

private static String initVersion() {
final String version = Version.class.getPackage().getImplementationVersion();
return version != null ? version : "[WORKING]";
ModuleDescriptor moduleDescriptor = Version.class.getModule().getDescriptor() ;
return moduleDescriptor != null ? (moduleDescriptor.version().isPresent() ? moduleDescriptor.version().toString() : "[WORKING]") : "[WORKING]";
Comment on lines -24 to +26
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should there be a fallback to getPackage().getImplementationVersion() somewhere here?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was going to suggest that maybe we could do something similar to this version injection into bytecode as it's done for Search e.g. here:

https://github.com/hibernate/hibernate-search/blob/6490598a0ee5895520a5915e53fe4d7af52abed7/engine/pom.xml#L44-L60

But then I notice that there already seems to be an injection gradle plugin:

hibernate-orm/build.gradle

Line 22 in 9361a1b

id "org.hibernate.build.version-injection" version "2.0.0" apply false

Maybe we should just make sure that the plugin is used in this case?

(cc7c7d7 this commit might be related as it seems it "removes" the injection part?)

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should there be a fallback to getPackage().getImplementationVersion() somewhere here?

Hello Gavin,

Ok, I will look through. Thanks.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should there be a fallback to getPackage().getImplementationVersion() somewhere here?

Hello @gavinking,

Is it better to check getPackage() and getImplementationVersion() or to inject "org.hibernate.build.version-injection" in gradle? Which one do you recommend?

Thanks

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mehmetali2003 I don't know.

Copy link
Member

@Sanne Sanne Aug 15, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(cc7c7d7 this commit might be related as it seems it "removes" the injection part?)

It's been a while, but I don't think the intent was to remove the bytecode injection part. I think the intent was to make sure the constant would be initialized as a "real constant" when running the native-image compiler.

So I suspect we simply never noticed that the bytecode injection had stopped working, as Version.class.getPackage().getImplementationVersion() has been effective enough (until today..)

+1 to restore the bytecode injection. Perhaps we should do it in such a way to actually cause a hard-failure when it fails, so to notice such defects earlier.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmmm so it seems the plugin is just disabled and not configured at the moment 😖

We'd need at minimum:

versionInjection {
    into( 'org.hibernate.Version', 'initVersion' )
}

as an injection plugin config, then

id "org.hibernate.build.version-injection" apply true

actually enable the plugin for the core module (it is disabled in one of the more common build files)

aaaand we'd also need a new release of the plugin... with the current version it is failing with the serialisation exception (+ it won't find the method as it's private so another tiny change to the plugin is needed). I have a fix locally, but looking at the plugin repository, we'd need to update its release process first 🙂 ,

with all that in place, it renders the following version class:

public final class Version {
    private static final String VERSION = initVersion();

    private static String initVersion() {
        return "7.1.1-SNAPSHOT";
    }

    private Version() {
    }

    public static String getVersionString() {
        return VERSION;
    }

    public static void logVersion() {
        ((CoreMessageLogger)Logger.getMessageLogger(MethodHandles.lookup(), CoreMessageLogger.class, Version.class.getName())).version(getVersionString());
    }

    @AllowSysOut
    public static void main(String[] args) {
        System.out.println("Hibernate ORM core version " + getVersionString());
    }
}

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@marko-bekhta But is all this actually better than just using the features that are built into Java?

}

private Version() {
Expand Down