How to get JAVA_HOME to resolve inside a snap?

Hello all,

I’m building a Java application that will be deployed to several channels, Snap being one of them. The application will be published as .zip and .tar.gz files attached to a GitHub release. From then on, tools such as Homebrew and Snap will download the corresponding binary, unpack and run. I’ve got a simple snap.yaml file that’s capable of downloading and unpacking *using he dump plugin) however the problem I’m facing is in the app’s launch script ( generated with Gradle’s application plugin), as it attempts to resolve the java executable using $JAVA_HOME.

Is there a way to tell a snap to consume Java from $JAVA_HOME? Or do I need to configure a particular JDK release (provided as a snap I suppose) as a dependency/plug on my Snap? I’d rather have the consumer define which JDK provider they’d like to use instead of choosing one for them, if possible.

I’m aware of the gradle and maven plugins for Snap, in this case they won’t be much help as the binary distro has already been created with time/date/git metadata that should be an exact match for all consumers from all deployment channels.


you actually need to ship the jdk with your snap … then you can point JAVA_HOME to $SNAP/path/to/your/java/interpreter

here is a very old java based snap (originally created for/on 16.04, many of these bits can be solved way more elegantly with modern snapcraft nowadays (i dont think you’d need a wrapper at all anymore)) that might give you some rough ideas:

I was hoping not to bundle a JVM as that limits the choices consumers may make in terms of JDK vendors and Java versions. Here’s for example the Groovy snap (with classic confinement)

Being in classic gives it access to the outside world, including environment variables if I understood correctly. I thought a similar configuration would be possible for strict where access to executables on the PATH (or env vars) was granted.

nope, strict confinement limits all access to the outside world from a snap, specifically executing external apps (with the exception of using xdg-open and portals to actually spawn apps outside of the snap env and handing them over the file/data)

but groovy being a programming language probably falls in a category that will just handwavy get granted classic confinement (IDEs, editors and languages have a general exception IIRC)

I see. So. If I want to deliver a Java app as a Snap then it either runs in strict mode and provides its own JVM OR runs in classic mode (which grants it access to $JAVA_HOME) however securing such confinement may be a difficult task.

That’s a shame considering I’m building a Java version of for all kinds of Java applications. JReleaser can’t take all the decisions, app developers will have to select either mode after weighting pros and cons.

well, getting classic cofinement granted for an app means it needs to undergo a review and must match certain criteria, normally apps dont really get classic …

goreleaser might fall in the IDE category though …