Hacker News Reader

Comment by tmp7oaje | Hacker News Reader

As a student most of the way through a Java course, I'm wondering what Java is still used for. Java applets are dead, Android is moving on to Kotlin (apparently Google got in legal trouble with Oracle even though Java is "open source?"), and I can't think of any desktop applications that use Java anymore. Java is supposed to be able to "run anywhere," yet C++ is more portable because it doesn't require the JVM to run.

Yet clearly I'm mistaken, since Java is still one of the most popular languages.

Edit: also please help me understand - do I have to pay for a license even though Java is open source? Is this normal for other languages too?

View on HN

>As a student most of the way through a Java course, I'm wondering what Java is still used for.

A huge majority of all code behind services, websites, and businesses you interact with every day. From Google, Facebook, Apple, and Twitter to your bank, and from Android to you favorite new unicorn. Of the top 25 unicorns "20 use Python; 19 use Java; eight use Kotlin. Coinbase was the only top-ten unicorn found to use Swift." [1]

And that's just startups and FAANG. On top of that, every enterprise, government organization, and financial organization also uses tons of Java with the exception of Microsoft shops, which use C# in its place (or also use C# on top of Java).

Think of it this way: you know how C# is a big industry? It's #5 in the TIOBE index. Java is #2, and has been between bouncing between #1, #2, and #3 spots for decades.

And on top of Java there's the JVM, which also powers Kotlin, Clojure, Scala, Groovy, and other languages...

>Java applets are dead

Java applets have been dead on arrival. It was just a fan around 1997-1999 and not that succesful even then (I was there). They were never a big part of Java's allure.

>Java is supposed to be able to "run anywhere," yet C++ is more portable because it doesn't require the JVM to run.

That's a non-sequitur.

[1] https://insights.dice.com/2019/07/12/python-java-kotlin-skil...

> Java applets have been dead on arrival

The only successful Java applet I know was Runescape (if that was an applet? it ran in browser), an RPG game that ran in Java in the browser, for 15 years or so roughly afaik, today they switched to a non browser based client instead.

Other Java applets almost never worked for some reason. Like, sometimes I'd visit a website about some mathematical topic, and the whole browser would hang while some java applet demonstrating the math was supposedly loading, and then most of the time it didn't actually work.

Roughly 20 years ago we embedded Java applets inside a HTML-based online help. This turned the help from a reading resource (which tells you where to find certain preferences) into an actually interactive resource, composed from the same applets that also formed the Application itself.

Worked like a charm. I have yet to see anything similar to that.

The only applet I know of outside the early few years of hype that still works and does something useful is Falstad's circuit simulator. https://www.falstad.com/circuit/

Actually that one has been rewritten in JS! The fast loading and no gray screen gives that away :D

There's a link to the original Java version below, that one doesn't work for me anymore, I no longer have a java-enabled browser

>* The fast loading and no gray screen gives that away :D*

Well, plus the fact that no modern browser runs Java applets...

The first "real" Java program I wrote back in 1997 was a huge applet. It was the replacement for an existing X Windows application, with 42 screens. The applet itself worked great, but the networking technology at the time was such that when all the users on a network segment started their browser and launched the applet, it bogged things down to a crawl. Still, when it was loaded it was amazing (for 1997). It looked almost exactly like the original application, and updates were as easy as putting a new jar file onto the web server.

Don't know about "successful" or "useful", but the Java Applets on Complexification were some of the most beautiful software I've ever seen: http://www.complexification.net/gallery/

> still

It's a very popular backend language. Ironically, "run anywhere" isn't much of a requirement for backend development.

> C++ is more portable because it doesn't require the JVM to run.

For backend development, this isn't much of an issue either way. These days, the main advantages C++ has to Java is startup time and no GC pauses.

It's also not as portable as you'd think. Take a look at cross-platform C/C++ projects and you'll see a lot of special cases for particular platforms.

Java's popularity mostly boils down to it's mature, has a large ecosystem, and is adequate for a lot of things. Unless you're writing an iPhone app or system-level code, it's unlikely to be a bad choice.

> Ironically, "run anywhere" isn't much of a requirement for backend development.

If you’re using Java, you can develop on macOS, deploy on Windows Server, then switch to Linux on AWS Graviton and M1 Macbook. Without a singe recompilation.

There are no GC pauses issues practically now and for years. Language startup is also not all that much issue.

