#graalvm — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #graalvm, aggregated by home.social.
-
We are excited that we are participating in #GSOC2026 with 3 projects:
- "Improved handling of older documents with OCR and AI-powered tools."
- "Improved #LibreOffice -JabRef integration" with one particular aspect of compatibility with other reference managers.- "Improving startup times for JabKit" by leveraging the power of #GraalVM
#javafx #jabref #academia #bibtex #TexLatex #opensource #bibliography
cc @frankdelporte @foojay -
Need Python’s #AI/ML ecosystem in a #Java service? Most teams spin up a separate #Python #Microservice. But what if the Python code ran inside the same JVM process?
Vishal Shanbhag explores this with #GraalPy on #GraalVM.See the PoC: https://javapro.io/2026/03/10/bridging-java-and-python-for-ai-ml-in-production-the-case-for-graalpy-on-graalvm/
#JAVAPRO @graalvm
-
Need Python’s #AI/ML ecosystem in a #Java service? Most teams spin up a separate #Python #Microservice. But what if the Python code ran inside the same JVM process?
Vishal Shanbhag explores this with #GraalPy on #GraalVM.See the PoC: https://javapro.io/2026/03/10/bridging-java-and-python-for-ai-ml-in-production-the-case-for-graalpy-on-graalvm/
#JAVAPRO @graalvm
-
Need Python’s #AI/ML ecosystem in a #Java service? Most teams spin up a separate #Python #Microservice. But what if the Python code ran inside the same JVM process?
Vishal Shanbhag explores this with #GraalPy on #GraalVM.See the PoC: https://javapro.io/2026/03/10/bridging-java-and-python-for-ai-ml-in-production-the-case-for-graalpy-on-graalvm/
#JAVAPRO @graalvm
-
Need Python’s #AI/ML ecosystem in a #Java service? Most teams spin up a separate #Python #Microservice. But what if the Python code ran inside the same JVM process?
Vishal Shanbhag explores this with #GraalPy on #GraalVM.See the PoC: https://javapro.io/2026/03/10/bridging-java-and-python-for-ai-ml-in-production-the-case-for-graalpy-on-graalvm/
#JAVAPRO @graalvm
-
Need Python’s #AI/ML ecosystem in a #Java service? Most teams spin up a separate #Python #Microservice. But what if the Python code ran inside the same JVM process?
Vishal Shanbhag explores this with #GraalPy on #GraalVM.See the PoC: https://javapro.io/2026/03/10/bridging-java-and-python-for-ai-ml-in-production-the-case-for-graalpy-on-graalvm/
#JAVAPRO @graalvm
-
[Перевод] Agentis Memory — Redis-совместимое хранилище со встроенным векторным поиском и локальными эмбеддингами
В наше время уже никого не удивишь разработкой агентов, очередной оптимизацией, новой моделью или новой инфраструктурой для нейронок. Всё это в порядке вещей. Однако одно дело читать в Twitter «мы написали агента X и он оптимизировал нам процессы на 300000%», и совсем другое — начать копать чуть глубже. Копнёшь — а «агентом» называют скилл с одним промптом. Разработка настоящих агентов — задача не тривиальная. Достаточно посмотреть на утёкшие исходники Claude CLI — это не просто CLI, а целая инфраструктура бизнес-логики вокруг LLM. Я бы сравнил разработку агентов с разработкой типичных бэкенд-компонентов. Аналогия такая: если вы пишете каноничный бэкенд-сервис — вам нужна СУБД. Если Web3-сервис — блокчейн. Но на СУБД или блокчейне происходит в лучшем случае 50% всей логики. Вся магия крутится именно на бэкенде. С агентами то же самое: подключаешь AI SDK, конфигурируешь мыслительное ядро и пишешь вокруг него всю обвязку — мониторинги, AIOps, оркестрацию, memory management. Вот про memory management и пойдёт речь.
https://habr.com/ru/articles/1018784/
#Redis #AI_agents #GraalVM #ONNX #embeddings #HNSW #Java_Vector_API #SIMD #Project_Loom #LLM
-
[Перевод] Agentis Memory — Redis-совместимое хранилище со встроенным векторным поиском и локальными эмбеддингами
В наше время уже никого не удивишь разработкой агентов, очередной оптимизацией, новой моделью или новой инфраструктурой для нейронок. Всё это в порядке вещей. Однако одно дело читать в Twitter «мы написали агента X и он оптимизировал нам процессы на 300000%», и совсем другое — начать копать чуть глубже. Копнёшь — а «агентом» называют скилл с одним промптом. Разработка настоящих агентов — задача не тривиальная. Достаточно посмотреть на утёкшие исходники Claude CLI — это не просто CLI, а целая инфраструктура бизнес-логики вокруг LLM. Я бы сравнил разработку агентов с разработкой типичных бэкенд-компонентов. Аналогия такая: если вы пишете каноничный бэкенд-сервис — вам нужна СУБД. Если Web3-сервис — блокчейн. Но на СУБД или блокчейне происходит в лучшем случае 50% всей логики. Вся магия крутится именно на бэкенде. С агентами то же самое: подключаешь AI SDK, конфигурируешь мыслительное ядро и пишешь вокруг него всю обвязку — мониторинги, AIOps, оркестрацию, memory management. Вот про memory management и пойдёт речь.
https://habr.com/ru/articles/1018784/
#Redis #AI_agents #GraalVM #ONNX #embeddings #HNSW #Java_Vector_API #SIMD #Project_Loom #LLM
-
[Перевод] Agentis Memory — Redis-совместимое хранилище со встроенным векторным поиском и локальными эмбеддингами
В наше время уже никого не удивишь разработкой агентов, очередной оптимизацией, новой моделью или новой инфраструктурой для нейронок. Всё это в порядке вещей. Однако одно дело читать в Twitter «мы написали агента X и он оптимизировал нам процессы на 300000%», и совсем другое — начать копать чуть глубже. Копнёшь — а «агентом» называют скилл с одним промптом. Разработка настоящих агентов — задача не тривиальная. Достаточно посмотреть на утёкшие исходники Claude CLI — это не просто CLI, а целая инфраструктура бизнес-логики вокруг LLM. Я бы сравнил разработку агентов с разработкой типичных бэкенд-компонентов. Аналогия такая: если вы пишете каноничный бэкенд-сервис — вам нужна СУБД. Если Web3-сервис — блокчейн. Но на СУБД или блокчейне происходит в лучшем случае 50% всей логики. Вся магия крутится именно на бэкенде. С агентами то же самое: подключаешь AI SDK, конфигурируешь мыслительное ядро и пишешь вокруг него всю обвязку — мониторинги, AIOps, оркестрацию, memory management. Вот про memory management и пойдёт речь.
https://habr.com/ru/articles/1018784/
#Redis #AI_agents #GraalVM #ONNX #embeddings #HNSW #Java_Vector_API #SIMD #Project_Loom #LLM
-
[Перевод] Agentis Memory — Redis-совместимое хранилище со встроенным векторным поиском и локальными эмбеддингами
В наше время уже никого не удивишь разработкой агентов, очередной оптимизацией, новой моделью или новой инфраструктурой для нейронок. Всё это в порядке вещей. Однако одно дело читать в Twitter «мы написали агента X и он оптимизировал нам процессы на 300000%», и совсем другое — начать копать чуть глубже. Копнёшь — а «агентом» называют скилл с одним промптом. Разработка настоящих агентов — задача не тривиальная. Достаточно посмотреть на утёкшие исходники Claude CLI — это не просто CLI, а целая инфраструктура бизнес-логики вокруг LLM. Я бы сравнил разработку агентов с разработкой типичных бэкенд-компонентов. Аналогия такая: если вы пишете каноничный бэкенд-сервис — вам нужна СУБД. Если Web3-сервис — блокчейн. Но на СУБД или блокчейне происходит в лучшем случае 50% всей логики. Вся магия крутится именно на бэкенде. С агентами то же самое: подключаешь AI SDK, конфигурируешь мыслительное ядро и пишешь вокруг него всю обвязку — мониторинги, AIOps, оркестрацию, memory management. Вот про memory management и пойдёт речь.
https://habr.com/ru/articles/1018784/
#Redis #AI_agents #GraalVM #ONNX #embeddings #HNSW #Java_Vector_API #SIMD #Project_Loom #LLM
-
Released version 1.0.1 of my #Native #Image #Config transformer plugin for the #Maven #Shade plugin that also deals with types defined in reachability-metadata-schema-v1.2.0.json format:
https://codeberg.org/michael-simons/native-image-config-transformer
Useful if you need to shade some stuff in your projects that comes with #GraalVM config settings.
-
Zajímá vás GraalVM? Přednáška Davida Kozáka a Petra Novotného z OpenAlt přináší přehled Oracle GraalVM a AOT kompilace pro Javu — must-watch pro každého Java vývojáře, co chce lepší výkon a moderní nástroje. Mrkněte na záznam! #GraalVM #Oracle #Java #AOT #OpenSource #OpenAlt #Konference #Czech
https://tv.pirati.cz/videos/watch/2e5ead1c-4abd-4ce4-b189-37e4f7d4eb68 -
Many #AI solutions live in #Python. Many production systems live on the #JVM. How do you connect both worlds without adding another service layer? Vishal Shanbhag shows a polyglot approach using #GraalPy.
Code & architecture: https://javapro.io/2026/03/10/bridging-java-and-python-for-ai-ml-in-production-the-case-for-graalpy-on-graalvm/
-
Many #AI solutions live in #Python. Many production systems live on the #JVM. How do you connect both worlds without adding another service layer? Vishal Shanbhag shows a polyglot approach using #GraalPy.
Code & architecture: https://javapro.io/2026/03/10/bridging-java-and-python-for-ai-ml-in-production-the-case-for-graalpy-on-graalvm/
-
Need Python’s #AI/ML ecosystem in a #Java service? Most teams spin up a separate #Python #Microservice. But what if the Python code ran inside the same JVM process?
Vishal Shanbhag explores this with #GraalPy on #GraalVM.See the PoC: https://javapro.io/2026/03/10/bridging-java-and-python-for-ai-ml-in-production-the-case-for-graalpy-on-graalvm/
#JAVAPRO @graalvm
-
Need Python’s #AI/ML ecosystem in a #Java service? Most teams spin up a separate #Python #Microservice. But what if the Python code ran inside the same JVM process?
Vishal Shanbhag explores this with #GraalPy on #GraalVM.See the PoC: https://javapro.io/2026/03/10/bridging-java-and-python-for-ai-ml-in-production-the-case-for-graalpy-on-graalvm/
#JAVAPRO @graalvm
-
Are you still using Spring over @quarkusio Are you sure you want to use native?
Think again: https://quarkus.io/blog/new-benchmarks/
And this is BEFORE Leyden, which smashes the numbers for startup time compared to native.
#java #development #software #openjdk #leyden #performance #optimization #native #springFramework #quarkus #quarkus3 #graalvm
-
Как ускорить тесты проекта в 6 раз: от 10 минут к 101 секунде
Почти 800 тестов, 10 минут на прогон, каждый пуш — ожидание на CI. Знакомо? Рассказываю, как довёл время до 101 секунды: снижение таймаутов, параллелизм ScalaTest, shared Testcontainers и защита от регрессий. Scala, SBT, PostgreSQL, GraalVM — конкретные шаги и подводные камни.
https://habr.com/ru/articles/1003592/
#scala #scalatest #testcontainers #postgresql #тестирование #оптимизация #параллелизм #sbt #graalvm #hikaricp
-
ТОП-10+1 “Золотых правил оптимизаций Java 21+: как заставить JIT петь, а GraalVM — летать”
Почему ваша Java-система буксует там, где должна летать? Мы привыкли доверять магии JVM, но в мире Java 21 и Native Image правила игры изменились. От микро-оптимизаций байт-кода до радикальной смены парадигмы с Scoped Values – разбираем 11 “золотых правил”, которые заставят JIT петь, а ваш бинарник – стартовать за миллисекунды. Никакой “воды”, только хардкор, регистры процессора и “голоса” компиляторов внутри вашего кода. Работая с кодом, я не раз ловил азарт: а как этот метод можно ускорить ещё? Какую гайку подкрутить, чтобы JVM не просто работала, а буквально летела? Что изменить в архитектуре, чтобы Native Image стал ещё компактнее, а холодный старт – ещё быстрее? Испытав этот азарт оптимизации не раз, я хочу поделиться им с вами. Я собрал квинтэссенцию своего опыта в конкретный чек-лист. Это не просто советы по стилю кода. Это “10+1 Золотых правил оптимизации Java 21+”. Это те рычаги, которые заставляют JIT-компилятор петь, а GraalVM – генерировать бинарники с хирургической точностью. Приготовьтесь! Мы начинаем оптимизировать! Начать оптимизацию!
-
-
-
-
-
-
Post-OOP Imperative Functional Java.
Model the process. Not the domain.Most Java code still asks the wrong question:
"What is this domain object?"
But production systems fail, scale, and burn because of processes, not nouns.If your system is a sequence of irreversible steps, model it as a sequence,
not as interacting objects pretending to be immortal.This follows ideas from Railway-Oriented Programming (ROP):
errors and decisions are values, not control-flow side effects.Modeling the process means you can read this top to bottom
and understand exactly what happens.
No debugger. No IDE magic. No tribal knowledge.Control flow is explicit.
You see the execution order.
Nothing hides in constructors, annotations, or overrides.Failure is a first-class concept.
Once it fails or decides early, nothing else runs.
No exception archaeology.Processes > Objects.
Real systems are workflows where refactoring is safe.Steps are reordered, removed, or replaced
without collapsing a class hierarchy.
Testing is trivial, small stepwise context — even for an AI.Feed input. Assert final result.
No mocking five layers of indirection.GraalVM / native-friendly.
No reflection rituals.
The compiler smiles.Objects are great for long-lived entities.
User actions, payments, rules, and failures are short-lived processes.I model what happens,
not what pretends to exist forever.Influenced by:
Railway-Oriented Programming,
Functional Core / Imperative Shell,
Workflow / Saga patterns,
Command pipelines,
Unix philosophy,
and value-oriented libraries like Vanilla-DI.Don't be stuck in axioms.
#PostOOP
#ImperativeFunctional
#ProcessOverObjects
#ModelTheProcess
#WorkflowFirst
#RailwayOrientedProgramming
#FunctionalCore
#ImperativeShell
#CommandPipeline
#ExplicitControlFlow
#ValueOrientedDesign
#ProcessModeling
#FailFast
#NoExceptionArchaeology
#ComposableSystems
#NativeFriendly
#GraalVM
#NoReflection
#DeterministicCode
#RefactorSafe
#SagaPattern
#UnixPhilosophy
#VanillaDI
#ModernJava
#ArchitectureMatters -
Post-OOP Imperative Functional Java.
Model the process. Not the domain.Most Java code still asks the wrong question:
"What is this domain object?"
But production systems fail, scale, and burn because of processes, not nouns.If your system is a sequence of irreversible steps, model it as a sequence,
not as interacting objects pretending to be immortal.This follows ideas from Railway-Oriented Programming (ROP):
errors and decisions are values, not control-flow side effects.Modeling the process means you can read this top to bottom
and understand exactly what happens.
No debugger. No IDE magic. No tribal knowledge.Control flow is explicit.
You see the execution order.
Nothing hides in constructors, annotations, or overrides.Failure is a first-class concept.
Once it fails or decides early, nothing else runs.
No exception archaeology.Processes > Objects.
Real systems are workflows where refactoring is safe.Steps are reordered, removed, or replaced
without collapsing a class hierarchy.
Testing is trivial, small stepwise context — even for an AI.Feed input. Assert final result.
No mocking five layers of indirection.GraalVM / native-friendly.
No reflection rituals.
The compiler smiles.Objects are great for long-lived entities.
User actions, payments, rules, and failures are short-lived processes.I model what happens,
not what pretends to exist forever.Influenced by:
Railway-Oriented Programming,
Functional Core / Imperative Shell,
Workflow / Saga patterns,
Command pipelines,
Unix philosophy,
and value-oriented libraries like Vanilla-DI.Don't be stuck in axioms.
#PostOOP
#ImperativeFunctional
#ProcessOverObjects
#ModelTheProcess
#WorkflowFirst
#RailwayOrientedProgramming
#FunctionalCore
#ImperativeShell
#CommandPipeline
#ExplicitControlFlow
#ValueOrientedDesign
#ProcessModeling
#FailFast
#NoExceptionArchaeology
#ComposableSystems
#NativeFriendly
#GraalVM
#NoReflection
#DeterministicCode
#RefactorSafe
#SagaPattern
#UnixPhilosophy
#VanillaDI
#ModernJava
#ArchitectureMatters -
Post-OOP Imperative Functional Java.
Model the process. Not the domain.Most Java code still asks the wrong question:
"What is this domain object?"
But production systems fail, scale, and burn because of processes, not nouns.If your system is a sequence of irreversible steps, model it as a sequence,
not as interacting objects pretending to be immortal.This follows ideas from Railway-Oriented Programming (ROP):
errors and decisions are values, not control-flow side effects.Modeling the process means you can read this top to bottom
and understand exactly what happens.
No debugger. No IDE magic. No tribal knowledge.Control flow is explicit.
You see the execution order.
Nothing hides in constructors, annotations, or overrides.Failure is a first-class concept.
Once it fails or decides early, nothing else runs.
No exception archaeology.Processes > Objects.
Real systems are workflows where refactoring is safe.Steps are reordered, removed, or replaced
without collapsing a class hierarchy.
Testing is trivial, small stepwise context — even for an AI.Feed input. Assert final result.
No mocking five layers of indirection.GraalVM / native-friendly.
No reflection rituals.
The compiler smiles.Objects are great for long-lived entities.
User actions, payments, rules, and failures are short-lived processes.I model what happens,
not what pretends to exist forever.Influenced by:
Railway-Oriented Programming,
Functional Core / Imperative Shell,
Workflow / Saga patterns,
Command pipelines,
Unix philosophy,
and value-oriented libraries like Vanilla-DI.Don't be stuck in axioms.
#PostOOP
#ImperativeFunctional
#ProcessOverObjects
#ModelTheProcess
#WorkflowFirst
#RailwayOrientedProgramming
#FunctionalCore
#ImperativeShell
#CommandPipeline
#ExplicitControlFlow
#ValueOrientedDesign
#ProcessModeling
#FailFast
#NoExceptionArchaeology
#ComposableSystems
#NativeFriendly
#GraalVM
#NoReflection
#DeterministicCode
#RefactorSafe
#SagaPattern
#UnixPhilosophy
#VanillaDI
#ModernJava
#ArchitectureMatters -
Post-OOP Imperative Functional Java.
Model the process. Not the domain.Most Java code still asks the wrong question:
"What is this domain object?"
But production systems fail, scale, and burn because of processes, not nouns.If your system is a sequence of irreversible steps, model it as a sequence,
not as interacting objects pretending to be immortal.This follows ideas from Railway-Oriented Programming (ROP):
errors and decisions are values, not control-flow side effects.Modeling the process means you can read this top to bottom
and understand exactly what happens.
No debugger. No IDE magic. No tribal knowledge.Control flow is explicit.
You see the execution order.
Nothing hides in constructors, annotations, or overrides.Failure is a first-class concept.
Once it fails or decides early, nothing else runs.
No exception archaeology.Processes > Objects.
Real systems are workflows where refactoring is safe.Steps are reordered, removed, or replaced
without collapsing a class hierarchy.
Testing is trivial, small stepwise context — even for an AI.Feed input. Assert final result.
No mocking five layers of indirection.GraalVM / native-friendly.
No reflection rituals.
The compiler smiles.Objects are great for long-lived entities.
User actions, payments, rules, and failures are short-lived processes.I model what happens,
not what pretends to exist forever.Influenced by:
Railway-Oriented Programming,
Functional Core / Imperative Shell,
Workflow / Saga patterns,
Command pipelines,
Unix philosophy,
and value-oriented libraries like Vanilla-DI.Don't be stuck in axioms.
#PostOOP
#ImperativeFunctional
#ProcessOverObjects
#ModelTheProcess
#WorkflowFirst
#RailwayOrientedProgramming
#FunctionalCore
#ImperativeShell
#CommandPipeline
#ExplicitControlFlow
#ValueOrientedDesign
#ProcessModeling
#FailFast
#NoExceptionArchaeology
#ComposableSystems
#NativeFriendly
#GraalVM
#NoReflection
#DeterministicCode
#RefactorSafe
#SagaPattern
#UnixPhilosophy
#VanillaDI
#ModernJava
#ArchitectureMatters -
Post-OOP Imperative Functional Java.
Model the process. Not the domain.Most Java code still asks the wrong question:
"What is this domain object?"
But production systems fail, scale, and burn because of processes, not nouns.If your system is a sequence of irreversible steps, model it as a sequence,
not as interacting objects pretending to be immortal.This follows ideas from Railway-Oriented Programming (ROP):
errors and decisions are values, not control-flow side effects.Modeling the process means you can read this top to bottom
and understand exactly what happens.
No debugger. No IDE magic. No tribal knowledge.Control flow is explicit.
You see the execution order.
Nothing hides in constructors, annotations, or overrides.Failure is a first-class concept.
Once it fails or decides early, nothing else runs.
No exception archaeology.Processes > Objects.
Real systems are workflows where refactoring is safe.Steps are reordered, removed, or replaced
without collapsing a class hierarchy.
Testing is trivial, small stepwise context — even for an AI.Feed input. Assert final result.
No mocking five layers of indirection.GraalVM / native-friendly.
No reflection rituals.
The compiler smiles.Objects are great for long-lived entities.
User actions, payments, rules, and failures are short-lived processes.I model what happens,
not what pretends to exist forever.Influenced by:
Railway-Oriented Programming,
Functional Core / Imperative Shell,
Workflow / Saga patterns,
Command pipelines,
Unix philosophy,
and value-oriented libraries like Vanilla-DI.Don't be stuck in axioms.
#PostOOP
#ImperativeFunctional
#ProcessOverObjects
#ModelTheProcess
#WorkflowFirst
#RailwayOrientedProgramming
#FunctionalCore
#ImperativeShell
#CommandPipeline
#ExplicitControlFlow
#ValueOrientedDesign
#ProcessModeling
#FailFast
#NoExceptionArchaeology
#ComposableSystems
#NativeFriendly
#GraalVM
#NoReflection
#DeterministicCode
#RefactorSafe
#SagaPattern
#UnixPhilosophy
#VanillaDI
#ModernJava
#ArchitectureMatters -
Spring Boot or Quarkus? Thymeleaf or Qute?
If you’re planning your next Java migration, this one’s for you.
A deep architectural dive into how build-time safety, native images, and developer experience reshape server-side templating.
https://www.the-main-thread.com/p/spring-boot-to-quarkus-qute-migration-guide#Java #Quarkus #SpringBoot #Qute #Thymeleaf #GraalVM #CloudNative
-
Spring Boot or Quarkus? Thymeleaf or Qute?
If you’re planning your next Java migration, this one’s for you.
A deep architectural dive into how build-time safety, native images, and developer experience reshape server-side templating.
https://www.the-main-thread.com/p/spring-boot-to-quarkus-qute-migration-guide#Java #Quarkus #SpringBoot #Qute #Thymeleaf #GraalVM #CloudNative
-
Spring Boot or Quarkus? Thymeleaf or Qute?
If you’re planning your next Java migration, this one’s for you.
A deep architectural dive into how build-time safety, native images, and developer experience reshape server-side templating.
https://www.the-main-thread.com/p/spring-boot-to-quarkus-qute-migration-guide#Java #Quarkus #SpringBoot #Qute #Thymeleaf #GraalVM #CloudNative
-
Spring Boot or Quarkus? Thymeleaf or Qute?
If you’re planning your next Java migration, this one’s for you.
A deep architectural dive into how build-time safety, native images, and developer experience reshape server-side templating.
https://www.the-main-thread.com/p/spring-boot-to-quarkus-qute-migration-guide#Java #Quarkus #SpringBoot #Qute #Thymeleaf #GraalVM #CloudNative
-
Spring Boot or Quarkus? Thymeleaf or Qute?
If you’re planning your next Java migration, this one’s for you.
A deep architectural dive into how build-time safety, native images, and developer experience reshape server-side templating.
https://www.the-main-thread.com/p/spring-boot-to-quarkus-qute-migration-guide#Java #Quarkus #SpringBoot #Qute #Thymeleaf #GraalVM #CloudNative
-
Wow. That is disappointing. Is that also going to be the end of #JVMCI?
https://blogs.oracle.com/java/post/detaching-graalvm-from-the-java-ecosystem-train
-
I got nerd sniped, so here is my new #java side-project:
jdtfmt - a Java #formatter for the command line.
* Can be paired with #spotless (both use jdt).
* fast (native via GraalVM)https://github.com/bmarwell/jdtfmt
Thanks to @jqno for the inspiration, @mthmulders for #graalvm hints and @bdemers for encouraging me to actually do the project! 😀
-
What do HotSpot, Loom & Garbage have in common? More than you think. Ingo Düppe mapped the #Java galaxy — from 1995 to tomorrow.
Ever read #JVM history that’s actually fun? Time to catch up: https://javapro.io/2025/04/07/hitchhikers-guide-to-java-performance/
-
Running #Java in the cloud once felt impossible—slow startups, memory bloat, clunky deploys. Then came #GraalVM, #NativeImages & reactive #Frameworks.
Mihaela Gheorghe-Roman connects the dots.For anyone who gave up on Java too early: https://javapro.io/2025/05/22/java-through-the-decades-from-applets-to-microservices/
#Applets #SpringBoot -
1995: #Java is slow.
2025: Java is almost too fast to comprehend.
Join @javacoding on a #Performance journey through 30 years of #JVM evolution.How did Java get this fast? Find out here:
https://javapro.io/2025/04/07/hitchhikers-guide-to-java-performance/ -
1995: #Java is slow.
2025: Java is almost too fast to comprehend.
Join @javacoding on a #Performance journey through 30 years of #JVM evolution.How did Java get this fast? Find out here:
https://javapro.io/2025/04/07/hitchhikers-guide-to-java-performance/ -
Früher: „Java ist zu langsam.“
Heute: „Wait, Java kann das?“Ingo Düppe klärt auf – Performance ist mehr als nur Geschwindigkeit! Weißt du, was heute wirklich in deiner #JVM steckt?
Lese jetzt: https://javapro.io/de/hitchhikers-guide-to-java-performance/ -
#JVM, GC, Loom, #ZGC. Wer denkt, Java ist oldschool, kennt den Artikel von @javacoding nicht. Wie modern ist deine Sicht auf Java wirklich?
👉 Jetzt nachlesen - könnte überraschen: https://javapro.io/de/hitchhikers-guide-to-java-performance/
-
🚀 New Release: API-Doc-Crafter just got sharper. Cleaner. Meaner.
Giving my little OpenAPI merging monster some upgrades.It all started with a simple idea: merge OpenAPI specs from multiple repos.
Now? It transforms outdated Swagger specs to OpenAPI 3+, generates HTML pages with full navigation, and allows customization via config or env.✨ SecurityRequirement deduplication - because why merge APIs if you can't also merge logic?
🧠 Custom metadata enrichment - inject your info, license, contact, and docs straight from config. No more excuses.
🔁 Better parser fallback - now tries more ways to read broken specs than your average intern in panic mode.
🎭 Variable substitution in outputs - ${variables} be gone. Use env or config, stay DRY, stay sane.
🧪 Tests expanded. HTML, JSON, YAML outputs covered like a nuclear bunker.
🧰 Powered by GraalVM, no reflection, blazing fast.
🐳 Native Docker builds.
🧼 Reflection config surgically trimmed. Less bloat. More edge.Project: https://github.com/YunaBraska/api-doc-crafter
Happy crafting. And remember: if your docs aren't automated, they're probably lies.#OpenAPI #Swagger #APIdocumentation #DevTools #GraalVM #Java21 #Docker #Automation #CleanCode #DevLife #APIDocs #OpenSource #DeveloperTools #coding #programming
-
Back then: “ Java is too slow.”
Now: “Wait, #Java can do that?”
Ingo Düppe explains why #Performance is more than just speed.Do you know what’s really under the hood of your #JVM today?
👉 Read now: https://javapro.io/2025/04/07/hitchhikers-guide-to-java-performance/#JavaConcurrency #GraalVM #ProjectLoom #GarbageCollection #ZGC
-
#JVM, GC, Loom, #ZGC. Think Java is oldschool? Then you haven’t met Ingo Düppe.
How modern is your view of Java, really? Read " Hitchhiker’s Guide to #Java #Performance "
👉 You might be surprised: https://javapro.io/2025/04/07/hitchhikers-guide-to-java-performance/ -
Was haben HotSpot, Loom & Garbage gemeinsam? Mehr als du denkst! Ingo Düppe hat die Java-Galaxie kartiert – von 1995 bis morgen. Schon mal #JVM-Geschichte gelesen, die Spaß macht? Hier nachholen: https://javapro.io/de/hitchhikers-guide-to-java-performance/
-
Java Is Becoming a Monster (And I Love It)
I used to think Java was done. Stale. Verbose. A relic.
But now? It mutated. It spawns 5000 virtual threads like it’s nothing.I just built a REST service:
✅ Runs on virtual threads
✅ Functional pipelines
✅ Only a few MB RAM
✅ No thread-pools
✅ No leaks
✅ Pure JVMThis isn't Java 8 anymore.
✨ No Groovy. No Kotlin. No detours.
Java is now useful and gets Beautiful.And then there’s GraalVM:
If you skip reflection and runtime init, you get:
⚡ Native executables
⚡ Instant startup
⚡ Tiny memory
⚡ No runtime surprisesGame. Changed.
But OSS frameworks?
Still look frozen in 2015.
Heavy, reflective, runtime-hacked monsters.So I built my own tools:
🔥 TypeMap
→ Zero-reflection json/xlm reader & type converter
→ GraalVM native
→ Fast. Simple. Functional.
https://github.com/YunaBraska/type-map⚔️ Nano
→ Anti-framework
→ Static main, no DI magic
→ Pure, clean design
https://github.com/NanoNative/nano🧪 Nano example app
➡️ One single static main file
https://github.com/YunaBraska/nano-graalvm-example🛠 API-Doc-Crafter
➡️ Native CLI doc tool
https://github.com/YunaBraska/api-doc-crafter🧭 My Java Functional Guidelines
https://devabyss.hashnode.dev/java-functional-guidelinesJava isn't just catching up.
It’s setting the pace now.The only question is:
Can frameworks and libraries keep up?#Java #GraalVM #VirtualThreads #FunctionalProgramming #JVM #ModernJava #coding #Programming
-
Java Is Becoming a Monster (And I Love It)
I used to think Java was done. Stale. Verbose. A relic.
But now? It mutated. It spawns 5000 virtual threads like it’s nothing.I just built a REST service:
✅ Runs on virtual threads
✅ Functional pipelines
✅ Only a few MB RAM
✅ No thread-pools
✅ No leaks
✅ Pure JVMThis isn't Java 8 anymore.
✨ No Groovy. No Kotlin. No detours.
Java is now useful and gets Beautiful.And then there’s GraalVM:
If you skip reflection and runtime init, you get:
⚡ Native executables
⚡ Instant startup
⚡ Tiny memory
⚡ No runtime surprisesGame. Changed.
But OSS frameworks?
Still look frozen in 2015.
Heavy, reflective, runtime-hacked monsters.So I built my own tools:
🔥 TypeMap
→ Zero-reflection json/xlm reader & type converter
→ GraalVM native
→ Fast. Simple. Functional.
https://github.com/YunaBraska/type-map⚔️ Nano
→ Anti-framework
→ Static main, no DI magic
→ Pure, clean design
https://github.com/NanoNative/nano🧪 Nano example app
➡️ One single static main file
https://github.com/YunaBraska/nano-graalvm-example🛠 API-Doc-Crafter
➡️ Native CLI doc tool
https://github.com/YunaBraska/api-doc-crafter🧭 My Java Functional Guidelines
https://devabyss.hashnode.dev/java-functional-guidelinesJava isn't just catching up.
It’s setting the pace now.The only question is:
Can frameworks and libraries keep up?#Java #GraalVM #VirtualThreads #FunctionalProgramming #JVM #ModernJava #coding #Programming
-
Java Is Becoming a Monster (And I Love It)
I used to think Java was done. Stale. Verbose. A relic.
But now? It mutated. It spawns 5000 virtual threads like it’s nothing.I just built a REST service:
✅ Runs on virtual threads
✅ Functional pipelines
✅ Only a few MB RAM
✅ No thread-pools
✅ No leaks
✅ Pure JVMThis isn't Java 8 anymore.
✨ No Groovy. No Kotlin. No detours.
Java is now useful and gets Beautiful.And then there’s GraalVM:
If you skip reflection and runtime init, you get:
⚡ Native executables
⚡ Instant startup
⚡ Tiny memory
⚡ No runtime surprisesGame. Changed.
But OSS frameworks?
Still look frozen in 2015.
Heavy, reflective, runtime-hacked monsters.So I built my own tools:
🔥 TypeMap
→ Zero-reflection json/xlm reader & type converter
→ GraalVM native
→ Fast. Simple. Functional.
https://github.com/YunaBraska/type-map⚔️ Nano
→ Anti-framework
→ Static main, no DI magic
→ Pure, clean design
https://github.com/NanoNative/nano🧪 Nano example app
➡️ One single static main file
https://github.com/YunaBraska/nano-graalvm-example🛠 API-Doc-Crafter
➡️ Native CLI doc tool
https://github.com/YunaBraska/api-doc-crafter🧭 My Java Functional Guidelines
https://devabyss.hashnode.dev/java-functional-guidelinesJava isn't just catching up.
It’s setting the pace now.The only question is:
Can frameworks and libraries keep up?#Java #GraalVM #VirtualThreads #FunctionalProgramming #JVM #ModernJava #coding #Programming
-
Java Is Becoming a Monster (And I Love It)
I used to think Java was done. Stale. Verbose. A relic.
But now? It mutated. It spawns 5000 virtual threads like it’s nothing.I just built a REST service:
✅ Runs on virtual threads
✅ Functional pipelines
✅ Only a few MB RAM
✅ No thread-pools
✅ No leaks
✅ Pure JVMThis isn't Java 8 anymore.
✨ No Groovy. No Kotlin. No detours.
Java is now useful and gets Beautiful.And then there’s GraalVM:
If you skip reflection and runtime init, you get:
⚡ Native executables
⚡ Instant startup
⚡ Tiny memory
⚡ No runtime surprisesGame. Changed.
But OSS frameworks?
Still look frozen in 2015.
Heavy, reflective, runtime-hacked monsters.So I built my own tools:
🔥 TypeMap
→ Zero-reflection json/xlm reader & type converter
→ GraalVM native
→ Fast. Simple. Functional.
https://github.com/YunaBraska/type-map⚔️ Nano
→ Anti-framework
→ Static main, no DI magic
→ Pure, clean design
https://github.com/NanoNative/nano🧪 Nano example app
➡️ One single static main file
https://github.com/YunaBraska/nano-graalvm-example🛠 API-Doc-Crafter
➡️ Native CLI doc tool
https://github.com/YunaBraska/api-doc-crafter🧭 My Java Functional Guidelines
https://devabyss.hashnode.dev/java-functional-guidelinesJava isn't just catching up.
It’s setting the pace now.The only question is:
Can frameworks and libraries keep up?#Java #GraalVM #VirtualThreads #FunctionalProgramming #JVM #ModernJava #coding #Programming