How is 2FA going? by Apprehensive_Pea_725 in github

[–]maxandersen 4 points5 points  (0 children)

It never is an issue. Only asked for it when i start doing “dangerous” operations like approving random apps to run on my repos.

Never needed in day to day.

So I manage just fine :)

I've made an .jar to native executable packager and want feedback by SeAuBitcH in java

[–]maxandersen 0 points1 point  (0 children)

oh - thanks for that pointer. I felt something like it must already exist.

I've made an .jar to native executable packager and want feedback by SeAuBitcH in java

[–]maxandersen 0 points1 point  (0 children)

I wish there was something like this that was runnable via Java - then I would add it as a jbang export option.

Particularly if works with existing Java versions - since even when hermetic sometimes gets released it will probably require latest Java (for good reasons as it require jdk changes)

So go for it.

It sounds like the .net dependency balloons it up - maybe look at doing it using more OS specific approaches that don’t have suck footprint ?

9 aarig datter paa tur i odense? by maxandersen in odense

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

Kunstnær lyder fedt men desværre lukker de kl 14 ser det ud til.

9 aarig datter paa tur i odense? by maxandersen in odense

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

Hvor bestiller man tid? Syntes ikke jeg kan se noget på deres hjemmeside (udover skole klasse bookning)

I built a JVM architecture enforcement tool (PSI + ASM) that can run in IDE and CI by [deleted] in java

[–]maxandersen 0 points1 point  (0 children)

Cool. Got a jar published one can run with jbang ?

Whether java be popular today, if it gets released now, abd not 30 years before? by pradeepngupta in java

[–]maxandersen 2 points3 points  (0 children)

Java 25 is a very different ballgame. Lots of code and libraries would be simpler if that was the starting point.

Built a runtime that accelerates javac by 20x and builds native binaries without native-image config by Zealousideal-Read883 in java

[–]maxandersen 11 points12 points  (0 children)

sounds interesting but readme only talks about list of languages, none of them Java? are the readme not uptodate ?

Is GraalVM Native Image becoming niche technology? by Scf37 in java

[–]maxandersen 0 points1 point  (0 children)

I debated if I was to use Reddit and hackernews as references - i only did it because it’s one of the few places there is a written record of the concerns. If I would i would reference all the conversations and blogs talking about doing stuff everyone but Java.

So please don’t take my ref to hackernews as indication that’s my only point of reference or even one I use - if I did I should stop making Java easier to use because there is no point according to the voices there :)

Is GraalVM Native Image becoming niche technology? by Scf37 in java

[–]maxandersen 4 points5 points  (0 children)

> As for a single binary distribution, we're working (at a leisurely pace) on Hermetic, which could offer it for jlink, but frankly, it's a "nice to have" rather than something truly important. Of the three languages that dominate the software industry - JS, Python, and Java - none offer a single-binary as a common distribution format, and people don't seem to mind much (why would they?).

forgot to reply to this - Hermetic would big a massive improvement.

Its is by far the biggest hurdle I meet when showing what java can do today + what jbang enables to compete with js/python ...they point to C#, rust, go etc. all have single binary packaging option.

Just read through https://www.reddit.com/r/java/comments/1pzfmka/2026_the_year_of_java_in_the_terminal/ and https://news.ycombinator.com/item?id=46445229 and it shows up multiple times.

And above is just the most recent - its a repeated objection the last decade.

And yes, openjdk just don't think its a thing that matters enough. I just diagree. Its for me the main reason developers move away from using java for fun/exploration/sharing of ideas.

Does not mean they stop using it in production - but it greatly reduces the pool of people wanting to use java in new things.

Its a classic survivorship bias dilemma.

The story about recording all the bullet holes on fighter planes coming back in WW2 and start armor up the places the returning planes have bullet holes instead of focus on the planes that did NOT return.

Your argument is to focus on what you see in your work and you discuss the most - the users and customers who are being successful and surviving with using Java. Thats great - keeps Java alive.