I'd say they're at a point where they're not a problem for most use cases, but if you're trying to get p9999 latency down, you might have to start looking at them.

The default GC has ridiculously good throughput with modest latency (10ms for quite large heap sizes), but there are also alternatives like ZGC and Shenandoah that optimize for latency instead, and they promise <10 ms latency, but in practice they are around 3-4 ms. At which point, not running a real time OS, you will get bigger hiccups from the OS scheduler.

Also, for very different use cases like soft real time, there are specific JVMs with real time guarantees.

Here is a great post about it: https://jet-start.sh/blog/2020/06/09/jdk-gc-benchmarks-part1

And in JDK 16, ZGC has concurrent thread-stack processing, which typically reduces GC pauses below 1 ms

https://openjdk.java.net/jeps/376

https://youtu.be/88E86quLmQA?t=1525

With graal vm java apps compiled to native have amost 0 startup time

Vast majority ( if not All ) of Fortune Global 2000 use Java as their Main Programming Language for their BackEnd.

And this isn't changing anytime soon. Their initial investment, continue investment and Java Ecosystem itself are still marching forward. I dont see any language ecosystem that could match or challenge Java any time soon. Remember you only see Java Haters on HN and Reddit. In the Real World it is all about Business Values Delivered and Get Shit Done.

JVM in itself is a monster with State of the Art GC and JIT.

All of the above means there is a positive feedback loop into making Java better. And there are things that were in the work for 10 years ( Like GraalVM ) before hitting mainstream. And many more to come.

> C++ is more portable because it doesn't require the JVM to run

Java is portable BECAUSE of the JVM. If a new computer architecture hits the scene, once someone writes a JVM for it your .class files will run on it (probably).

Your C++ program, however, will definitely not run and you'll need to recompile it with a compiler that targets that new architecture.

The same compiled Java code will(should) run on a Mac or a PC or any Linux box, but you need a different executable for each target with a C++ program.

The JVM isn't portable. That needs to be recompiled for each new target, but your Java .class files are portable.

For a couple decades, x86 was absolutely dominant and there were no new architectures of any importance outside specific niches. Once you dealt with the OS specific oddities (which java also helped with), C++ was highly portable.

> For a couple decades, x86 was absolutely dominant

On the desktop and servers, maybe. But there is more in heaven and embedded than is dreamt of in your philosophy.

I work in embedded. Embedded Java has always been a huge set of tradeoffs, which is why it never took off outside of application platforms like mobile phones and set-top boxes.

If you wanted the full fat SE Sun/Oracle JVM you were pretty much stuck with power or ARM, and even then you had to be careful. Remember the portability disaster that was symbian and Java ME? These ISAs weren't exactly the low end of the embedded market at the time either. The farther away from x86 you got the less portability you could actually take advantage of.

> Remember the portability disaster that was symbian and Java ME?

Don't forget Java Card in that list. Which Oracle still tries to claim as a Java portability win, even though it doesn't support basically anything. And I don't mean missing standard libraries, I mean like it doesn't support char, double, float, and long, or multidimensional arrays. Support for int is even optional. Doesn't support exceptions and you can't even assume it has a garbage collector. Among many other limitations.

I had successfully blocked JavaCard. Boo.

> but your Java .class files are portable.

No, they aren't, they regularly have non-portable dependencies or assumptions about the environment.

For example, it's more or less impossible to write a Java program that runs on Windows, Android, and iOS - the 3 most popular OS's. You have completely different UI support between Windows & Android, and there's not really any JVM for iOS (there's AOT, but now you're not even pretending to run a .class file)

So to make a "portable Java" program you're already stuck compiling it 3 times for the 3 major OS platforms, but without anything helping you to actually specialize for a platform like exists with C++. Making Java less portable in practice than C++.

Toss in that other popular platform, web, and the "portability" of Java gets even worse compared to others like C++.

> For example, it's more or less impossible to write a Java program that runs on Windows, Android, and iOS

Not only is it possible, it happens all the time.

The entire Maven Central repository, which contains tens of thousands of JVM libraries, is usable on all the platforms you just listed.

If that's not portability, I don't know what is.

Maven runs on 1 out of the 4 mentioned platforms. There are no Android, iOS, or web builds of Maven.

Maven is used to ship dependences for the other platforms, but it is not run itself on those other platforms. Shipping an Android-specific library on Maven isn't magically portable (which is what's common here - OS-specific libraries on Maven). It's still Android-specific.

