There're a lot of incorrect opinions among developers - some root in misunderstanding, lack of knowledge or bad experience from past. Java develope...
For further actions, you may consider blocking this person and/or reporting abuse
I'm also baffled by all those people claiming that Java is "slow" - its JIT compiler and its JVM are heavily optimized, for sure if you look at raw speed it runs circles around Ruby, Python, or PHP.
It's only when you start comparing it to C/C++ that you could call it "slow" but that's a weird comparison, C and C++ are like "high level assembly", they're used for totally different things than what Java is used for.
In reality the idea that Java is "slow" is an urban myth and not based on anything.
This is actually the first time I read that "Java is slow" is a thing. I've always thought that the common disposition is to write your v1 on Python/PHP/Ruby, release it ASAP, and then rewrite it in Java for speed once you're earning millions.
I've heard the "Java is slow" thing many times, but I've never really understood where it comes from. Yes, if you write it in assembly or C then it's faster "duh" but that's not the point hope.
Maybe it harkens back to the old days of Java 1 and the failed "applets" concept, which gave it a bad name. And I see some people complaining about JVM startup time and memory usage, or GC pauses, although in those areas a lot of progress has been made as well.
If you can criticize Java for anything then it would be its verbosity and the slow evolution of the language (but even those two have been addressed recently) - but not its speed per se.
Yeah, I've seen companies doing that. For instance writing machine learning/intensive data processing in Python and when bottlenecks are found, they rewrite parts of the application to Scala/Java.
Java "buggy or not secure" is IMO entirely due to perceptions of client side Java, which nobody uses and which only causes problems.
Client side Java is, was, will be, and always has been, an epic failure, and should have been retired years ago ... Java belongs on the server, period.
I agree. However, there're a lot of client-sided applications for digital signatures (e.g. eGovernment) using Java Web Start and while I'm not an expert in this area, I don't know whether there are any other cross-platform solutions that would do the same.
Hm yes I guess there are some niche apps where it's popular, e-signatures used by e-government would be one example ... but isn't it possible nowadays to do that kind of stuff simply with Javascript? Which I think would be vastly preferable over foisting Java or Web Start on the end user.
I believe you when you say there are still apps out there which use client side Java, but my guess is they're just old legacy apps, and the government doesn't have the resources to rewrite them ... but for new apps probably nobody would consider Java anymore (or Silverlight, or Adobe Flash for that matter).
Also, cheerpj can compile the stuff to js, depending on what level of hardware/network access it needs.
WOW just wow, how many people in this world would know that :-) .... "CheerpJ Applet Runner", that's just genius
Need to give this a look, thanks!
People who like messing around on old sites with archive.org :)
What modern developers call is slow, is sometimes not the language per se, but the workflow around the language and tooling. For example developing something Python is the workflow is pretty simple, edit - run - observe. The feedback loop is short. I can type and observe the effect immediately. The same advantage for example using flutter. Every time i hit save in my IDE/editor the UI gets updated almost immediately.
Java on the other hand has the following development cycle:
Type → compile → package as jar → run → wait for web server to start up → observe code change. The sad part of all this is that modern Java frameworks such as springboot compile, package and run my web apps sometimes in under 15 seconds. But still for them script kiddies is just to slow. In fact I have seen some "modern" java script tooling frameworks take sometimes even longer to build a fully deployable artifact.
Ah yes, but at least the java package manager (maven) doesn't let me die of old age before it's done, nor does it create singularities on my file system 😆
(on a more serious note, hot reloading can alleviate much of what you mention)
In all honesty my experience of the tooling for Javascript was much worse than I've ever experienced with Java. Specifically adding a dependency via NPM would sometimes break my project build to such an extent that I had to start almost from scratch. At this stage I rather deal with "slow" Java than me having to start the same project everytime NPM crash my project.
I'm currently learning SpringBoot with Udacity.
Taking a dip in Java ecosystem, it's so vast.
I love the lambda functions they added in 8. when a ROR dev sees it gives us a breather and appreciate how nice Java syntax has changed in recent years
What do you mean ? JavaScript was totally created by aliens !
Just kidding.
Great article. Java isn't going anywhere and i feel it gets a bad rep because compared to JS or python it is more daunting to get into. But like you point out, it's gotten a lot better over the years.
This sums up lots of misconceptions nicely! Thanks man! Java has evolved a lot in the last years and now supports many innovative features like Lambas, functional programming and neat switches expressions 😀
Great article! Thanks :)
But do Java programmers wear glasses? 🤔
SCNR 😁 great article
Just a question!
Does google have to pay Oracle for using java or not in android?
Btw nice article
The Oracle lawsuit is about the APIs, not Java nor the JVM per se. Android doesn't run java, but the original Dalvik VM offered an API that very closely matched the Java one, even if the target object code was for a totally different platform.
The core fact that Oracle affirms is that an API is copyrightable, and that the copyright holder can block a use of it.
Well that's a separate story :D, and a separate lawsuit which is still not settled.
That's why Google is pushing kotlin ,maybe.
Kotlin needs a JVM underneath, though.
On Android it doesn't use JVM, but their own implementation ART (and DVM, formerly). The Java bytecode is transpiled during build to ART bytecode (btw I'm not an Android dev, so this might be a huge simplification).
But I think the whole lawsuit is about Android API being basically Java. It's not that like they said "you can write your Android applications in Java", it's "we have here a very familiar SDK that you can write your Android applications in, as easy as Java" :D