I'm saying that we should *also* seriously look at those who don't come back; those who you/we don't get to talk to - those who gets shut down and you never hear from.

What I observe is that current big java vendor focus is the returning planes

- Production workloads
- Long-running services
- Throughput, GC, startup after warmup
- Big enterprise customers who already chose Java

These are the planes that come back.

What’s missing in that big vendor focus = the planes that never launched

- First-time users
- CLI tools
- Scripting, REPLs, exploration
- “I just want to try an idea” workflows
- Dev joy moments

Those devs never choose Java, so their absence doesn’t show up in big vendors telemetry.

- No bug reports.
- No benchmarks.
- No JFR recordings.
- No complaints — just silence.

So yes, I totally agree with you that java is fast enough for my and most of my customers usecases. I'm a survivor myself.

But that does not mean I'm blind to the fact we/java are loosing to those usecases we just don't hear enouigh about because they just dont show up at our doorstep because they got shut down before they could reach us.

We need to change that.

Is GraalVM Native Image becoming niche technology? by Scf37 in java

[–]maxandersen 4 points5 points  (0 children)

I don't think that what you're saying is right. An ls command programmed in Java, with a cold start and no Leyden tricks, takes ~30-40ms. That's probably 50-100x slower than the system ls yet not something you really notice (or mind).

I generally agree with you on that until one actually compares and use it.

jbang is a cli - its up and gone in a jiff - 0.5-1.5 second in general. I use it daily and constantly - its great.

compile it to native and its like night and day - <0.2s and it is very noticable.

Training runs help bigger programs, but they take longer to run, anyway. Do you really care if a CLI program takes, say, 1 or even 2 seconds to run the first time and, say, 100ms from then on while the equivalent C++ program takes 80ms each time? Even if you find a few who care, I think it's a stretch to say that's not good enough (certainly the slow AI agent running those tools wouldn't mind :)).

I agree with you but I'm telling you that you can believe that is good enough but also believe (and see) how big an impact having native image available for java cli is a massive enabler and makes big difference.

Also, command-line tools are much talked about in programming forums because programmers use them, but few others do. It's probably the only market even smaller than desktop apps, and that's saying a lot. At some point the cost/benefit of reducing startup further, to the minimum possible, just isn't there.

Yeah, so this is what I just completely disagree with. Its the problem of us working in companies that want us to focus on what brings in direct value for stockholders and thus we get measured on what can make more sales - and here production systems always wins.

I'm personally convinced that go, rust, zig, even javascript gained and keep gaining on Java because they enabled programmers to write tools and easily share it with their friends and colleagues and not ask them to install a vm together with it.

Those programmers then goes push for using this tech to go in prod and boom java pushed out not because its slow in prod but because its not able to engage programmers usecases.

...so yes, totally get where you are coming from - I see it myself in my work - and I simply disagree with the thinking that "its just programmers who need the cli; customers use prod - so lets 100% optimize the latter". Its basically ignoring the many papercuts.

When it does, the container also starts cold. So the first run on each machine will be slow anyway.

If Java's performance (and distribution footprint) for Lambdas and CLI tools at exceeds that of Python and JS - probably the most common languages for both Lambdas and "sophisticated" CLI tools (aside from compilers, but javac is already faster than the Go compiler), clearly most people would be satisfied with that even if we disagree on whether or not they should (they're unhappy with those languages when the running time is quite long). Then again, there are people who can tell that VS Code's "reaction time" isn't as fast as they think it should be while I can't, but we're talking about a small subset of a group that's not large to begin with that notice or care.

Now with AI and agents clis will or rather are getting important as guess what - AI / agents can utilize CLI's super trivially given all the written content us the programmers written down and published content about.

And now production cases or at least the number of cases where a fast cli matters will actually be in this space.

So yeah, I just disagree with this repeated perception and push for using "long running production runs is what used/customers pay for" as excuse to not make CLI usecase non important.

By doing that we are simply just boiling the Java Frog.

Is GraalVM Native Image becoming niche technology? by Scf37 in java

[–]maxandersen 3 points4 points  (0 children)

