New feature, improvement proposal
I’m relatively new to Java beyond basic “Hello World” level.
Years ago, when I only knew shell scripting, I attempted to learn Java without guidance. I quickly realized it is not just a language—it has an enormous ecosystem. At the time, I worked in outsourcing, earning very little and often working 16 hours a day just to survive.
I needed stable employment, so I chose Python instead. I taught myself Python in a month and escaped outsourcing. That experience made me deeply appreciate simple, practical tools that help developers survive and grow.
First, I want to express my sincere admiration for Maven.
I deeply respect its “convention over configuration” philosophy: simple, stable, predictable. That is precisely why I am proposing ideas to Maven, not other tools. I honestly struggle with Gradle’s complexity and prefer Maven’s clarity and stability. I want to see Maven remain dominant in the Java ecosystem.
Today, millions of Java developers and enterprise teams want to adopt cloud-native practices: smaller runtime size, faster startup, more efficient deployment.
However, the ecosystem currently focuses heavily on AOT and native image as the primary solutions.
While AOT delivers impressive startup and footprint improvements, it has a critical downside:
it breaks backward compatibility for most existing enterprise applications.
Dynamic features like reflection, proxies, service loaders, classpath scanning, and many third-party libraries often require heavy refactoring to work with AOT.
For mature, business-critical legacy systems, this level of change is often too risky, costly, or simply impractical.
Meanwhile, countless stable, long-lived Java applications cannot tolerate disruption but still want modern lightweight distribution.
These teams do not need native images.
They need a low-risk, fully compatible way to shrink the JVM runtime without rewriting code.
This is where Maven can deliver an industry-leading solution:
provide built-in, out-of-the-box automation for jdeps dependency analysis and jlink runtime trimming.
To realize this vision, we also need a new wave of lightweight frameworks and tools with fewer dependencies, simpler models, and better static-analysis friendliness.
The biggest opportunity is this:
Once Maven provides a standard, easy-to-use minimal runtime packaging mechanism, the entire Java ecosystem will see an explosion of new lightweight frameworks, starters, libraries, and tooling.
New projects, microservices, and applications built on these slim foundations will become extremely popular.
Developers will create small, efficient production-ready services without traditional Java bloat, without AOT pain, and without sacrificing compatibility.
Many details remain to be refined:
more reliable dependency analysis, better handling of dynamic classes, leaner conventions, and tools that work out of the box.
Future JDK versions could go even further by modularizing and separating GC implementations, allowing developers to include only the GC they need.
Combined with automatic jlink trimming, this would produce extremely slim, production-ready JVMs: small, predictable, fully standard, and without AOT drawbacks.
With Java’s massive existing developer base, once these pieces align,
the Java ecosystem will experience a new wave of growth, innovation, and cloud-native adoption.
The end result would be revolutionary:
- Fully standard Java, no ecosystem fragmentation
- Tiny footprint comparable to Go binaries
- Zero code refactoring for existing applications
- Complete backward compatibility
- Mature tooling, debugging, and observability
This can be implemented as an optional opt-in feature with full fallback to original safe behavior.
Teams can experiment safely; if anything breaks, they simply turn it off.
Low risk, high reward — exactly what Java needs to unlock a new lightweight ecosystem.
In short:
We gain all the deployment benefits of Go without abandoning the Java ecosystem.
Java can compete directly with Go in the cloud while retaining scalability, libraries, and enterprise maturity.
For Maven, this is a once-in-a-decade strategic opportunity.
By owning the full toolchain for lightweight, compatible Java delivery, Maven can secure its leadership, retain enterprise users, win back teams lost to other build tools, and help Java outcompete Go in the cloud-native era.
This is how Java should do cloud-native:
without compromise, without disruption, and without losing its soul.
I’m not an experienced Java developer, but I care deeply about Java’s future in cloud-native.
I hope this idea can spark useful discussion.
New feature, improvement proposal
I’m relatively new to Java beyond basic “Hello World” level.
Years ago, when I only knew shell scripting, I attempted to learn Java without guidance. I quickly realized it is not just a language—it has an enormous ecosystem. At the time, I worked in outsourcing, earning very little and often working 16 hours a day just to survive.
I needed stable employment, so I chose Python instead. I taught myself Python in a month and escaped outsourcing. That experience made me deeply appreciate simple, practical tools that help developers survive and grow.
First, I want to express my sincere admiration for Maven.
I deeply respect its “convention over configuration” philosophy: simple, stable, predictable. That is precisely why I am proposing ideas to Maven, not other tools. I honestly struggle with Gradle’s complexity and prefer Maven’s clarity and stability. I want to see Maven remain dominant in the Java ecosystem.
Today, millions of Java developers and enterprise teams want to adopt cloud-native practices: smaller runtime size, faster startup, more efficient deployment.
However, the ecosystem currently focuses heavily on AOT and native image as the primary solutions.
While AOT delivers impressive startup and footprint improvements, it has a critical downside:
it breaks backward compatibility for most existing enterprise applications.
Dynamic features like reflection, proxies, service loaders, classpath scanning, and many third-party libraries often require heavy refactoring to work with AOT.
For mature, business-critical legacy systems, this level of change is often too risky, costly, or simply impractical.
Meanwhile, countless stable, long-lived Java applications cannot tolerate disruption but still want modern lightweight distribution.
These teams do not need native images.
They need a low-risk, fully compatible way to shrink the JVM runtime without rewriting code.
This is where Maven can deliver an industry-leading solution:
provide built-in, out-of-the-box automation for jdeps dependency analysis and jlink runtime trimming.
To realize this vision, we also need a new wave of lightweight frameworks and tools with fewer dependencies, simpler models, and better static-analysis friendliness.
The biggest opportunity is this:
Once Maven provides a standard, easy-to-use minimal runtime packaging mechanism, the entire Java ecosystem will see an explosion of new lightweight frameworks, starters, libraries, and tooling.
New projects, microservices, and applications built on these slim foundations will become extremely popular.
Developers will create small, efficient production-ready services without traditional Java bloat, without AOT pain, and without sacrificing compatibility.
Many details remain to be refined:
more reliable dependency analysis, better handling of dynamic classes, leaner conventions, and tools that work out of the box.
Future JDK versions could go even further by modularizing and separating GC implementations, allowing developers to include only the GC they need.
Combined with automatic jlink trimming, this would produce extremely slim, production-ready JVMs: small, predictable, fully standard, and without AOT drawbacks.
With Java’s massive existing developer base, once these pieces align,
the Java ecosystem will experience a new wave of growth, innovation, and cloud-native adoption.
The end result would be revolutionary:
This can be implemented as an optional opt-in feature with full fallback to original safe behavior.
Teams can experiment safely; if anything breaks, they simply turn it off.
Low risk, high reward — exactly what Java needs to unlock a new lightweight ecosystem.
In short:
We gain all the deployment benefits of Go without abandoning the Java ecosystem.
Java can compete directly with Go in the cloud while retaining scalability, libraries, and enterprise maturity.
For Maven, this is a once-in-a-decade strategic opportunity.
By owning the full toolchain for lightweight, compatible Java delivery, Maven can secure its leadership, retain enterprise users, win back teams lost to other build tools, and help Java outcompete Go in the cloud-native era.
This is how Java should do cloud-native:
without compromise, without disruption, and without losing its soul.
I’m not an experienced Java developer, but I care deeply about Java’s future in cloud-native.
I hope this idea can spark useful discussion.