Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

2026: The Year of Java in the Terminal?

xam.dk

Post reply on HN
Print view View original

141–150 of 191 posts

Re: 2026: The Year of Java in the Terminal?

#141

Post by nineteen999 »

voidfunc wrote: post #42
chamomeal wrote: post #26

Earlier quoted context omitted.

Yeah it’s funny how “Java runs everywhere” was a huge selling point of the JVM. But now it’s not even included in macOS by default, so if you want somebody to use you Java/clojure CLI they have to install Java. And that will raise eyebrows and make people think “what is this, 2010??”

jpackage It does all of this work for you and its a standard tool that dumps out a platform specific application bundle. The only people living in 2010 are the ones that choose to live there with incredibly outdated takes on things they dont understand.

> platform specific

Write once, run everywhere.

Re: 2026: The Year of Java in the Terminal?

#144

Post by Tostino »

awesome_dude wrote: post #97
burnte wrote: post #74

Earlier quoted context omitted.

Java SHOULD never become a player in anything more until Oracle stops being such a threat. Oracle just wants to be a parasite on companies that actually build.

I gave up on Java when Oracle took over, because I thought that it was such a horrific move, but, to their credit, they haven't ruined it for everyone (yet) They've kept it alive, allowed it to grow, and innovate, even let Green threads back in. I'm not planning on going back to Java, but that's no longer because Oracle.

They have been better stewards of Java than Sun was IMO. I never would have expected it at the time, but it has turned out alright.

Re: 2026: The Year of Java in the Terminal?

#145

Post by ivan_gammel »

weinzierl wrote: post #138

It is not only the language but also the mindset and culture. When in Java System.exit() and even System.println() are treated as smells and I have to actively push to get exceptions from the company wide style I'll just write Rust and be done.

Company wide styles that restrict things generally rather than putting them in context are bad smell itself.

Re: 2026: The Year of Java in the Terminal?

#146

Post by thomashabets2 »

thayne wrote: post #103
thomashabets2 wrote: post #81

Earlier quoted context omitted.

> Java on the other hand makes it impossible to get a single distributable. Heh, I find this very amusing and ironic, seeing how Write Once Run Anywhere was a stated goal with Java, that failed miserably.

It was successful for a while. Java applets were once fairly common. But then Flash largely replaced them, and then Html5 killed them flat.

A very limited "anywhere", but yes.

For that use case, was it active content, was it shipping intermediate representation, was it a sandbox? To all three: yes, very poorly.

Re: 2026: The Year of Java in the Terminal?

#147

Post by ivan_gammel »

ninth_ant wrote: post #84

I get the argument from this article that it’s possible. But I don’t get the argument that this is somehow desirable. Just because it’s possible to smash a square peg into a round hole doesn’t make it a good idea.

The argument is probably that it’s no longer square.

Re: 2026: The Year of Java in the Terminal?

#148

Post by CamouflagedKiwi »

gegtik wrote: post #99
CamouflagedKiwi wrote: post #94

Earlier quoted context omitted.

I don't think uv makes distribution simple? Unless I've missed something, it doesn't do anything out of the box to help you produce a standalone artifact - it builds wheels but those are only useful for a user that already has python and pip, and don't do anything to deal with Python version drift etc.

uv can install a version of python of your choosing in addition to pulling the specific versions of libraries specified in your lockfile. it's extremely dummy-resistant.

Right, but that means the end user has to have (or install) uv, and then you ship them all your code, and then they can use uv to run that. That's a development workflow - and exactly what I meant when I said that uv didn't solve distribution in the way a language like Go or Rust does by producing a single binary.

Re: 2026: The Year of Java in the Terminal?

#149

Post by CamouflagedKiwi »

unlikelytomato wrote: post #105
CamouflagedKiwi wrote: post #90

Why? It's not well suited to it - fundamentally the language semantics lead to very large distributions, slow startup and expecting a runtime on the machine. Okay, I hear this can be solved by Graal, but that's a whole piece of its own complexity that you'd never have to worry about with a tool written in something like Go. Python has many similar properties, but at least there I can understand that Python is a 'pret…

Regarding slow startups, I am not sure this applies to any use cases I can think of where it would not also be a concern in python, etc. JVM startup times have never meaningfully impacted my workflow in the last 15 years. The why is quite simple, in my opinion. I see java devs reaching for other accepted tools for such things and opening a whole can of worms by introducing a new language that is only "required" by co…

Right, as I said I also think Python has similar issues with startup time.

I've used a limited amount of Java CLIs, the most obvious ones are things like Gradle which never felt snappy to use - it is annoying when even doing basic things takes 2+ seconds. I guess not the end of the world, but that seems suboptimal to me compared to a system that feels fast to use and hence well engineered.

Post reply on HN