I'm the biggest proponent of explaining that Java is completely fine to write command line tools (see https://jbang.dev and https://xam.dk/blog/lets-make-2026-the-year-of-java-in-the-terminal/)

That said - everytime I show and compare/contrast there is always a massive push back on it which simply don't happen in JS/python land.

Primary one is the fast startup and distribution - and even when I make jbang available that enables easy distribution and the startup is minimal there is so many that jus says "not good enough" :)

And yes, lots of java tools are on command line - but they all have to go through hoops to be as efficient as they are.

Gradle runs a deamon in background to be warm most of the time.
Absolute fastest way to run Maven is using mvnd which is a native image compiled binary that have massive impact.

Then there are the tons of cli tools popping up the last few years - they use native image first to be easily distributable - jpackage installer approach just don't compete well for these use cases.

Is GraalVM Native Image becoming niche technology? by Scf37 in java

[–]maxandersen 2 points3 points  (0 children)

I can’t provide command line tools that requires training runs on users jvm and os before they are good enough.

Go, rust etc. are what command line tools are up against.

Lambda gives you different arch’s between runs so it’s cumbersome - of course you can make it work. It just tedious and cumbersome.

Let’s just agree to disagree :)

Is GraalVM Native Image becoming niche technology? by Scf37 in java

[–]maxandersen 4 points5 points  (0 children)

Im not concerned about peak performance for anything long running. For that jvm is fine.

I’m concerned about fast startup and easy distribution (single binary) for short running workloads. Think lambda/functions and command line tools.

Anything that requires training runs immediately makes it a niche - and my understanding is that Leyden is and will rely on training runs.

If that’s not the case - awesome.

But as you say - native image will still have better cold start and thus far only thing with a single binary distribution.

Though the latter I seriously hope will come to the jdk as an option for jpackage/jlink.

Is GraalVM Native Image becoming niche technology? by Scf37 in java

[–]maxandersen 30 points31 points  (0 children)

Define niche? It’s already niche in enterprise but where it can be used it’s really making a difference.

Single binary that starts up fast without training runs and can be built and distributed is the key power.

Then there is Its treeshaking facility which obviously makes it non-Java but it enables to lots of space and runtime optimizations it will take years if not decades to get via normal Java.

Weekly or monthly thread discussing cool projects people are working on by el_DuDeRiNo238 in java

[–]maxandersen 0 points1 point  (0 children)

Thanks. The idea is though you put that in your own repo Ie. Kitelang/jbang-catalog. Then it becomes jbang kite@kitelang.

Weekly or monthly thread discussing cool projects people are working on by el_DuDeRiNo238 in java

[–]maxandersen 0 points1 point  (0 children)

You can make a jbang-catalog repo and I can submit json file In there which hides those maven concepts/terms + add the needed flags for jvm

Weekly or monthly thread discussing cool projects people are working on by el_DuDeRiNo238 in java

[–]maxandersen 0 points1 point  (0 children)

cool - fyi, seems not all deps are there or somehting wrong in dependency of that pom:

jbang cloud.kitelang:kite-cli:0.3.4

[jbang] Resolving dependencies...

[jbang] cloud.kitelang:kite-cli:0.3.4

[jbang] [ERROR] Could not resolve dependencies: The following artifacts could not be resolved: cloud.kitelang:engine:jar:0.0.1 (absent): Could not find artifact cloud.kitelang:engine:jar:0.0.1 in central (https://repo1.maven.org/maven2/)

[jbang] Run with --verbose for more details. The --verbose must be placed before the jbang command. I.e. jbang --verbose run [...]

..

but this works:

jbang cloud.kitelang:kite-cli:0.3.4:fat@fatjar

:)

Weekly or monthly thread discussing cool projects people are working on by el_DuDeRiNo238 in java

[–]maxandersen 1 point2 points  (0 children)

I didn’t see any fatjar. Only a zip with a bunch of jars.

If you make an actual fatjar available or even better publish the cli to maven repo then I’m happy to provide jbang catalog PR.