Continuing the series! Feel welcome to dip in and weigh in on a past question.
Let's say I've never used Java before. Can anyone give the run down of what the language does and why you prefer it? Feel free to touch on drawbacks as well.
For further actions, you may consider blocking this person and/or reporting abuse
Top comments (60)
Pros of Using Java:
Cons of Using Java:
Java is not slow.
Java is not for desktop apps.
Java is reasonably verbose, which makes support and maintenance of long-living projects much simpler. As a consequence, Java dominates enterprise software development. Needless to say that it means virtually infinite number of jobs, constant high demand and great salaries.
P.S. Java is very expressive and simple language with very straightforward, consistent and well thought out syntax.
I don't think it's performance is bad compared to other interpreted languages. Sure it is slower than compiled languages but very fast for most task. Also what do you mean by no backup facility?
I can only second that. Performance is actually very good, in fact it outperforms natively compiled C++ code in many situations as the hotspot VM aggressively optimizes at runtime.
Also I don’t understand what „backup facility“ means.
I never coded in Java but used many internal developed Java softwares and every single one was slooow. We had the same app later rebuilt with Electron which was fully written in JavaScript/Node and it felt like 50 times faster.
Slow apps could be written in any language. Java is not an exception.
Those "internally developed Java softwares" were likely desktop apps ... let's be frank, Java on the desktop (applets, JWT, Swing and all that) sucks ... do not, I repeat do not, use Java on the desktop - should only be used server side!
@ivanjeremic
If you think electron was faster, you can't imagine the performance of tauri, or webview.
I have worked on Java desktop app. They can be really fast if you compile it for production, which uses compiler optimization flags. Yes startup time can be slow in some cases, but JVM has been improving a lot in past few years. Memory footprint of J9 is also in league of its own.
It also depends on framework used, In my experience, If animations are avoided, Fx is really fast, compared to swing. That said, Swing is really performant library. Eclipes IDE uses SWT which is built upon on swing.
Good to hear a bit of a different view, the huge amount of bashing that Java gets (often not based on actual knowledge) can be tiresome ...
Sorry but it's not an "interpreted language", not by a stretch ... it uses a JIT compiler, once a piece of code (class or method) has been JIT-compiled it essentially runs almost at C/C++ speed (well, with still some runtime overhead in the form of garbage collection and all that).
I know that. I am just comparing it's speed with an interpreted language
Right, well then you know it's not in the same league :)
Java is Just-In-Time compiled language. It's performance comparable or even better to compiled languages like C or Rust.
I know that JavaScript is a JIT language it is comparable but not faster it can however have a few areas where it is as fast as compiled or faster, but most of the time just comparable.
JS as a language has some specific (variable type may change at run time, for example), which makes efficient JIT compilation somewhat tricky.
Kindergarten here.
When Java became interpreted?
Go to school, take some lessons.
Before arguing properly READ WHAT I SAID. I am just comparing it's speed to an interpreted language.
You don't have problem with Java alone, but with English and languages in general.
Sentence: "I don't think it's performance is bad compared to other interpreted languages." states that you think that Java is interpreted language.
Listen comparing java's speed with an interpreted language doesn't mean that I think it is an interpreted language. That like saying fighter jet is sound because we often compare it's speed with sound(mach number literally means number of times faster than sound). So instead of arguing(in this case you are completely wrong) do something useful or maybe learn english and how to behave online
Ok. Let me give you kindergarten level example.
I think that Ferrari is fast compared to OTHER bicycles.
Word OTHER here means that Ferrari is a bicycle. Otherwise, it completely redundant.
I hope you finally learned something.
Also, you don't actually need to think about Java performance. Just check some benchmarks. For example: github.com/kostya/benchmarks. You will see that Java between fastest and for some tasks Java is the fastest language. And its main competitors are C, C++, Rust and Go. Are those interpreted in your opinion?
You will also see, that comparing Java to interpreted languages like Ruby, Python and PHP is meaningless as its performance usually ten times higher.
Opinion that Java is slow comes exclusively from "new language of the day" propagandons and aimed into idiots who tends to believe everything they read more than once.
"Slow and Poor Performance", "Poor GUI", "No backup facility" - are you talking about Java on the desktop? (applets, swing, JWT) ... that's a disaster, and always has been, but Java on the server is a different story, it'd well-respected.
(scalability and memory management of the JVM in server environments are arguably strong points ... verbosity of the language remains an issue, but you can use other languages on top of the JVM)
Slow and poor performance? Where is it came from?
Compared to which language? JavaScript? Python? Ruby? PHP?
Do you have a benchmark?
Java is among fastest languages. For some tasks it is comparable to C++. With much simpler memory management.
Verbose - yes, but it is feature. All your fancy JavaScript oneliners should be well commented to be understood. Java code that follows conventions is self explained.
Writing GUI is not simple in Java, but it is possible. Check Eclipse and Netbeans. Those apps are among most complex GUI applications you ever seen and they written entirely in Java.
Apache Cassandra is written in Java and it's fast 🤷♂️
Java is a great language to learn and use for the following reasons:
It is one of the most widely-used languages there are, consistently placing in the top three most popular alongside C++ and Python
It powers most of the major web apps you know--everything from Twitter to Google Maps to eBay
As a result, it has a huge ecosystem of open-source libraries and frameworks around it. You can leverage the advantages of widely-used and well-maintained libraries for every kind of programming task imaginable from concurrency to testing (caveat: this also means you can experience analysis-paralysis about which library/framework to use to accomplish a task)
It has great performance and scalability, particularly in web services and applications (caveat: it is slow to load and does not support autoscaling as well as a language like Go)
Java is always backwards-compatible, even across major versions, so code that was written twenty years ago can (and does) still do its job today (caveat: this sometimes means it is slow to adopt modern language features or does so in unexpected ways)
A real advantage of Java is not the language itself, but the Java Virtual Machine. The JVM both allows Java to run atop any underlying hardware (you can run Java on your phone or your microwave, for instance) and allows you to use wholly other languages like Clojure, Kotlin, Scala, etc. in case you prefer a different idiom (functional, for example)
HIH
Pros:
Cons:
Verbosity is not a bad thing. There is no behind the scene magic, which means you are in control, and can optimize code and its performance. Also in large enterprise, verbosity is encouraged because it will make it easier for the next guy who will replace you, to understand what is happening in code. Some companies even have code guidelines that prefers you to not show-off your special tricks and stick to basics.
At beginners level, With verbosity, you will learn concepts at a great details because you have to write every step of that concept. Every line of code that you write, you will ask yourself "have I covered all edge cases"
At intermediate level, your IDE will take care of a lot of stuff for you, You will have learnt the reason for any line of code you have written. So you will create generic snippets, and write a lot more code by writing a lot less.
And once you reach advance level of skillset, you will look beyond IDEs, You will use libraries like project lombok to replace boilerplate code with rich annotations. You will embrace annotations because you know what code compiler will generate based on those annotations. You will play with different JVM flags to optimize bytecode. All because you have a clear understanding of code that was verbose.
Probably what you abhor is the verbosity - that got quite a bit better with the most recent version(s), but still ... there's also a culture in the Java world of being in love with 'patterns', with layers upon layers upon layers, and with over-engineering in general ... I worked with Java for a long time, but for me moving to other languages and ecosystems was a breath of fresh air.
You've really hit the nail on the head here. I'm working with a Java dev on a Typescript project at the moment and he's really struggling to get out of this mind set. Especially wrapping everything in a class
Yep ... :)
First thing he needs to do is forget and unlearn the heavy OO baggage, and throw that thick "patterns" book (the infamous "Gang of Four") out of the window ;)
test induced design damage
Lol and that is? TDD (if that's what you mean) is generally a commendable technique, it's not necessarily the reason why all of the Java software got so complex, it's more the mindset that everything needs to be infinitely generalized and abstracted to death, even when there's no reason to do so.
dhh.dk/2014/test-induced-design-da... - that was the article that got me thinking that hexagonal architecture, which I first encountered in reading about java (and scala) patterns, was part of a pattern of over engineering in some circumstances.
Ah right, interesting article ...
The problem is the misconception that all tests must be "unit" tests in a pure sense - no database, no I/O, only calculations ... that's of course nonsense and impractical, and that's not what TDD says.
If you accept that a large part (the largest part) of your tests just execute web requests (but without talking to a real web server over the network), and use a (test) database, then TDD can still be applied perfectly well without having to use Hexagonal or such extreme stuff.
So I'd say don't blame TDD, blame people who don't understand how to implement it in a practical way. Oh and Hexagonal Architecture is cool and interesting, and very relevant ... for less than 5% of all apps/systems ;)
(the 5% is almost certainly an exaggeration)
It is a robust and solid programming language.
You can build web APIs, Android applications and even GUIs with it.
The ecosystem is great and very mature!
There are well maintained libraries for nearly every use case.
Pretty much every problem in Java has already been solved.
Literally, for every possible problem, there is a tutorial, library or research.
Anything from wrappers for some esoteric legacy protocols, to using existing C++ libraries.
Java is pretty much a 34 rule of programming. If some problem exists, there is a Java solution for that.
This is so true, it made my day. 🤣
There have been many times, when I was working on PHP, or Node, I was stuck and closest thing I found was a java solution. It is easier to understand because of its verbosity, and convert that solution to whatever stack I am working on.
Most recently, I was working on a Golang project, and was stuck trying to refactor a very large module. I found an article on DZone about a similar example, I printed out the code, and implemented the structures based on that. Now my teammates are piggybacking on the improved package I wrote.
Funny thing is that this is the first time I am working with Golang, in a job. I have just learned Golang last year, and basically made a few contributions on various oss project on github. But my team is very happy to work with me, all because of Java.
Disclaimer: I am a card-carrying member of the Boring Technology Club and my pitch might sound a bit like "nobody gets fired for buying IBM", but Java is a total work-horse.
It is not pretty. It is not best in class. But it is solid and has you covered. But you can draw from a vast pool of resources, have plenty of software engineers with experience to hire, there is an abundance of libraries. Its ecosystem is mature. All the stuff that makes you productive is in place.
I build software for hospitals for a living. I like to sleep well. I use Java.
If you’re into something longer, I wrote about it here…
dev.to/stealthmusic/java-is-dead-l...
…and here…
dev.to/stealthmusic/modern-java-de...
Write once run anywhere without recompiling. Coming from c++ that's a good addition
@goyo I'm calling you out! I know you got some thoughts on this topic. 😀☕️
Well, a lot has been said here already but I'll chime in.
Java, especially the newer versions, is a very good language for server-side applications - it's fast, reliable, has powerful tooling and libraries, and virtually every question you may have has already been answered online.
On the other hand, it is not the most sleek language so if someone really cares about punctuation or the number of characters they have to write, they may be put off.
The language is ubiquitous among enterprises, so it's a pretty solid bet if you want to get a job or switch companies. It also means you're likely to work with enterprise applications and deal with complex business issues. IME, if you're biased towards solving interesting domain problems, you'll be happy doing it with Java (and probably any other language). If you're more biased towards doing cool technical stuff, you're probably going to look for something else.
Personally, I'm in love with Kotlin and I see it as an obvious replacement for Java, as they work in the same ecosystem.
I have been trying to find statistics on Kotlin backend adoption. I don't have a good way of measuring it right now. I see it occasionally in backend job descriptions. I suspect it will take over java marketshare, but not sure.