Hacker News Reader

Comment by coldtea | Hacker News Reader

>Today, the JVM runs on an estimated 89% of computers, 3 billion mobile phones, and 125 million TV devices.

I'm not even sure the above is technically correct. But even if it is:

1) it runs on most of those "89% of computers" as Java Applets, a technology noone cares about, not as a readily deployed Java runtime for the desktop.

2) Those 3 billion mobile phones either are Android, in which case they don't exactly run Java, or are insignificant featurephones with mobile Java that again nobody cares about.

3) Nobody cares about those "125 million TV devices" as platforms either.

View on HN

> 2) Those 3 billion mobile phones either are Android, in which case they don't exactly run Java, or are insignificant featurephones with mobile Java that again nobody cares about.

No. Java is more pervasive than you think. It's widely used in SIM cards: http://en.wikipedia.org/wiki/Java_Card

You can't get away from it.

Still, SIM cards are not a platform anyone cares about either. It's not like it matters what runs in SIM cards with regards to Java's viability.

(Not to mention they'll probably get the boot soon, as they're an obsolete technology)

Not in Africa and other developing countries.

Actually tons of people in Africa have Android phones by now...

Android phones use SIM cards in most of the world.

CDMA/locking the device to an account is basically a US only thing.

But who cares about sim cards? If SIM cards were to run on Fortran (for some strange reason), would you argue that Fortran is the wave of the future.

Exactly that.

I didn't say Android phones don't use SIM cards. I'm a European, I have an Android and an iPhone with SIM cards both.

I replied to the statement that "in Africa they don't use Android phones", not that in Africa they don't use SIM cards.

Of course they have Android phones. My point is that SIM-based applications for payments especially are still quite widespread in Africa.

Since when are SIM cards going obsolete?

It's been an ongoing research to get a new standard going:

>"The GSM Association, an organization of wireless telephone operators including AT&T Inc., plans to replace the removable SIM card connecting handsets to networks with a system integrated in the devices."

http://www.bloomberg.com/news/articles/2010-11-18/gsma-explo...

Apple then made a first move adding a "programmable SIM card" -- which is a first step towards software-only SIM:

>"Some of Apple’s latest iPads have a new type of SIM card that lets users switch easily between operators without replacing the card. This could seriously weaken the operators’ grip on their market, especially if Apple were to follow up by putting the new SIMs in iPhones or replacing them with software"

http://www.economist.com/news/business/21633870-moves-reinve...

>"As others have pointed out, as of right now the Apple SIM isn’t a huge threat to the existing smartphone sales model – contract subsidies are too attractive to customers. But ultimately, Apple is almost certainly hoping to replace the physical Apple SIM with a software solution built directly into devices; in fact, it was working on such a plan back in 2010, before that was axed by opposition from a coalition of European carriers in particular."

http://techcrunch.com/2014/10/16/apple-sim-details-and-poten...

This is an argument that applies equally well to Linux; after all, my auto mechanic could give a shit what OS runs on his phone or set-top box.

If Linux was only used inside phones or set-top boxes as embedded software, yes, it would be as insignificant as QNX.

There would be some embedded software programmers employed, to write the set-top box or the phone OS, and that's it.

The same way that before phones had "app platforms" nobody cared what OS an Ericsson, or a Nokia or a Motorola phone run, and the number of people who worked on them was insignificant (basically employees of said companies).

What makes Linux important for millions of people is that it's used in servers, corporate and home desktops, phones, consoles, etc, that have active application platforms, it gives jobs to sys-admins, web apps, pages and services are written in it, etc.

It's not just that an "auto mechanic" doesn't care what OS runs on his set-top box, it's that unless that OS also provides a platform that lots of people work on nobody else does either (except of the "coders of propriterary embedded-ware" that wrote it and those competing for jobs with them in a quite small market).

A commenter lower down says it more succintly:

">who cares about sim cards? If SIM cards were to run on Fortran (for some strange reason), would you argue that Fortran is the wave of the future?.

It's called Java Card and is used in smart cards (pocket-sized card with embedded integrated circuits) in Europe, Africa, etc.: http://en.wikipedia.org/wiki/Java_Card and http://en.wikipedia.org/wiki/Smart_card

"Java Card bytecode run by the Java Card Virtual Machine is a functional subset of Java 2 bytecode run by a standard Java Virtual Machine but with a different encoding to optimize for size"

It's a proprietary binary blob like the GSM-modem in your smartphone or the HTML5-DRM-module in your web browser. It probably falls under the category security by obscurity.

> 2) Those 3 billion mobile phones either are Android, in which case they don't exactly run Java, or are insignificant featurephones with mobile Java that again nobody cares about.

It may or may not be as relevant as before, but one of the smartest things that WhatsApp did was to care about mobile Java.

>Java Applets, a technology noone cares about

I care about them as a security hazard. See "Java Primary Cause of 91 Percent of Attacks: Cisco" (2013) and similar.

http://www.eweek.com/security/java-primary-cause-of-91-perce...

lol, don't run java in your browser man. Just don't. boom bam no Java security flaws

