Wow this is a really big deal. I know Jigsaw support was hotly debated for a long time, I’m glad it found its way in and I’m glad it provides such a major value add to the language - being able to seamlessly create stand alone native executables is something neither Python nor Ruby can do right now out of box.
Nice to see an already super capable platform continue to evolve in useful ways!
being able to seamlessly create stand alone native executables is something neither Python nor Ruby can do right now out of box.
Sure, but on the other hand it’s a bit of a sad commentary on the state of programming tooling that the bar is so low that this is considered a big deal.
It is, and it isn’t. Think about the vast amount of code and configuration and process that goes into creating a .EXE in Windows versus an executable binary in Linux versus a .app in OSX. That’s a non trivial task right there.
It shouldn’t be, but it is.
I see this less as an indictment of the state of programming tools and more of an indictment of the fact that platforms can’t and won’t agree to standardize anything at all for commercial reasons.
You’re right, I was overgeneralizing. I do think that commercial concerns had some bearing on some of these decisions (e.g. why are we still creating .EXEs 20 years later when this is arguably an artifact of MS-DOS) but certainly in the Linux versus OpenBSD case it’s a matter of design choice.
After lobste.rs talked about A Fire in the Deep and A Deepness in the Sky, I just finished reading them. Developments like these make me think of the tech, thousands of years old and completely irreplaceable, that exists in A Deepness in the Sky. On one hand we lambaste the JS world for rewriting itself every other week, but at the same time we keep Java alive and kicking. I am one of those people that thinks the JVM is long past its prime (every heavy use of Java is running it on hardware the have defined ahead of time and don’t benefit from anything the JVM gives them), but I guess we’ll be stuck with Java for a long time as it keeps on doing accreting new functionality to keep chugging a long. IBM posted its first quarter in 5 years where it will see growth. Why? Thanks to the mainframe portion of the business.
It’s also incredibly complicated. Language implementations like Go and Ocaml are on-par with the JVM in most workloads people care about at a fraction of the complication. The JVM exists because of “write once, run everywhere”, but that vision never panned out.
Got a cite for that? I don’t doubt what you say, but I think a lot of people formed impressions about Java that are of varying levels of accuracy.
The fact that companies like Square, Netflix and Amazon use Java extensively even for greenfield projects should be an indicator that Java is far from the tire fire some people make it out to be.
Sure, it’s verbose, and there are parts of its ecosystem that are excessively complicated, but there are newer choices that have learned from the past and eschew that kind of complication in favor of a much leaner style.
I’m not trying to get anyone to love or use Java who doesn’t want to, but I’d encourage people to challenge their long standing impressions and come to a better understanding of what the language is good at and which use cases might call for its use.
I’m not saying Java is a tire fire, I am saying its runtime no longer suits the case it was designed for. People know what hardware and processor they are running their programs on.
The most common use-cases I see today is server-side, which are almost entirely I/O bound. Erlang compares well to Java in this use case, if only for utilizing I/O so well.
I don’t have any studies for you other than the fact that everything is a service now.
For the complexity aspect of my claim, I think that is self-evident if you’ve looked at the code of the various runtimes.
So, thanks for some good food for thought. I’ll leave you with this - Every problem is different. There are still large swaths of problem space that the Go ecosystem has barely even nibbled at which have very rich support in the Java world.
That combined with newer frameworks which are the polar opposite of some of the useless complexity we’ve all battled in the past (Take a look at Play for an example of what I mean) can make Java a really great choice for some problem domains.
I just think we need to be careful about making overly general claims, and open minded to the fact that there are huge swaths of the industry still coding in Java for a reason.
I think some aspects of my point are being conflated a bit, though. I’m not making a statement about Java-the-language, I’m making a statement about the runtime. My point about Ocaml/Go, which I didn’t make very well, is really that these are languages with a much simpler runtime but still quite comparable performance combined with my claim that the problem the complex runtime is solving is not a problem a vast majority of Java users have.
I just think we need to be careful about making overly general claims, and open minded to the fact that there are huge swaths of the industry still coding in Java for a reason.
If you reread my first comment, I think you’ll see I fully acknowledge that. Mainframes are still a money-making business (would you advocate one use a mainframe, though?) It’s a fact that people are running lots of workloads on the JVM. I even work for a young hip company that uses the JVM. But I’d also be cautious of reading too much into that, IME, the “reason” people do it is often not connected to a technological merit.
Mainframes are still a money-making business (would you advocate one use a mainframe, though?)
That depends. What do you mean by ‘mainframe’? There are scads of business running on the descendant of mainframes - the IBM Power system to this day, running ageless workloads using tools like COBOL and RPG and the like, because those tools suit he use case.
Sure, there are tons of people out there supporting legacy hardware and software nobody in their right mind would choose for a greenfield project, but that’s a different problem.
It’s a fact that people are running lots of workloads on the JVM. I even work for a young hip company that uses the JVM. But I’d also be cautious of reading too much into that, IME, the “reason” people do it is often not connected to a technological merit.
Technical merit has many variables attached. If you’re really talking strictly about runtime size, then you may have a point. I’d argue that for many (most?) people, runtime size is pretty much meaningless.
You’ve successfully proven a couple of assertions like “Go runtimes are smaller than Java’s” and even “under certain circumstances, Go can outperform Java” but I respectfully disagree with the idea that choosing Java might not be the right thing based on technical merit.
The JVM exists to be a Java bytecode interpreter. It’s counterproductive to assign any more labels to it – write once, run anywhere is hardly its main focus these days.
I would argue, basing on what most Java software is built for, that the JVM exists to be the best abstract bytecode interpreter there is. It’s not particularly great for small-scale algorithmic benchmarks like the alioth benchmark games, but where it shines is long-running processes. Servers.
The TechEmpower benchmarks demonstrate this. JVM languages occupy a significant portion of the top 10 in every segment.
Comparing the JVM to OCaml/Go runtimes is not fair. The JVM is a much more complicated beast, given that it supports some very advanced features like:
AOT and JIT evaluation (fair enough, AOT support is experimental, but it is there)
An extremely sophisticated garbage collector which is user-tuneable (this does not exist in Go/OCaml)
A user-configurable concurrency model (native threads, fibers, green threads) - OCaml concurrency support is blah and Go only has green threads
Code hot swapping and dynamic class loading
Direct native code interface (OCaml is better in this regard, but with Go you need SWIG)
And HotSpot is just one implementation. There are several enterprise-grade JVMs out there that include crazy things like real-time support (PTC Perc, JamaicaVM), AOT (ExcelsiorJET) and native execution (IM3910.
I think your citation of the expiry of the write-once, run-anywhere paradigm is anecdotal. I develop on OSX and run my .jars on Linux and Solaris v11.
As I said, the comparison is not fair. The JVM has about 25 years of engineering behind it. For that reason alone, it is extremely unwise to downplay it as outdated.
I don’t really understand the core of your response. Part of my claim is that the JVM is a big complicated beast, and that’s not a good thing. And your response is “It’s not fair to compare it to <X, Y> because the JVM is a big complicated beast”. How is one to argue that being a big complicated beast is not a positive thing?
Go and Ocaml are on-par with the JVM in most workloads
That’s a huge benefit of the JVM right there. Most developers and their managers have absolutely no idea what their workloads will be 2 years down the road.
Using the JVM obviates the risk of coming back to a system and having to significantly re-engineer it due to Go’s/OCaml’s runtime starting to choke as the amount of data grows:
Service needed 1GB back then, now it requires 10GB.
Go/OCaml: Rewrite your application.
JVM: Who cares? Traffic could even have grown to 100GB, and buying more RAM would fix it.
Using lesser runtimes is basically a bet that your application will never experience an increase in traffic.
Your claim that the JVM just magically scales up to any workload does not match my experience. I see software rewritten on the JVM as much as any other language. Perhaps you have some specific experience in mind that you could share. Maybe you’re talking about something like Azul? Sure, I’ll grant you that. But in the microservice world, those situations are few and far between. To be clear, I am not saying that some people aren’t just buying bigger hardware to run their JVM programs, I am saying that usecase is dwindling, IME.
Well, you said: “Language implementations like Go and Ocaml are on-par with the JVM in most workloads people care about”.
I pointed out that the Alioth benchmark game is not “most workloads”. I gave the TechEmpower benchmarks as a more relevant benchmark environment (web applications, since that’s what most people do). These benchmarks demostrate that JVM is more performant than the languages you mentioned.
Where you are correct is that the JVM is a complicated beast. I do not disagree there. But it’s a performant and sophisticated one, that is definitely not past its prime.
I am one of those people that thinks the JVM is long past its prime (every heavy use of Java is running it on hardware the have defined ahead of time and don’t benefit from anything the JVM gives them).
Could you elaborate on this? I find this statement quite confusing.
The point of the JVM is a portable runtime so you can compile your program once and run it anywhere. However, every company I have worked for deploys their program to one platform, running one OS, in a very well-defined environment. The value of the JVM is limited. “What about the JIT?” one might say, but IME, the JIT offers no value over AOT for modern workloads and it’s significantly more complicated.
I do run across projects that make use of the JVM’s non-platform-specific binaries fairly regularly, but for forward compatibility in case of a future platform migration, rather than cross-platform portability of the style where you need to deploy to multiple platforms simultaneously (where, yes, only one platform is usually targeted). It’s not uncommon to find some random ancient .jar file in the libs/ directory, and for the development team to assume that kind of thing is going to keep working forever even if the project migrates to a different platform; there may not even be source, if it was a licensed commercial library. In that respect it has some of the same uses in enterprise as mainframe-style binaries, which also typically compile to some kind of bytecode to ensure binaries will keep running without a recompile, even across major platform updates.
I’m not sure what part of our industry you’re in but I think those usecases are decreasing over time. I hear horror stories about banks that just have a .jar sitting around without source code that they depend on, but I’m not sure that is motivating enough for why the rest of us have to live with a massively complex runtime.
I think that was the point once, but I don’t think that has been Java’s primary thrust for quite a while. That paradigm made much more sense when Java was aiming for the browser and the desktop, and today those use cases are not the language’s primary focus.
My point is not that the use cases for the language are static, but that they have changed and we are still stick with this hugely complex runtime for a use case that isn’t really used that much (IME).
Wow this is a really big deal. I know Jigsaw support was hotly debated for a long time, I’m glad it found its way in and I’m glad it provides such a major value add to the language - being able to seamlessly create stand alone native executables is something neither Python nor Ruby can do right now out of box.
Nice to see an already super capable platform continue to evolve in useful ways!
Sure, but on the other hand it’s a bit of a sad commentary on the state of programming tooling that the bar is so low that this is considered a big deal.
It is, and it isn’t. Think about the vast amount of code and configuration and process that goes into creating a .EXE in Windows versus an executable binary in Linux versus a .app in OSX. That’s a non trivial task right there.
It shouldn’t be, but it is.
I see this less as an indictment of the state of programming tools and more of an indictment of the fact that platforms can’t and won’t agree to standardize anything at all for commercial reasons.
Is it really due to commercial reasons? I can’t run my Linux binaries on OpenBSD neither can I run any BSD binary on Linux.
You can run your Linux binaries (some of them, at least) on FreeBSD and even more so on SmartOS.
You’re right, I was overgeneralizing. I do think that commercial concerns had some bearing on some of these decisions (e.g. why are we still creating .EXEs 20 years later when this is arguably an artifact of MS-DOS) but certainly in the Linux versus OpenBSD case it’s a matter of design choice.
After lobste.rs talked about A Fire in the Deep and A Deepness in the Sky, I just finished reading them. Developments like these make me think of the tech, thousands of years old and completely irreplaceable, that exists in A Deepness in the Sky. On one hand we lambaste the JS world for rewriting itself every other week, but at the same time we keep Java alive and kicking. I am one of those people that thinks the JVM is long past its prime (every heavy use of Java is running it on hardware the have defined ahead of time and don’t benefit from anything the JVM gives them), but I guess we’ll be stuck with Java for a long time as it keeps on doing accreting new functionality to keep chugging a long. IBM posted its first quarter in 5 years where it will see growth. Why? Thanks to the mainframe portion of the business.
IIRC, the JVM is an incredibly fast VM with hundreds of man years put into performing well.
That alone ensures it will stick around for quite awhile.
Yup. Hotspot is awfully hard to beat.
It’s also incredibly complicated. Language implementations like Go and Ocaml are on-par with the JVM in most workloads people care about at a fraction of the complication. The JVM exists because of “write once, run everywhere”, but that vision never panned out.
Got a cite for that? I don’t doubt what you say, but I think a lot of people formed impressions about Java that are of varying levels of accuracy.
The fact that companies like Square, Netflix and Amazon use Java extensively even for greenfield projects should be an indicator that Java is far from the tire fire some people make it out to be.
Sure, it’s verbose, and there are parts of its ecosystem that are excessively complicated, but there are newer choices that have learned from the past and eschew that kind of complication in favor of a much leaner style.
I’m not trying to get anyone to love or use Java who doesn’t want to, but I’d encourage people to challenge their long standing impressions and come to a better understanding of what the language is good at and which use cases might call for its use.
What are you asking for a citation for, exactly?
I’m not saying Java is a tire fire, I am saying its runtime no longer suits the case it was designed for. People know what hardware and processor they are running their programs on.
That.
Ah,
One source:
http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=java&lang2=go
The JVM beats Go for 3 out of 10 problems (and by a pretty significant margin).
For Ocaml, it’s 4/10 for beaten by a significant margin, and the other numbers are pretty comparable:
http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=java&lang2=ocaml
The most common use-cases I see today is server-side, which are almost entirely I/O bound. Erlang compares well to Java in this use case, if only for utilizing I/O so well.
I don’t have any studies for you other than the fact that everything is a service now.
For the complexity aspect of my claim, I think that is self-evident if you’ve looked at the code of the various runtimes.
So, thanks for some good food for thought. I’ll leave you with this - Every problem is different. There are still large swaths of problem space that the Go ecosystem has barely even nibbled at which have very rich support in the Java world.
That combined with newer frameworks which are the polar opposite of some of the useless complexity we’ve all battled in the past (Take a look at Play for an example of what I mean) can make Java a really great choice for some problem domains.
I just think we need to be careful about making overly general claims, and open minded to the fact that there are huge swaths of the industry still coding in Java for a reason.
I think some aspects of my point are being conflated a bit, though. I’m not making a statement about Java-the-language, I’m making a statement about the runtime. My point about Ocaml/Go, which I didn’t make very well, is really that these are languages with a much simpler runtime but still quite comparable performance combined with my claim that the problem the complex runtime is solving is not a problem a vast majority of Java users have.
If you reread my first comment, I think you’ll see I fully acknowledge that. Mainframes are still a money-making business (would you advocate one use a mainframe, though?) It’s a fact that people are running lots of workloads on the JVM. I even work for a young hip company that uses the JVM. But I’d also be cautious of reading too much into that, IME, the “reason” people do it is often not connected to a technological merit.
That depends. What do you mean by ‘mainframe’? There are scads of business running on the descendant of mainframes - the IBM Power system to this day, running ageless workloads using tools like COBOL and RPG and the like, because those tools suit he use case.
Sure, there are tons of people out there supporting legacy hardware and software nobody in their right mind would choose for a greenfield project, but that’s a different problem.
Technical merit has many variables attached. If you’re really talking strictly about runtime size, then you may have a point. I’d argue that for many (most?) people, runtime size is pretty much meaningless.
You’ve successfully proven a couple of assertions like “Go runtimes are smaller than Java’s” and even “under certain circumstances, Go can outperform Java” but I respectfully disagree with the idea that choosing Java might not be the right thing based on technical merit.
The JVM exists to be a Java bytecode interpreter. It’s counterproductive to assign any more labels to it – write once, run anywhere is hardly its main focus these days.
I would argue, basing on what most Java software is built for, that the JVM exists to be the best abstract bytecode interpreter there is. It’s not particularly great for small-scale algorithmic benchmarks like the alioth benchmark games, but where it shines is long-running processes. Servers.
The TechEmpower benchmarks demonstrate this. JVM languages occupy a significant portion of the top 10 in every segment.
Comparing the JVM to OCaml/Go runtimes is not fair. The JVM is a much more complicated beast, given that it supports some very advanced features like:
And the new Graal compiler is really cool.
And HotSpot is just one implementation. There are several enterprise-grade JVMs out there that include crazy things like real-time support (PTC Perc, JamaicaVM), AOT (ExcelsiorJET) and native execution (IM3910.
I think your citation of the expiry of the write-once, run-anywhere paradigm is anecdotal. I develop on OSX and run my .jars on Linux and Solaris v11.
As I said, the comparison is not fair. The JVM has about 25 years of engineering behind it. For that reason alone, it is extremely unwise to downplay it as outdated.
I don’t really understand the core of your response. Part of my claim is that the JVM is a big complicated beast, and that’s not a good thing. And your response is “It’s not fair to compare it to <X, Y> because the JVM is a big complicated beast”. How is one to argue that being a big complicated beast is not a positive thing?
That’s a huge benefit of the JVM right there. Most developers and their managers have absolutely no idea what their workloads will be 2 years down the road.
Using the JVM obviates the risk of coming back to a system and having to significantly re-engineer it due to Go’s/OCaml’s runtime starting to choke as the amount of data grows:
Service needed 1GB back then, now it requires 10GB.
Using lesser runtimes is basically a bet that your application will never experience an increase in traffic.
Your claim that the JVM just magically scales up to any workload does not match my experience. I see software rewritten on the JVM as much as any other language. Perhaps you have some specific experience in mind that you could share. Maybe you’re talking about something like Azul? Sure, I’ll grant you that. But in the microservice world, those situations are few and far between. To be clear, I am not saying that some people aren’t just buying bigger hardware to run their JVM programs, I am saying that usecase is dwindling, IME.
Well, you said: “Language implementations like Go and Ocaml are on-par with the JVM in most workloads people care about”.
I pointed out that the Alioth benchmark game is not “most workloads”. I gave the TechEmpower benchmarks as a more relevant benchmark environment (web applications, since that’s what most people do). These benchmarks demostrate that JVM is more performant than the languages you mentioned.
Where you are correct is that the JVM is a complicated beast. I do not disagree there. But it’s a performant and sophisticated one, that is definitely not past its prime.
Could you elaborate on this? I find this statement quite confusing.
The point of the JVM is a portable runtime so you can compile your program once and run it anywhere. However, every company I have worked for deploys their program to one platform, running one OS, in a very well-defined environment. The value of the JVM is limited. “What about the JIT?” one might say, but IME, the JIT offers no value over AOT for modern workloads and it’s significantly more complicated.
I do run across projects that make use of the JVM’s non-platform-specific binaries fairly regularly, but for forward compatibility in case of a future platform migration, rather than cross-platform portability of the style where you need to deploy to multiple platforms simultaneously (where, yes, only one platform is usually targeted). It’s not uncommon to find some random ancient .jar file in the
libs/directory, and for the development team to assume that kind of thing is going to keep working forever even if the project migrates to a different platform; there may not even be source, if it was a licensed commercial library. In that respect it has some of the same uses in enterprise as mainframe-style binaries, which also typically compile to some kind of bytecode to ensure binaries will keep running without a recompile, even across major platform updates.I’m not sure what part of our industry you’re in but I think those usecases are decreasing over time. I hear horror stories about banks that just have a .jar sitting around without source code that they depend on, but I’m not sure that is motivating enough for why the rest of us have to live with a massively complex runtime.
I think that was the point once, but I don’t think that has been Java’s primary thrust for quite a while. That paradigm made much more sense when Java was aiming for the browser and the desktop, and today those use cases are not the language’s primary focus.
My point is not that the use cases for the language are static, but that they have changed and we are still stick with this hugely complex runtime for a use case that isn’t really used that much (IME).
Can you link to this discussion? Sound quite interesting WRT the books.
Gladly:
See https://lobste.rs/s/hsdcqo/repo_upon_deep#c_vles2i
Specifically this comment from @akkartik : https://lobste.rs/s/hsdcqo/repo_upon_deep#c_y1nfhu