All Android builds use Gradle and download their dependencies from Maven Central.

I have no idea what you're talking about.

Let me repeat this: all Windows, macOS, Linux, and Android apps that use Maven or Gradle to build ALL download their dependencies from Maven Central. These are the very same libraries, same bytecode.

For example, do you use Mockito? You will download that exact same library from Maven Central regardless of the platform you are building on.

When you build Android you're not building it on Android, you're building it on Windows, MacOS, or Linux. Maven itself is not being run on Android or iOS.

The Java code that powers Maven isn't portable. The AndroidX code hosted on Maven that everyone is pulling down for Android isn't portable, either.

Your claim would be like saying that PHP is portable because every platform has a web browser that can talk to the server running modphp. That's not what portability means.

> For example, do you use Mockito? You will download that exact same library from Maven Central regardless of the platform you are building on.

Mockito only runs on 2 of the 4 platforms (doesn't run on iOS or web).

Who cares about Maven-the-app, we are talking about the portability of the JVM bytecode.

There are gigs of JVM bytecodes stored on Maven Central and these bytecodes are being downloaded and run on macOS, Windows, Linux, and Android on a daily basis without a single change. The very same libraries. Unchanged.

That's the very definition of portability.

I don't understand why you keep shifting topics by bringing up irrelevant observations.

There's no portability requirement to being on Maven Central. Maven Central regularly hosts non-portable bytecode - like every AndroidX library.

And, again, none of those libraries run on Windows, Android, iOS, and web - the 4 major platforms by market share. At best you get half of those, but typically you don't even get that, and that's still only libraries. None of them are portable applications.

It's trivial to write semi-portable C++ snippets, too, that's not a major achievement.

Now you're being intentionally obtuse and moving the goal posts from your original claims just to score points.

You're not arguing in good faith.

Feel free to stick with your invalid views on portability, the rest of us JVM developers will keep enjoying the portability that this wonderful technology provides us.

Me: You can't write a portable Java app that runs on the 4 major platforms (windows, android, ios, web)

You: But <thing that doesn't do that>!

Me: But it doesn't do that?

You: moving goalposts! obtuse!

Any libraries in the Maven repos that rely on JNI have to include platform-specific native libraries for each platform. For example, anything that uses Unix-domain sockets, which weren't supported in Java until this very release.

When people call .class files portable, they mean between platforms that have a JVM available and can pass the TCK.

Platforms that do not aim to do that are not really relevant.

That's like saying C++ exe's are portable if you just ignore all platforms that don't have an NT kernel.

Market share determines a platform's relevance to portability claims, not its intention towards the JVM.

I see that your goalposts in this discussion are also highly portable.

Java is used all over the place for various backend applications, e.g. data processing, web backends. It's fast, well documented and has a great standard library and ecosystem. In many of these applications you control the deployment environment, so making sure that your container has the JVM isn't an issue.

Except for "Java applets are dead", everything else you wrote is wrong :-)

Android is not moving to Kotlin: Kotlin is simply supported as a first class language in Android. Most of Android itself is written in Java and while it's clear that an increasing number of Android developers are switching to Kotlin, Java will never stop being supported on Android.

The legal battle between Google and Oracle has nothing to with Google using Java.

You can use Java for free and without any licensing concerns (use Open JDK).

C++ is less portable than Java precisely because Java runs on a JVM.

Java is used a LOT on the back-end still.

Yes, golang is shiny new thing, but there is TONS of boring back-end done in Java.

Whole Alibaba runs on Java, for example. I know of some companies (won't share names but fill in the blanks) that used to be Go shops, that were eaten by Alibaba and they migrated from Go to Java.

Wouldn't agree on the GO statement, yes GO is great in terms of performance but it still lacks some important language features AFAIK no generics, no proper exception handling. I honestly don't know how the GO ecosystem is, but I can't imagine it's as mature as java. Perhaps I'm wrong tho

I’ve removed that part of the post as I don’t want to make this about go :)

> no proper exception handling.

That's just like saying Go does not have application servers, DI, IOC, ORM frameworks, runtime reflection and so on. Different languages have different ways of achieving user requirements. It is not one-to-one matching.

> ... I can't imagine it's as mature as java.

Yes, depending on perspective, not as mature or not as fossilized as Java.

Here at Quobyte, we're developing a distributed file system that is partially written in Java. The JVM is rock-stable, fast, and developers are very productive in Java.

