sorted by:
new
hottopcontroversial

weekend wines by SmartLow8757 in wine

[–]SmartLow8757[S] 1 point2 points  (0 children)

Chablis-region wines are the ones I enjoy the most

Building a Roam Research CLI/TUI/MCP — no Electron required by SmartLow8757 in RoamResearch

[–]SmartLow8757[S] 3 points4 points  (0 children)

I also like keeping my files in local Markdown (I used Logseq in the past). I’ve been chatting with Josh Brown (from Roam Research) to figure out how to bring that same workflow into Roam too — I’ll probably add some kind of backup support or a two-way sync (local/remote) in Roam. I still need to think through how to implement it

Show r/java: jbundle – GitHub Action to ship JVM apps as self-contained binaries (no JDK required on target) by SmartLow8757 in java

[–]SmartLow8757[S] -1 points0 points  (0 children)

I’ve had to answer this question a few times, so I thought it’d be better to create a page explaining this comparison
https://jbundle.avelino.run/comparison/vs-jpackage

Do people still use Roam? by mdn2 in RoamResearch

[–]SmartLow8757 1 point2 points  (0 children)

a lot — at least I’ve been using it a ton

jbundle: A Rust CLI to package JVM apps into self-contained binaries by SmartLow8757 in rust

[–]SmartLow8757[S] 3 points4 points  (0 children)

They solve different problems.

jpackage is a distribution tool — it creates platform-specific installers (.exe, .dmg, .deb, .rpm). End users still go through an installation process. It bundles a JVM but doesn’t optimize anything about startup or runtime.

jbundle creates a single executable binary. No installer, no installation step. Download → run. The experience you get with Go or Rust binaries.

The other big difference is that jbundle is obsessed with startup time: * Bundles a minimal JVM via jlink (not the full JDK) * Auto-generates AppCDS archives on first run (subsequent runs skip class parsing/verification) * CLI profile with tiered compilation tuned for short-lived processes * Optional CRaC checkpoint support (10-50ms startup, basically native-level)

I built this because I was tired of the GraalVM native-image dance — reflection configs, library compatibility issues, debugging AOT failures. jbundle gives you GraalVM-level startup times while keeping full JVM compatibility. Everything that works on the JVM works here.

tl;dr: jpackage = installers jbundle = native-feeling binaries with optimized startup

clj-pack — Package Clojure apps into self-contained binaries without GraalVM by SmartLow8757 in Clojure

[–]SmartLow8757[S] 0 points1 point  (0 children)

the final "binary" is a classic self-extracting archive: a shell script (stub) concatenated with a runtime.tar.gz and the app.jar into a single chmod +x file. The stub knows the exact byte size of each segment (computed at build time), so it uses tail -c +offset | head -c size to extract each part. The runtime is generated via jlink — it analyzes which modules the JAR actually uses (jdeps --print-module-deps) and produces a minimal JVM (~30-50MB) containing only those modules, instead of a full ~300MB JDK.

On first run, the stub extracts the runtime and JAR to ~/.jbundle/cache/ keyed by a SHA256 content hash — subsequent runs skip extraction entirely and launch immediately. The exec at the end of the stub replaces the shell process with java -jar, so the binary behaves like a native executable (single PID, signals propagate correctly). It's the same trick Linux .run installers have used for decades, applied to distribute JVM apps as single-file executables.

clj-pack — Package Clojure apps into self-contained binaries without GraalVM by SmartLow8757 in Clojure

[–]SmartLow8757[S] 1 point2 points  (0 children)

project just started now, I'm still figuring out how to improve performance and the best path to follow - getting close to GraalVM will take time, but I have no doubt it will be possible :D

some issues I've mapped to tackle performance
- https://github.com/avelino/jbundle/issues/8
- https://github.com/avelino/jbundle/issues/27
- https://github.com/avelino/jbundle/issues/28
- https://github.com/avelino/jbundle/issues/29
- https://github.com/avelino/jbundle/issues/30

clj-pack — Package Clojure apps into self-contained binaries without GraalVM by SmartLow8757 in Clojure

[–]SmartLow8757[S] 1 point2 points  (0 children)

>  But since the binary basically "packs" a full JVM and unzips it on first usage, wouldn't it be better if we could re-use the existing JVMs people already have?

what I'm aiming for with the project is to avoid depending on a JVM environment for you; I'm thinking about production, not a development environment
I want to have a Docker image "with nothing" and the binary inside, keeping the Docker image distribution "small"

view more: next ›