You don't always have that choice. There was a European country (I forget which one. Norway?) that was using applets for access to government services.

Germany was it – until 2011 the only way to file taxes digitally was through a Java Applet called ELSTER. Now there is a beta version of a JS based solution.

You can run Java selectively then, disable when not knowingly using it. Would provide a higher magnitude of security than just having it running while a rogue 0 day exploit hits advertisement servers or something similar.

Not to detract from your point, but the applet part of Norwegian BankID is now mostly replaced by the new Javascript-based solution.

They were in a bad place but in the last two years they've spent considerable time stomping security bugs - Java was the only one left standing at the pwn2own comp last year https://nakedsecurity.sophos.com/2014/03/13/pwn2own-day-one-...

Security contests are the worst way to eval security. It might have something to do with the java prize only being $30K (cuz it's so fucking easy) instead of $75K.

If Fischer Price made "My first exploit" kits it would ship with java.

> Those 3 billion mobile phones either are Android, in which case they don't exactly run Java

That's true, but it's also academic. Android's runtimes, Dalvik and ART, have very similar semantics to runtimes that use Java bytecode.

In the Android toolchain, Java source code gets compiled to Java bytecodes. This enables Java tooling to work with the Android toolchain. Then the Java bytecode is converted to Dalvik bytecode.

So, on the one hand you can say "There is no Java in Android devices." But very few Android APKs are created without Java in the code base.

"don't exactly run Java" - Dude, most Android app's are built using Java.

but not run Java

The JVM has had billions of dollars of engineering effort poured into it. At the same time, it is still out-performed by low-budget small-team efforts (e.g. LuaJIT, Inferno).

The article disassociates itself from Java the language. Java was a better C++ in 1994. It has long since been eclipsed by both improved old languages that have evolved (e.g. C++11/C++14) and new languages (e.g. Go and Rust) that are unencumbered by the JVM. This is despite recent incremental efforts to renew Java the language.

Instead, the article tries to claim some success for Java by switching focus to the JVM. The JVM is still slow and - by its design (a clunky stack-based architecture) - simple to implement but very hard to run fast.

Java will still be around for a long time to come. It's the COBOL of our generation: it's better than what it replaced, but far away from what we are capable of.

>The JVM is still slow

What are you talking about? It's the fastest widely deployed VM out there...

If you want to talk about "widely deployed VMs" then Dalvik is faster. If you want to talk about VMs in general then there are many that are faster, e.g. LuaJIT.

Actually no, Dalvik is slower than the JVM and with worse GC.

And LuaJIT faster than the JVM? Where you got that? You wont fine many benchmarks or people agreeing with you. LuaJIT is faster (much) than most scripting languages, but not faster than Java.

Are you comparing startup time?

Dalvik is ~3x slower than JVM for compiled (JITed) code (on an ARM Cortex A8):

https://dl.acm.org/citation.cfm?id=2388956

It's always fun to see how different people throw around the seemingly-absolute terms "slow" and "fast" when there is always some other platform they're implicitly comparing to. I had a chuckle about this the other day as I was evaluating BEAM for potentially running a re-write of a Rails app; I was thinking how pleasant it was to use a platform so fast when I came across people ridiculing how slow Erlang is (presumably relative to C++ or even the JVM).

Those people don't get the point of Erlang. You'd have to be completely oblivious to complain about performance on the Erlang VM. The Erlang developers will always sacrifice performance and everything else in favor of reliability and response time. Consider that every actor has its own heap and GC. That's slightly absurd, honestly, but it makes sense when you think about Erlang's goals. I just get so frustrated when people say things like that.

Indeed, these claims always lack context of what is being attempted. If you are using Erlang to perform matrix multiplications on large datasets or some kind of CPU intensive work, you're probably barking up the wrong tree.

But if you want to parallelize and distribute less CPU intensive tasks and have fault tolerance, then it's a good choice.

Being the fastest VM doesn't make a VM fast. It's just faster than other slow things.

True, but thankfully the JVM is faster than most compiled languages as well.

Yes, that's why modern triple A titles are written on the JVM.

The JVM can generate faster numeric code than C++ in limited instances and when writing in C/C++ style. And then when you want to be faster than java you drop down to ASM and use a few SIMD instructions.

In the general case when you write real applications it's much slower. Not to mention that no one wants to drop 12 frames waiting for GC.

Why does someone bring up game performance when the discussion is about JVM versus native code? Languages with a GC compiled to native code have the same problems, even C/ASM calls can be relatively expensive in languages compiled to native code (e.g. see Go).

There are many other classes of applications outside games where a few milliseconds of garbage collection are acceptable. It is no surprise that many server applications are written in JVM languages - the 2x C/C++ performance is acceptable when people get a lot of instrumentation, more safety, etc.

Java is rarely 2x faster than C/C++.

I would say the primary reasons server apps are written in Java is the enterprise support and giant ecosystem as well as number of developers who can write java. The performance on the server is decent, and great compared to ruby/python.

People bring up video games because they are the most demanding apps most people run. Similarly you'll see apps like Photoshop, Office, etc written in C++.

Languages with a GC blah blah blah don't matter because no one writing C++ for performance uses a GC with it. I'm comparing C++ to Java for real world apps not language benchmarks, etc. C++ would not be my first choice for a web app because the task is trivially parallelizable and you get little improvement in string copying between C++ / Java / etc which is the primary thing web apps do, copy strings.

You say the JVM is hard to run fast because it has a stack-based architecture.

That argument doesn't make any sense to me - by the time you are in your dynamic compiler, and you have an IR in something like sea of nodes, what difference does it make in what format the program was represented on disk? The stack part of it has long gone by then.

wait til they hear that Linux has a stack-based architecture. that all C-based software has a stack based architecture. threads with stacks everywhere: surprisingly fast. it's usually things like higher-level architectural patterns and algorithm choices which make a MUCH bigger impact on latency and throughput, than whether you have stacks or not.

The thread is talking more about stack versus register-based VMs than call stacks.

The great stack vs. register-based debate is, in my mind, somewhat like the CISC vs. RISC debate—a fun water cooler conversation, but not too relevant in practice. All performance-focused language VMs lower into a (usually SSA-based) IR soon anyway, so the difference only ends up mattering for VMs that are deliberately kept simple for code size, simplicity, or legacy reasons (like Lua, or CPython).

fair points

That's not what that means. In the context of bytecode, a stack-based architecture is one where instructions directly manipulate stack entries. For example, the Java bytecode instruction iadd takes the top two entries from the stack, adds them together, and pushes the result onto the stack. This is in contrast to a register architecture, where you might have an instruction of the form `add x, y, z`, which takes the values in two registers, adds them, and stores the result in another register.

To say that Linux or C is stack-based is nonsensical, as it applies to an instruction set architecture. Virtually all hardware ISAs you're likely to encounter are register-based these days.

C compiles down to register-based machine instructions, just as Java bytecode does. Bytecode is merely an intermediate represenation.

But in doing so, Java runs by simulating a stack machine, hence the name virtual machine.

Java bytecode is instructions for a stack machine -- but that's an abstraction. Then the bytecode compiles down to (register) machine instructions, and that compiled implementation is highly efficient and highly optimized.

The virtual machine itself is a complete abstraction. Modern JVMs do not run a simulation of a stack machine at runtime (after compilation, that is).

His argument is hearsay. There's no conclusive evidence that a stack-based VM will always perform worse than a registered based one. There are tradeoffs between both designs. With all of the optimizations you see from register based VMs, you end up with larger instructions due to the lack of a stack pointer.

You can claim that the JVM runs faster than Dalvik though, because it has a better JIT that has had years more to improve.

But I don't know why JVM is being compared against Dalvik when ART is where Android is going in the long run, and has AOT compilation that beats Dalvik's JIT.

"The JVM has billions of dollars of engineering effort poured into it. At the same time, it is stil out-performed by low-budget small-team efforts (e.g., LuaJIT, Inferno)."

This seems a truism with respect to many "high value" software products/projects across the computing world. The ones that attract large investment.

The only time I ever use Java is when I use something made by someone else who uses Java. And when their software slows to a crawl or crashes, what can I do? It was not my decision to use Java. It is so pervasive, there's Java on a SIM card, what can a user do? Impossible to avoid.

But as for computers where I can open them up and install my choice of kernel and utilities, I have no need for Java. There is not a single file of Java anywhere in my source tree. I can find code written in terse languages that does everything I need to do with the computer. Code that out-performs Java, easily.

Maybe something written by a small team or even one person. :)