I discovered Quobyte today thanks to this comment. I am extremely excited to start exploring your technology.

I am also working on a networked file system solution. My approach is likely fundamentally different. Instead of a single file system to represent file system artifacts across various devices I am using a single simplified data model as an abstraction for all file systems and pairing that with a new security/identity scheme. The idea is to solving for file asset distribution using point-to-point solutions that don't compromise security or privacy.

https://github.com/prettydiff/share-file-systems

I suspect your approach is likely far more stable as I am still working out the kinks in my models, but I supply a complete GUI in the browser that works the same in all browsers on all modern OSs.

> and I can't think of any desktop applications that use Java anymore.

The desktop application everyone has to use to report the income tax in my country is written in Java. Which is nice since it runs anywhere that has a recent enough JRE; in a distant past, before it was rewritten in Java, it was first a DOS-only and then a Windows-only desktop application.

All jetbrains IDEs are JAVA. Webstorm, Intellij etc

I have worked with Java EE (Enterprise Edition) for a few years. Java in the backend is probably the most common one when doing enterprise software.

Lets define it differently: Everything what is not an SAP System and is backend and is not Cobolt, is Java at least for automotive and banking. Automotive -> managing cars, service contracts, financing offers, accessories and for banking -> money management, insurance, contract management etc. You go to a shop and you wanna finance something? Might be a Java backend or Cobolt :D)

Spring/Spring Boot as a Framework got a lot of traction because Java specification process was just way slower and more boilerplate

And yes Oracle got fed up of doing Java for free for too long and if you wanna use an older version of java and still need patches, you will need to pay.

Luckily there is were java actually shows it strength which i have not seen in other languages: You define a specification, you get a reference implementation from someone and then everyone around it starts to build on those specifications.

This allows for different jpa (database access with java) implementations, different application server etc. It also allows for different companies to do their own JVM implementation/maintenance track/version.

From an ecosystem pserpective, the JVM itself (without java) also did a great job and shows how versatile it is. Close to what .net is doing but in a more free version. And you could throw .net/c# into the same similiar category as Java. Language feels similiar and if you are a MS company, you just use C# perhaps. But switching between c# and java is much easier than to other languages.

From all languages i know and worked with, i do like JVM based languages the most. golang is interesting but nothing i would wanna use for a big code base at all. C/C++ i would use if i need to because of tooling features, how you write it and how hard it is to write it good;

Java is fast, java has great tools for a long long time: Great Debugging features, great memory and performance analysis and tools, lots and lots of frameworks and architecture catalog.

PHP is written and used in business context like java but without the benefits of running on the JVM. I don't recommend it. Its not bad, its less boiler plate but its just not a nice well defined well designed language. Most shocking to me was the performance optimizations which were done a few years ago which shows how little interest in that language exists that you can just optimize it that much. What facebook did with PHP was just shitty and weird.

for a while i got confused and thought you were talking about usage of cobalt element in manufacturing of automobiles.

To give you some more details of how Java can be used in the backend, while there's obviously unknown "generic business logic" there's also big name infrastructure pieces you can look up:

- https://en.wikipedia.org/wiki/Apache_Hadoop

- https://en.wikipedia.org/wiki/Apache_Kafka

- https://en.wikipedia.org/wiki/Apache_Cassandra

- https://en.wikipedia.org/wiki/Apache_Lucene

- https://en.wikipedia.org/wiki/Elasticsearch

- https://en.wikipedia.org/wiki/Apache_ZooKeeper

- https://en.wikipedia.org/wiki/Apache_ActiveMQ

Java is not commonly used for consumer desktop applications, where it often is necessary/desirable to invest in fully native apps for Windows and MacOS. But desktop Java is quite common in business desktop applications, for example, medical devices (like radiology image viewers).

I'll give you a bit of advice I give to engineers I mentor. Go to a tech jobs site like dice.com, and put in a technology you're curious about. So, put in java for your zip code. See what jobs are available. Are they back end? desktop? Then you'll find out where java (and any other tech) is used, and how popular it is. For example, how many jobs are there for PHP compared to Java?

I'm not saying you should adapt a technology based solely on the number of jobs...but we all gotta eat. And on the flip side if you see Java jobs decline over the years...time to learn the one that's increasing :)

Java is _very_ prevalent in Financial IT - almost everywhere. C++ is probably the only language in the same league in terms of usage. I have also seen C# lately in bunch of places but mostly middle-office/back-office.

