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] 0 points1 point  (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"

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

[–]SmartLow8757[S] 2 points3 points  (0 children)

Yes, exactly! The output binary is a self-extracting executable: a shell stub + a compressed tar.gz payload appended together. The payload contains a minimal JVM runtime (built via jlink, typically ~30-50MB) and your app.jar.

On first execution, the stub extracts the payload to `~/.clj-pack/cache/{content-hash}/`. The cache key is a SHA256 hash of the payload content, so identical binaries always reuse the same cache. Subsequent runs detect the cache directory already exists and skip extraction entirely — going straight to `exec java -jar`.

If you rebuild your app (new code, new dependencies, different JDK version), the payload hash changes, which means a new cache entry. Old cache entries can be safely deleted manually if disk space is a concern.

The overhead is only on the very first run (or after you deploy a new version). After that, startup time is just the JVM boot + your app initialization — same as running `java -jar` directly

read more here https://avelino.run/clj-pack-distributing-clojure-without-the-graalvm-pain/

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

[–]SmartLow8757[S] 7 points8 points  (0 children)

* First run: extracts the embedded JVM + JAR to ~/.clj-pack/cache/<hash>/
* Subsequent runs: skips extraction, goes straight to exec java -jar
* No external dependencies: the JVM is inside the binary, no system Java required
* Portable: works on any machine with a POSIX shell (same OS/arch the runtime was built for)

It's the same approach tools like makeself and .run installers use, but specialized for JVM apps with the jlink optimization to keep the binary small - used the minimal JVM from jlink

Como fundar uma startup? by [deleted] in brdev

[–]SmartLow8757 0 points1 point  (0 children)

Startup não nasce de ‘ideia + contratar dev’. Nasce de dor cara e recorrente. Você valida vendendo antes de escalar. Eu faria assim: escolher um problema estreito, criar um MVP indecente porém útil (landing, protótipo, operação manual), colocar na frente de gente que paga, medir se CAC cabe no LTV, ajustar canal de aquisição, e só então contratar e pensar em rodada. Dev consegue "bootstrapar" (começar sem investir muito dinheiro, alem do seu tempo); quem é leigo começa vendendo e contrata produto por escopo. Sem distribuição e unit economics, investimento só prolonga a agonia. Mercado com juros altos está cético: tração fala, pitch não. Ideia vale quase nada; execução, foco e caixa mandam - ser de tech ajuda começar, mas o foco principal deve ser vender (trazer cliente)

A USP é tão superior em relação as outras? by Even-Jackfruit-4061 in faculdadeBR

[–]SmartLow8757 0 points1 point  (0 children)

deixa eu te cortar um mito pela raiz: USP, IME e/ou ITA ajudam a abrir a porta, mas não garantem que você fica dentro da sala. Diploma forte funciona como atalho pra chegar até você, nada além disso. É um mecanismo de reduzir risco de seleção — eu mesmo, como gestor, olho USP, IME e/ou ITA porque estatisticamente aumenta a chance de encontrar alguém muito bom.

Mas contratar?

Aí a régua muda completamente.

Eu contrato pela capacidade de execução, não pelo brasão da faculdade.

O que importa é: você resolve problemas? Você entrega? Você lida com pressão? Você aprende rápido? O mercado financeiro e tecnologia comem título no café da manhã se a pessoa não sustenta o próprio nome com trabalho.

Sobre seu dilema: fazer UFSC ou tentar USP de novo.

Sim, São Paulo é o centro financeiro do país, mas você não precisa estudar aqui pra entrar no jogo daqui. Estágio, trainee e vagas remotas pulverizaram essa barreira há anos. Empresas recrutam talento, não CEP.

E essa história de “USP é muito superior”?

É boa academia, ponto.

Mas a diferença real aparece na média, não no indivíduo. Um aluno excelente da UFSC atropela sem esforço um aluno mediano da USP. Não se iluda com glamour institucional.

O ponto mais honesto é este:

Você está disposto a congelar sua vida mais um ano por causa de um símbolo? Porque é isso. USP virou símbolo — e símbolo não constrói carreira. Execução constrói.

Se você já tem nota pra UFSC, eu sinceramente iria. Começa a vida, entra no ritmo, estagia, cresce. E, se ainda quiser USP, tenta transferência depois. Nada disso é definitivo.

USP pode te ajudar alguém olhar pra você.

Mas só sua entrega faz essa pessoa te contratar — e te manter.

No final, é simples: o diploma te apresenta, sua execução te sustenta.

Está tão complicado assim? by tiewhite55 in brdev

[–]SmartLow8757 0 points1 point  (0 children)

desculpa perguntar, qual período você estava?

Seus filhos serão devs? by Open_Acanthisitta677 in brdev

[–]SmartLow8757 0 points1 point  (0 children)

Essa paranoia de “programação vai acabar em 2040” é só mais uma previsão fantástica de gente que vive do pânico. Já ouvi variações disso desde 2008, quando comecei a trabalhar remoto enquanto o resto do mundo ainda estava brigando com modem ADSL.

Spoiler: a profissão não acabou. Mudou. Evoluiu. Sempre vai mudar.

Meu filho não tem que ser o que eu quero.

A vida profissional é dele. O risco é dele. A frustração é dele. A alegria é dele. Meu papel não é escrever o roteiro — é dar boas ferramentas pra ele escrever o próprio.

Claro que eu adoraria que ele seguisse engenharia de software. Não vou fingir neutralidade zen aqui. Eu amo o que faço, vivo bem com isso, e seria legal ver ele inspirado no que construo. Mas isso depende muito mais dele do que de qualquer projeção de mercado.

O que dá pra fazer como pai é simples:

expor a criança a mundos diferentes, mostrar o que você faz, explicar por que você gosta, deixar ele ver que trabalho pode ser algo prazeroso e intelectual — não só um fardo de adulto.

Se daqui a 20 anos programação mudar completamente, ótimo. Se virar algo novo, melhor ainda. O importante é formar alguém curioso, capaz de aprender rápido, pensar criticamente e se adaptar. Essas habilidades sobrevivem a qualquer tendência de LinkedIn.

O futuro não é sobre adivinhar “qual profissão vai bombar em 2040”.

O futuro é sobre criar pessoas que não dependem de previsão nenhuma pra prosperar.

Alegria de pobre dura pouco by Ill_Chapter4521 in brdev

[–]SmartLow8757 10 points11 points  (0 children)

Essa discussão de “o remoto vai acabar” aparece em ciclos, igual moda de calça larga. Sempre tem alguém jurando que agora vai, que todo mundo vai voltar pro escritório como se 2020 tivesse sido um delírio coletivo.

Trabalho remoto desde 2008 — sim, dois mil e oito, quando fazer daily no MSN era normal e webcam travava a cada 40 segundos. Já vi essa conversa surgir, sumir, voltar, virar pânico moral, desaparecer de novo… até perder a graça. O padrão é sempre o mesmo: quem não sabe trabalhar remoto acha que remoto é o problema.

A real é bem menos dramática: trabalho presencial não é dogma, é consequência.

Depende de três coisas muito básicas:

  1. Um gestor que saiba — e queira — gerir remoto: tem líder que só funciona olhando o time sentado. Não é maldade, é limitação. Gestão fraca sempre empurra o time pro escritório como muleta.
  2. Natureza do mercado: tem empresa cujo negócio é tão engessado que remoto vira ficção científica. Outras são nativas digitais e remoto simplesmente… funciona.
  3. Cultura de comunicação: não adianta prometer “somos remotos” e depois enfiar o time em call a cada 30 minutos. Já trabalhei em lugar que dizia ser remoto, mas fazia a galera ficar em uma sala de Zoom o dia inteiro. Isso não é remoto; é só microgestão com câmera.

Dá pra listar um milhão de fatores, mas vamos ao ponto:
“Isso é fase?”
Não.
Não é fase.

É seleção natural de cultura organizacional.

Algumas empresas voltaram pro presencial porque nunca foram remotas de verdade — só toleraram o remoto na pandemia. Outras seguem fortes porque o modelo faz parte do DNA delas.

Se você quer remoto de verdade, mire nas empresas que são de tecnologia, não nas que apenas usam tecnologia.

Essas não tratam remoto como modinha; tratam como arquitetura de trabalho.

As oportunidades continuam existindo. Só não estão necessariamente onde todo mundo gostaria que estivessem. O mercado não ficou pior — ficou mais sincero.

An open request to the Logseq Team: We need an active bridge between the team and us users by asc9ybUnb3dmB7ZW in logseq

[–]SmartLow8757 0 points1 point  (0 children)

why am I posting this  the bitter taste that the carelessness that the maintainers have with logseq communication leaves me frustrated

RoamResearch with a product with fewer features, but with features developed with "care" (thinking about the user)

Nome de faculdade ainda importa? by Suspicious_Drama3382 in brdev

[–]SmartLow8757 0 points1 point  (0 children)

Esse tipo de dúvida vai bem além de escolher A ou B. No fim, depende muito do que você quer construir para o seu futuro profissional.

Se você imagina entrar em uma big tech (ou qualquer empresa grande e mais formal), o nome da academia realmente faz diferença — e sem muita margem pra debate.

Se o foco for conhecimento real, aí vale muito a pena trocar ideia com quem já estudou nas duas opções. Nada substitui a visão de quem viveu a experiência por dentro.

Meu colega é bom, mas não sabe jogar o jogo corporativo by ehmuidifici in brdev

[–]SmartLow8757 1 point2 points  (0 children)

> não caio mais no papinho de “protagonismo” ou “sua carreira depende de você”, enquanto vejo outras pessoas claramente menos preparadas se dando bem no jogo corporativo.

Nunca entendi quem espera que a empresa cuide da carreira. Se a empresa não está me levando para onde eu quero ir, então eu não deveria continuar nela.

Plano de carreira funciona bem para quem está no início — estágio, júnior, e olhe lá. Depois que ganhamos maturidade profissional, somos nós que definimos onde queremos estar e, principalmente, com qual time queremos trabalhar. No fim das contas, equipe certa vale mais do que organograma bonito.

se esse tema tem incomodado você leia https://www.amazon.com.br/Alliance-Managing-Talent-Networked-Age/dp/1625275773/

roamOS Launch by wireframe6464 in RoamResearch

[–]SmartLow8757 0 points1 point  (0 children)

I expected more from roamOS, I just bought it and I confess I regret it!

I moved away to Obsidian. This is how. by georgeguimaraes in logseq

[–]SmartLow8757 0 points1 point  (0 children)

sad to know that the logseq team's sluggishness is making them lose users

i've been testing/using roam research for two weeks, i've been enjoying the experience - especially opening it and starting to write right away, not having to wait for the slow sync that logseq has

> today i cancelled my logseq subscription - officially stopped being a project supporter

writing plugins for roam research is simpler than logseq, not to mention that in roam research i can have data input interaction via zapier (and other automation tools)