I think that is what makes the ITC field so entertaining. No matter how much cash and how many engineers a company can accumulate, a small team of dedicated people with little to no money, sometimes just one incredible mind sitting at a keyboard, can still create something that wins on performance. Is that not "success" of some sort?

As for Java, I guess it depends on how one defines success.

I like brevity, conciseness, performance and reliablity. Not sure I would label Java as a success under those criteria, but that is just my personal opinion as a user.

In terms of mindshare, Java is a tremendous success.

You mentioned Go. Rob Pikes' OSCON 2010 talk introducing Go had some criticisms of Java with examples. I think he said Java was a symbol of bureaucracy or something to that effect. Let us celebrate the success of bureaucracy. Congratulations Java.

What year is it where you are?

Java is no longer slow. JVM languages in general are very, very fast. HotSpot is, frankly, incredible.

There are legitimate gripes to be had about Java as a language, but Java as an ecosystem and a runtime are incredible.

All java software installed on my computer are still slow as shitting. All my java projects need minutes to compile fully and to startup. All my java programs uses hundreds Mb memory.

On the contrary, Golang programs run much faster, compile much faster, use much less memory.

Apples, Oranges. The Golang compiler is made for a language designed for speed of compilation. If you'd write a golang compiler in java (why you'd ever do that is not a relevant question here) then it would most likely be quite fast too.

If you're complaining about java programs that are slow or memory hogs you can only compare languages when you build the exact same application using different languages.

Yes, for the exact same application using golang and java, golang one startups faster, much faster, and uses less memory, much less.

Reply on news.ycombinator.com