Look into Spring Boot for cloud applications, it’s a big ecosystem

We use it on servicing the backend of an e-commerce website. The code is now 2 decades old and wonderfully refactorable to modern code.

I’m assuming Amazon? Most of Amazon runs on Java.

Most OpenJDK implementations do not require a license.

There are multiple implementations of the Java VM. Java is designed by a collaboration of companies and OpenJDK is the reference implementation. Based on the license of the company, its implementation is free or not.

Now, Oracle was the biggest and most well known contributor of OpenJDK for a long time (and probably still is). And Oracle did something unusual, which is that they made their own version no longer free. Which is why you are confused. You can still get Java from Oracle, with Long Term Support, but now it is paid support.

The OpenJDK reference implementation is still free, and many companies have made their own tweaks and provide Long Term Support for these versions, mostly because they use tons of Java and/or want others to keep using Java because of its massive ecosystem, for which they can provide consulting/paid support. Note, you can still run these versions commercially, but if you want support you likely have to pay.

The Google issue was that before all this OpenJDK stuff, all designing of Java was done by a single company, Sun, which was bought by Oracle. So a single company designed, developed, implemented, maintained, and built up the ecosystem of Java. This includes years of R&D in what keywords to use, and how classes work, basically the rules of the language. Tons of developers got into Java. And they attracted big customers like banks and governments to pay them for this R&D with support and development. Then came Google and they said, we like this language design and ecosystem and developer skills, but we don't want to pay for that support, so thanks for all the hard designing of your language, but we will create our own implementation and pay you nothing. Basically Google didn't want to pay it's share of the Java R&D. Now things get a bit blurry because of Oracle, which bought Sun, and tried to make a lot more money off Java while reducing R&D spending. So Oracle isn't too popular either.

Things have improved since Oracle decided that Java isn't something to make a lot of money off, and the whole Google debacle. Now Oracle is mostly stewarding the language and other companies are now also contributing features. The past few years there have been some good and strong updates to Java, making it feel more like a leading language than a trailing language.

Basically, get AdoptOpenJDK, latest version if possible, and don't use preview features.

> do I have to pay for a license even though Java is open source?

Most people use free OpenJDK builds (Adopt OpenJDK, Zulu OpenJDK, Oracle OpenJDK to name a few). There are some builds which require license, like Oracle Java. If you need some kind of advanced support, you have that option.

>>I'm wondering what Java is still used for.

A good part of AWS is written in Java. The Hadoop, Storm, Spark, Kafka etc major backend projects are written in Java.

In fact if you are writing anything even half serious. Java is what you chose to write it in.

>>Java is supposed to be able to "run anywhere," yet C++ is more portable because it doesn't require the JVM to run.

Manual garbage collection is long dead, and it won't be revived any time soon. Machines have gotten too fast and resourceful for most of the developer community to give it a serious selection choice for their projects.

Not saying C++ or Rust is dead. They have their place. But they are not going to be used for bulk of everyday projects. That ship sailed long back.

Java is rarely used for sexy stuff like front-ends or (increasingly) apps.

Java is, however, used for services. Bank logins, search engines (Google originally used it), insurance systems.

C#, C++ and Rust are in the same area. But Java, for the most case, has been around longer.

A LOT of companies used it and can't easily switch their codebase to something newer and shinier. And now Java improves with every release they have fewer reasons to move.

> A LOT of companies used it and can't easily switch their codebase to something newer and shinier

I don't agree with that. Spring Boot makes it so easy to write nice backends and a type system is often useful

> they have fewer reasons to move

Move to what btw? NodeJS?

Literally every business that adopted it back in the 90s. Like all of insurance.

Other languages have started to eat into Java's market share, but coincidentally a lot of them run on the same host VM as Java. For instance, Kotlin, Scala and Clojure are more and more frequently seen in backend, web and mobile development.

These languages are definitely much more "portable" depending on what your definition of portability is; the JRE runs on A LOT of systems and abstracts much of the underlying system away for you, meaning that IME you have to write a lot less platform-specific code if you're targeting e.g. Windows, macOS and Linux.

As for your edit, the licensing is a bit complex for Java but TL;DR if you install OpenJDK releases you do not need to worry yourself about licensing.

Your credit card runs Java, that's a fun one

E. g. Backend services for webapps or HFT.

Reply on news.ycombinator.com