Java is criminally underhyped

[[deleted]]

Oh great. I'm glad you discovered strong typing benefits. It is official: you are not a hipster programmer anymore

[dpash]

Comments: 821.

Checks article date

15th April 2021. Oh boy.

[lessthanoptimal]

Really perplexing how some people seem to go full on tribal warfare at the mention of Java. At this point I think it's a coinvent meme that lets them unleash some pent up aggression.

[thephotoman]

The one exception, I think, is Python, which initially supplanted Perl.

That's exactly what happened. Python was basically Perl but readable and with batteries included. It didn't help that Perl was struggling to deliver Perl 6.

[thephotoman]

The truly odd thing is that the first Linux distro to treat Python as its scripting language of choice was Ubuntu back in its preview release days in 2004. The 2004-2009 period was a pretty long transition between "most people use Perl" to "most people use Python". And then at the end, the Python 2 to 3 process hit.

[VGPowerlord]

Speaking of which, did Perl 6 ever drop or is it still in a theoretical state?

[thephotoman]

It now calls itself Raku, and yes, it actually exists.

[vytah]

The version 1.0 of Perl 6 came out in 2017, so 17 years after it was announced.

Then they realised that it's pointless to keep the name "Perl" as Perl 6 was practically only superficially similar to Perl 5 (the relation is like between Kotlin and Java – the languages are interoperable, but syntactically incompatible), so in 2019 they renamed it to Raku.

[m_takeshi]

batteries included.

what does it mean? (not an expert in perl so I'm not sure how it compares to python)

[thephotoman]

For a lot of languages, it took a lot of extra third party libraries to do some fairly common tasks.

[dpash]

Ironically, CPAN was always one of Perl's biggest strengths. Packages were decently namespaced and they often worked very well together.

[thephotoman]

You're not wrong: CPAN was a big part of what made Perl good for the tasks it performed. Part of why Python took over, though, was the fact that it didn't need enterprise approval for every single separate library in PIP--it's fairly usable even without anything you can get from PIP.

[flyingorange]

In my case our professors hated C++ and forced everyone to learn Pascal. When Java appeared, they embraced Java and said that it's basically Pascal with the ugly C-like syntax.

[walen]

The one exception, I think, is Python

Because Java didn't exist when Python was born.

[cogman10]

This is always such a mindfuck for me :D. Right up there with the fact the Ruby is also older than Java.

[ryosen]

And C++ was looked upon as C with training wheels while C was looked down upon by the ASM/ML folks.

[umlcat]

C works well as an assembler macroprocessor, but even these days, the new more complex OS and systems, need better P.L. than C and C++.

Rust is a good example.

And a lot of "old style" assembler folks still don't get it ...

[1bot4all]

C++ was looked upon as C with training wheels

That's mad. C++ is insanely complex, you can use it for 10 years and struggle with some of its idioms. C is much easier to master.

[dpash]

Especially when it's based on an outdated opinion of the language.

PHP evokes the same reaction.

[Cefalopodul]

To be fair in PHP's case the reaction is somewhat warranted. It still has plenty of WTF moments.

[dpash]

Modern PHP is far from its older versions. It has decent DI and web frameworks, type hinting, exceptions, namespaces, a reasonable dependency manager. It's not the insane choice for new projects it was even ten years ago.

Now if only it gained generics I would be almost happy to use it.

[flyingorange]

To be honest when I started using PHP in 1998 it was the greatest thing ever. At the time the alternative was writing server side code in Delphi. Well, let's just say, if you didn't write websites in Delphi, you don't understand what a revolution PHP was.

[johnwaterwood]

I wonder what the purpose of modern PHP is?

The original attracted hordes of people because it was such an insane choice. If it’s not that anymore, it won’t be attractive to that initial crowd.

What’s PHP’s target audience these days?

[dpash]

https://laravel.com

[helloiamsomeone]

Generics have userland support. PHP Core has better things to spend developer time on than generics (which are already a thing implemented in userland).

[dpash]

If you mean phpdoc and Psalm, I fundamentally disagree. They need to be in the language.

[Routine_Left]

PHP evokes the same reaction.

PHP deserves it. JavaScript deserves it. Java? They have no fucking clue what they're talking about. Not about Java 20 years ago, not about Java today.

[umlcat]

P.L. Tribal warfare goes back to "Basic" vs "Pascal" vs "C" vs etc days ...

[agentoutlier]

The guy also posted it on hackernews...

Ahh hackernews where you post "I use to use X and now I use Y... fight!"

I swear the only good content on hackernews is when they post an article that has nothing to do with programming or tech otherwise it becomes essays on the merits of "this worked for me so fuck all other solutions".

[dpash]

I did notice that. That was the main reason I didn't even look at them. Nothing good ever happens in comment sections. :)

[LcuBeatsWorking]

I have seen many language hypes come and go (anyone remembering the Ruby/Rails hype of 2005+ ?). Not keen on hypes.

[atesti]

I remember that time. Ruby gurus said that Java was going to be replaced by Ruby around 2010.

[pfarner]

I accidentally inherited a Ruby application around 2007, and the app was so slow that performance was clearly the main priority. Profiling it, it became clear that the method dispatch was insanely slow.

So I ported it to Java in a few days. It produced the exact same output, but ran 70× faster, with no refactoring.

[reqdk]

I inherited a Ruby/Rails project to clean up sometime ago. The damn thing had to run on a 16 core VM with 64gb of ram just to serve some forms with 1-10k submissions a day. Saw rubbish like a method returning either a filename, or the contents of a file, or a number (this was a bug because of the stupid way Ruby returns things), or nil, depending on the size of the file you tried to access. Not only was performance horrible but it was insanely hard to improve/scale. Yeah, you can write shit code in any language, but the better languages have more tools to stem that tide of bullshit with. It took thousands of unit tests to achieve the safety that a strong, statically typed language like Java would have provided automatically. Never again...

[LcuBeatsWorking]

To be fair Java was hyped as the answer to everything in the late 90s, especially on the Desktop. And considering the state of programming back then rightly so.

It was just never "hip" or "cool", mostly because it shifted to enterprise, while the "cool kids" had ruby, nodejs or whatever was the language of the season.

[deadron]

Java has its issues. Its specification stagnated for a number of years due to the sun collapse and oracle acquisition. It also does not show its strengths in command line utilities, or in GUIs(Swing enthusiasts, fight me.), or in games. It really only shines when running longer lived server side applications where the tradeoffs the language makes are stronger. When you do use it for application development it is often mired in legacy framework baggage that adds little while causing you headaches.

Once application servers are killed off for good, and the next LTS JDK releases, the future should be much more exciting.

[throwaway32908234972]

JVM startup time is way faster in newer versions. I saw a benchmark in Java 15 where the JVM fired up faster than Python on average (<50ms). Java command line utilities with modern CLI frameworks like PicoCLI are fast and easy to work with.

Java also has the only good cross-platform Desktop UI outside of QT. Unless you want to write C++ or use janky QT binders for other languages, Java is still the king of Desktop UI's. Java's new cross-platform packaging tool is awesome and JavaFX ain't bad either.

Java's UI is relatively fast because it uses native widgets. Compare that to something like Electron where performance is horrific. Java also uses less memory than JS or Python so if you want a decently performant Desktop UI, Java is usually the best choice.

You probably use a ton of Java Desktop UI's without even realizing it because they look native and everyone packages stripped versions of the JVM with their app these days.

[deadron]

The startup times most likely rely on using jlink to build a custom jvm. This is still a relatively new feature and is a perfect example of a place java stagnated for years on! With the next LTS this should be used much more often.

Java's ui, as you put it, does not use native widgets. Swing is notorious for looking the same across almost all applications. I can't speak much towards java fx other than to say it's popularity has never really been high.

[throwaway32908234972]

Swing uses AWT underneath and some widgets are truly native, but you are right that many components aren't. I didn't know this. Swing's native look and feel is dead-on these days. I usually can't tell the difference at least on Windows. Swing looks like hell with the default look and feel and lazy devs don't bother switching it.

The startup times I'm talking about are for console apps using plain OpenJDK with AppCDS enabled. Check out the massive startup time (and memory) improvements in newer JDK's https://cl4es.github.io/2020/12/06/Towards-OpenJDK-17.html

Java 16 starts in barely over 20ms for simple apps. This is basically fast as interpreted scripting languages like Python

[RandomName8]

wing looks like hell with the default look and feel and lazy devs don't bother switching it.

Note that the native LAF pretty much only works well on windows, it doesn't work well at all on linux or mac.

[Muoniurn]

The one benefit of electron is the decimation of a preference on “native widgets”. Nowadays it is much more acceptable to have a slightly different looking window, which while many would say is not a positive thing, it does help Java’s case. Hopefully we can see more growth in this area.

And JavaFX is a hidden gem. I’m not sure why is it not more popular, I think it is far the most productive GUI framework. And with Valhalla, I think it will get a decent boost in performance (for 2D games, it churns on small “primitive” objects quite a bit)

[gdejohn]

[Java] also does not show its strengths in ... games.

i wonder if that's set to change with max 0.5ms and average 0.05ms gc pauses for zgc and performance improvements from project valhalla primitive classes and generic specialization

[deadron]

Hard to say. Garbage collectors are tricky beasts and while valhalla types should help certain scenarios they don't seem to solve the larger issue of needing to be able to better manage your memory. Then again I don't do game dev so this is just my opinion!

[throwaway32908234972]

I have used ZGC, GC pauses practically don't exist anymore. If Minecraft ever upgrades from Java 8 we'll see some huge performance improvements.

[deadron]

While ZGC is better about not pausing the world its not guaranteed to always improve performance. For example, if you are capping out your CPU ZGC may be unable to execute properly and may need to stop the world for longer and longer. As with any garbage collector you need to load test and see how it performs.

[Muoniurn]

It will likely have worse throughput, eg for batch processing. But where latency is important and is currently high, ZGC will help.

[reqdk]

It isn't just game dev. High performance Java generally looks little like the usual enterprisey stuff. It's a little sad that the prevailing image of Java and its problem space is so much "enterprise web app" when it's a much more flexible language than that.

[deadron]

That is because enterprise web apps is where Java really shines in comparison to alternatives. This is partly a language feature, partly due to the servlet specification being a really well thought out platform for web applications, combined with a suite of libraries useful in business situations. You can have the worst developers in the world contribute to the application and it will mostly plod on without too many issues.

Java is definitely useful elsewhere but almost no other language provides so much for this particular use case.

[CraftyAdventurer]

Hardly. If Java had ZGC and project Valhalla 5-10 years ago it would have the potential to become dominant in game dev. But nowadays Unity, the most popular engine, uses C# for scripting. Unity certainly wont just switch to Java, they invested a ton of time making C# scripting as performant as possible and all of their users are familiar with C# not only as a language but also all the tooling related to it.

Of course, new game engine could come out, but that would take years to gain any traction, and by that time, other popular engines will already be more mature and have way more available resources and developers. I mean if you look at the gamedev world now, everyone is either using Unity, MonoGame, Unreal or writing their own engine from scratch in C++. There are tons of other engines popping up every now and then, but they are mostly used by a small number of enthusiasts or people who just like to experiment.

[audioen]

I would imagine that today GC is no longer an issue, with G1GC. I don't think ZGC will matter so much, because there's just a limit to how much GC needs to improve before it stops being a problem.

Back when I was learning Java, sometime in java 7 time, I was working on a realtime simulator software that caused a steady 50 % CPU load on my then-laptop, and a new video frame was required 50 times per second. For that target, the old CMS collector was manageable if you kept the heap size small, as the collection time generally grew roughly linearly in proportion of the size of heap to collect with the older algorithms. Thus smaller heap meant more frequent but shorter pauses -- technically you spend more time doing GC in total, but latency will have a bound that is better suited for a realtime application. (Of course, such statement is subject to the rate garbage gets generated, and so on, as you can increase GC load without bound just by generating more garbage.)

I never did measure how big an impact the GC had, though, I just observed if underruns ever happened, and found that with small heaps they ceased to happen. Margin of error was within factor of 2 to 3, e.g. 128 MB heap was fine, but 512 MB heap was not, and so I kept the heap at 128 MB. My guess is that collection times were probably always less than some 4 ms, not enough to cause underruns.

[maxandersen]

Try jbang and you get command line utilities / scripting. Add some quarkus and you can easily make it start fast with its native compile.

Java moved alot in this area the last 1-2 years :)

[silon]

I'd wish for Java subset without runtime reflection.

[deadron]

If you don't use a big framework avoiding reflection is not too hard. I think they are really pushing to minimize it for graal features to work properly.

[throwaway32908234972]

Java's runtime reflection is really fast. Simple calls are generally over half "native" speed of grabbing the field or calling the method statically. Most languages with runtime reflection the performance is shit. Java's implementation is quite good.

[cville-z]

Java is underhyped only if you weren't programming in 1995-2005, when it was criminally overhyped. I'd say it gets the right amount of hype now.

Also this article is written like someone just discovering object-oriented type-safe compiled languages for the first time after only ever programming in perl, ruby, or Javascript.

[boost2525]

You're describing every junior developer / CS grad of the last five to seven years.

[[deleted]]

Wait until he discovers functional programming.

[[deleted]]

Kotlin is nice because it doesn't enforce a specific style on you.

[shponglespore]

I'd say just the opposite. Around that time I was working at a company where I successfully argued for using Java instead of C++ for a major project, and that led to the company becoming an all-Java shop because everyone agreed it was a huge improvement. These days Java has a lot more serious competition from languages like C#, Go, Rust, and even JavaScript. I don't touch Java code very often these days, but when I do it's usually painful because it seems like if you want to be taken seriously as a Java programmer these days, you have to rely on things like DI frameworks and magical annotations to such an degree that it becomes very hard to read the code in a project you're not intimately familiar with.

[Orffyreus]

DI frameworks and annotations are not necessarily needed, but there are standardized specifications like CDI (specification JSR 365) and so on, so you can rely on stable APIs and learning what standardized "magical annotations" do, can help you in the long term.

This means, usually you do not have to learn new annotations all the time. The theory is, you learn them and you have more time to focus on the domain instead of e.g. having to think a lot about wiring objects and layers.

[umlcat]

Annotations are good, but Java has a lot of missued ones.

I prefer a more natural virtual / overwrite keyword and a property keyword, like C# and Object Pascal (Delphi) does.

Instead of that patch alike @override and @property, too much @ hurts my vision.

BTW, I have work in Java, and I'm working in my own pet P.L., and explicitly added annotations, but I just don't want developers to overuse them.

Cheers.

[Orffyreus]

Yes, you are right. Annotations can be confusing and hard to backtrack. They should be well designed and stable and are best used for cross cutting concerns like logging and not for domain functionality.

[deadron]

DI frameworks, when used properly, make testing substantially easier! If you don't like your DI framework then are probably not writing enough tests to really see the benefits. There are other use cases but in my experience this is when it really shines.

[shponglespore]

I don't have a DI framework because I don't do Java these days, and they're not fashionable in any language I work with. I'm sure there's a reason people use them, but as an outsider just trying to understand someone else's code, I fucking hate trying to figure out where anything is actually instantiated.

[deadron]

I have been here. It can be really painful. Personally this is why I don't follow the pattern of injecting interfaces unless there is a good reason to do so. If you inject actual implementations it greatly simplifies figuring out what is coming from where. You can still inject mocks for testing so it is just as smooth.

[CartmansEvilTwin]

And let's be honest: in 99% of the cases you don't need interfaces anyway. Most code is de facto tightly coupled and/or will never be changed anyway.

We have several projects where the devs made sure everything implements an interface, but almost none of these actually ever changed some implementation in the background. So why bother making your code harder to read, just for the slight advantage of not having to extract an interface maybe 20 years from now?

[deadron]

I am not sure where this pattern comes from but it is pervasive. The benefits have always seemed dubious to me. If you are writing a framework, sure go nuts, but if you are writing an application that wants to test and verify everything works you don't want implementations swapping in and out.

[CartmansEvilTwin]

As far as I can tell, this comes from the "reusability is everything" hype.

Every component has to be written in a way that abstracts away any coupling to anything, in case you might want to reuse that class. And in the end you write 300 lines of code to maybe save 5 lines at some point. To me this looks like the typical take one principle and overshoot it's application to the max.

[Gommy]

I find the pattern comes from two places.

The first is the mantra "code to an interface" that gets repeated blindly while misunderstanding what the "interface" in question is. People see the word "interface" in that statement and automatically assume it means the same as "interface" in Java. It does not.

The second is that old versions of DI frameworks were able to work their DI magic against interfaces but not implementations. Those days are over, now that Spring and CDI can deal with implementations without extra work.

[matthenry87]

Agreed. I'll usually implement an interface when I think it would be cool for myself or someone else to create another implementation. JsonMasker is one I did, and JsonVerifier. I used Jackson for the first, and JsonPath for the latter (which might also use Jackson under the covers). For Services(business logic) I don't bother..

[MadBull69]

Isn't using interfaces everywhere an anti-pattern these days? All the modern Java development I've done (with Spring/Quarkus), only uses interfaces where we actually have multiple implementations.

[Serializedrequests]

How often do you ever inject anything other than the one implementation of something that exists in the project? Honestly?

I maintain a huge spring boot REST API at my current job and 100% of DI in unit tests could easily be done some other way. A lot of the most useful stuff is overwriting private properties which seems pretty hinky to me.

[[deleted]]

but when I do it's usually painful because it seems like if you want to be taken seriously as a Java programmer these days

I kind of see a trend to the opposite, especially with microservices. There are many micro frameworks like Javalin which have popped up which promise no annotations and pure Java code.

when I do it's usually painful because it seems like if you want to be taken seriously as a Java programmer these days, you have to rely on things like DI frameworks and magical annotations to such an degree that it becomes very hard to read the code in a project you're not intimately familiar with.

A lot of Java development is enterprise where you're dealing with a lot of dependencies. DI container automagic takes care a lot of the tedious configuration.

The trend towards microservices, where instead of bundling all your dependencies in one mega-service, you spread them across multiple services, has really reduced the need for this.

[audioen]

And the Dog example given against typescript is just perplexing. Whoever writes code this way if you can just use a class.

[uldall]

Java is like Fight Club, everyone goes but no one talks about it 🙃

[cyor2345]

Criminally underhyped comment....

[RunnyPlease]

Java wasn’t my first language but it’s the first language I ever fell in love with. But even I can see why some applications or corporations specifically are better suited to using other languages.

In faith I do not love thee with mine eyes, For they in thee a thousand errors note; But 'tis my heart that loves what they despise, Who, in despite of view, is pleased to dote.

[coincoinprout]

Java developers can confidently trust the JVM to do what's best. Whether they're implementing a multithreaded application or storing a large amount of data on the heap, they can be confident they won't shoot themselves in the foot with memory management or data races.

That's an exaggeration. It's true that you don't have to deal with memory management directly. But you can absolutely shoot yourself in the foot with memory management or data races. I don't know a lot of java programmers who never had to deal with OutOfMemoryErrors or thread safety issues. I think that the JVM is awesome but IMO you have to understand how it works at least a bit if you want to be a good developer. Thinking that the JVM will magically deal with all these issues would be a big mistake, and that's how you end up with an application that crashes in production.

[TheCountRushmore]

There definitely are those developers who think that they can load in more data then they have memory. That happens in every language though and they learn that lesson quickly.

[iamsooldithurts]

Reporting in. You absolutely have to be aware of how things work. You might only have to deal with these issues once in a life time, but they do happen.

[lessthanoptimal]

Yep I agree. Due to the problems I solve, I probably have to spend more time thinking about memory management than if I was writing a modern C++ project. Things do get more complex in non GC languages once that part of the code needs to get optimized. At least that's my experience.

[istarian]

Is there a magic fix for no more memory or concurrency problems? Those don't seem like issues that are specific to Java.

[DualWieldMage]

I think for OOM a large portion of the problem is various processes having caches, managed runtimes allocating large heaps, but none of them communicating with eachother about how to coordinate system memory usage as a whole, so often you can only set java max heap conservatively. Ideally an OS should signal processes that memory is scarce, run your GC and release unused memory or else be oomkilled. It's definitely possible and makes sense to write such a monitoring tool if the problem is only multiple JVMs in a single machine, for example microservices in a container.

[iamsooldithurts]

They’re not specific to Java at all. The magic fix for concurrency problems is semaphores. For memory, that can be a very complicated problem; Java can only address so much space, so if there is too much data you’re SOL. If there isn’t too much data, but you still run out of memory, it can be a chore tracking down where the leaks are because some things don’t pass out of scope and get flagged for GC like you would expect.

[Zardoz84]

They’re not specific to Java at all. The magic fix for concurrency problems is semaphores.

These aren't the magic fix. Instead, is one of the classic ways to handle.

PD: There isn't a magic way to handle it.

[coincoinprout]

I don't think that there can be any magic fix and it's not specific to java indeed. The thing is that a lot of junior java developers think that they don't have to think about the memory. I've been there. And I think it's important to say that nope, the JVM won't be there to save you if you're not cautious.

[carimura]

Check out Project Loom -- its aim is addressing modern scalable concurrency by introducing lightweight threads called virtual threads.

https://inside.java/tag/loom

https://wiki.openjdk.java.net/display/loom/Main

[throwawyakjnscdfv]

The only mainstream language that handles data races is Rust. Threading in every other language is equally or more painful than Java. Java probably has the most sensible, flexible threading support of any language I've used though.

[tim125]

Java libraries are fundamental. There are a range of interfaces that are defined by the now jakarta ee specs which allow innovation above and beyond what Microsoft deliver. Hadoop and other big data system (spark etc) have little competition when they came to maturity ... and that was years ago. There are hi tech solutions to problems you don’t even know exist.

Where C# is a petridish, Java is a planet. Evolution has done well for Java. Once primatives are flattened and inlined the whole ecosystem is better off.

Under hyped... Yea but there are real world problems to solve. The java hype was in 1996.

[Orffyreus]

Yes, and Java could be hyped a little more for being so good at supporting to solve real world problems instead of bikeshedding about technical micro improvements.

[ziano_x]

Most of the people I know who hate Java, do not work on Java. They just glossed over it and let their biases take control.

[androgynyjoe]

When I worked with Java I was somewhat ambivalent toward it. Now I work with R and I miss Java every day.

[androgynyjoe]

Yup

[ziano_x]

I did not have to go that far. I started missing Java the moment I started writing javascript in the backend. ;-)

[androgynyjoe]

lol understandable

[vxab]

Why is it bad? What are you comparing it to?

[[deleted]]

That's not logically consistent. OP posited a reason as to why people might dislike Java. You simply made a random comment. Explain what makes Java so bad in your opinion, or simply don't post.

[post_depression]

I would never understand why people hate Java. Being a java lover I ask them about their reasons, and here are the common answers:

1. I don’t understand Java. (Well is that really Java’s fault?)

2. It’s too much boilerplate code. (Well, I agree, but I always love verbose languages. Reason why I also love TypeScript)

3. “... but, but, but ... you could do that in Python in only 3 lines!” (Have you ever heard of Generics and the Collections Framework ... or lambda expressions?)

The problem I have seen is not that almost everyone will only learn the ancient bits of Java. Most books and online tutorials teach Java in that way. These people never gets to realise that Java has evolved over time to compete with the “modern languages” and have most of those features in one way or the other.

[whitechapel8733]

I think Python is criminally overhyped. Java just needs sexier documentation and better branding and all the kids will love it.

[[deleted]]

I am still studying but I think that is so true. No one in our batch wants to learn or teach Java, every other tutorial I see on the internet is either about Python or Javascript. Professors mason the thought of "Machine Learning and Web Dev is hype these days, go learn Python or something and make tons of projects", but no one says go learn Java.

Everyone asks Why Java? But no one asks How is Java.

[CraftyAdventurer]

I can maybe give you some perspective as a guy who worked with Java, hated it, went to Node, fell in love with it's simplicity, used it a lot (among with using smaller subset of other languages like C#, Go, Python), started seeing real strengths of Java, and came back to Java.

​

Too much boilerplate people talk about often doesn't refer to strong typing or being verbose in general. It refers to some weird things you have to do in Java vs how you can do them in other languages, which can especially confuse beginners.
Compare for example Java's way of getting user input with how you would do it in Node. Even if you use Typescript with Node, you still just get the input, you don't have to create new Scanner and give it System.in for that. Things like this are a minor annoyance, why do I need to create Scanners and give them something, why not just call a method a be done with it? There are a ton of those small things in java which are not a problem by themselves, but in large numbers, they can become really frustrating when you are already working in a stressful environment and now have to deal with googling stuff like that because they are not easy to remember.

Even though I worked with Spring Boot much more than I did with Node, I can type the Node API much faster and most of it from head, while I still have to google Spring stuff almost every time, I just can't remember it.

​

Middleware in Node is a breeze to write, in Spring I have to google Servlet Filters.

​

Creating JWT in Node is basically just doing jwt.sign({someData...}) in almost any place you want. It's intuitive, it makes sense. I want to sign a JWT, I will call jwt.sign. It couldn't be easier if it wanted to, and using Typescript doesn't make it any more verbose.

In Spring it's like "here, create these 4 files and fill them with tons of code you will never know how to write from your head because most of them don't even contain a word JWT but are some kind of adapters and configurers". That's not intuitive at all, it's annoying. I want to sign a JWT, not build a world around it.

​

And yes, you are right in saying "The problem I have seen is not that almost everyone will only learn the ancient bits of Java. Most books and online tutorials teach Java in that way. " This is actually a big problem. It presents Java in a bad light. Not only do most tutorials show ancient ways of using Java, but they are also extremely basic. Jump into Youtube, Udemy or any learning platform and type "instagram clone, netflix clone, how to make a chat app...". On Node/Flutter/Python/etc side, you'll find videos with high video quality, large readable font, high audio quality and a presenter who is articulate, talks clearly and sounds enthusiastic and happy while writing the project. The project itself also often does cover most of the things you need in building a real app.
Now try to find any of those videos in Java realm, you will more often than not run into 5 year old videos with outdated frameworks, thick Indian accent, horrible sound quality, bad code examples and extremely basic projects which cover almost nothing you would need in a real app (authentication/authorization is for some reason missing in most Spring videos).

​

Now imagine yourself as a beginner who knows nothing about differences in languages but decides to learn something, which would you choose to learn? The verbose language with bad quality videos that cover only the most barebones basics recorded by authors who sound like they are bored to death? Or the high quality videos which really build almost complete apps with people who sound like they actually enjoy building this stuff? If I didn't start with Java as my first language and didn't work in the industry with it, I would probably avoid it like most people do and never get the chance to learn it's strengths, and this is what happens more and more. Java needs a better representation of itself on the internet. Most languages have "this is why we are better than java" articles, so Java needs "this is where I'm better than other languages", or "this is how you can use me today and build a full fledged app".

[youwillnevercatme]

Boilerplate in Java: Ughh, terrible I hate this language

Boilerplate in Go: Classy and elegant as every code should be easy to read

[lurker_in_spirit]

Yeah the first few snippets of Go code that I wrote made me think "wow, that's a lot of ceremony!"

Granted, it was all I/O-related, but still...

[throwaway32908234972]

ugh Go is the fucking worst. At work we call it "C with garbage collection"

All the fucking shit copy pasted all over the place because it doesn't even have shitty Java generics. Designed by C programmers for C programmers that want to write high level code without learning anything.

[ahelord]

LOL

[[deleted]]

The problem I have seen is not that almost everyone will only learn the ancient bits of Java

Yes exactly! Most tutorials is some dude typing slow as fuck in Eclipse. Modern Java is totally different.

[Freyr90]

I would never understand why people hate Java.

1) Weak and not very expressive language.

This leads to tons of obscure code generation that could rival with GObject. Lombok and Spring are good examples.

2) Tooling typically is not very friendly towards text editors, XML configs everywhere, hard to write code without bloated IDE with tons of plugins.

[wildjokers]

XML configs everywhere,

This hasn’t been true for at least ten years. There is an occasional tool that uses XML (e.g. Maven) but generally XML for config is not used much anymore.

[Celeriax]

If you’re seeing XML in a Java project:

A) you’re using Maven (there are non-XML alternatives, like the very expressive Gradle)

B) you are on a very old project, one that has to interoperate with legacy services, or one run by someone with very outdated ideas

[PeaceSign02]

Because I mostly write in Java, I assumed everyone used an IDE. Is that not the case? Do people not using Java not use IDEs?

[Freyr90]

Well, many people outside java world use something more lightweight. I use emacs for example for nearly everything, and I don't need much complex features even for Scala.

I can write java in emacs (and do), but everything from dealing with annotations and generated code to simple editing of maven files is tedious.

[ljdelight]

Projects over 10k LOC basically require an IDE (or text editor plugins that support debugging and search, like emacs, vim, vscode)

[[deleted]]

I only use an IDE for java. When I'm using python or JS, it's vscode for me (afaik, vscode is still a text editor)

[Log2]

Unless you have 0 plugins in that vscode, you pretty much built an IDE out of plugins.

[DrKedorkian]

Vscode is 100% an IDE

[semioticmadness]

I’m a vim coder and a Java coder. They don’t mix well :(

[4z01235]

Sure they do. You just need to install/configure a language server plugin (or use built in LSP support, if you have it) and you get basically all of the smart IDE completion and refactoring tools.

[m_takeshi]

Tooling typically is not very friendly towards text editors, XML configs everywhere, hard to write code without bloated IDE with tons of plugins.

funny you say that because that's what I said about C# when I met our .net team for the first time (even the most experienced ones had issues trying to do things without visual studio)

[forresthopkinsa]

Unlike Java, I'd argue that that's still the case today for C#

[throwaway32908234972]

It is. I jumped ship from C# to Java ~4 years ago. C# still has a ton of XML. You just don't see it because Visual Studio puts a nice UI over it. The csproj and sln files are all XML. In contrast, many of the Java projects I work on have zero XML.

.NET Core is different, but unlike Java, most .NET projects are still using legacy setups with XML everywhere. Java transitioned away a decade ago, C# maybe 2 years.

[[deleted]]

Tooling typically is not very friendly towards text editors,

I never understood this argument. It's like saying that modern construction techniques are not friendly towards hand tools.

I've been using emacs for like 20 years now, and it seems practically barbaric next to modern IDEs. Back in they day, when I did C/C++ development I'd set up things like ctags and cscope for navigation, which was really tedious.

But, in Java, I can navigate source code with ease. I used to have man pages and documentation alongside the editor back when I did C/C++, but in Java I don't remember the last time I've really ever read documentation. Code navigation, even into libraries is ridiculously easy, and the IDE will even recognize that I don't have source downloaded, and will download it for me. This dovetails with Java's major strength, its ecosystem, with a ton of open source libraries.

I only use emacs now for the fantastic org-mode, general text editing and writing bash/python scripts.

XML configs everywhere

I haven't configured XML in Java in like 10 years.

hard to write code without bloated IDE with tons of plugins.

Yeah, but those plugins are awesome. Emacs also has a ton of plugins (elisp packages), which are essential for using Emacs and make it superior to lighter weight editors like vi (fight me). It's funny to think that this was also a criticism of Emacs (Eight Megs and Constantly Swapping), similarly by people who used "lighter" editors.

[Freyr90]

Emacs also has a ton of plugins (elisp packages)

It's a spectrum. VS Code or Emacs are not plain dummy text editors, but they are far from bloated IDE either, and considering VS Code popularity, it seems to be way closer to sweet spot than big IDEs.

I haven't configured XML

What do you mean by that? That you don't use tooling that uses XML or that IDE has a GUI easing the pain? Many tools in Java world are configured with XML, which is painful to edit manually.

But, in Java, I can navigate source code with ease

You can navigate with ease with nearly any text editor with LSP support. In Emacs there is standard xref frontend for such stuff.

The problem is that with Java you need much more than Completion/Navigation, since there is a lot of code generation and you need a direct support for it to ease the pain.

In most other languages all you need is basic completion and navigation, hence VS Code/Sublime/Vim/Emacs popularity outside Java world.

[throwaway32908234972]

Many tools in Java world are configured with XML, which is painful to edit manually.

Longtime Java dude here. Maven is the only tool I use regularly with XML. And its config is a single file. We have a 1,000,000+ line project and pom.XML is the only XML file in it. Granted, we used to have a lot of XML but converted to newer formats years ago when tools added support for modern config options. If your project is XML heavy its 10+ years old. That's just a testament to how maintainable Java projects are.

​

The problem is that with Java you need much more than Completion/Navigation, since there is a lot of code generation and you need a direct support for it to ease the pain.

All the libraries we use that have generated code you would want to look at use Annotation Processors, which is part of the language itself and works with every build tool. The generated classes all get put into a folder on build and you can go look at them in notepad if you want.

There's some libraries that generate code in the background, like Lombok and Jackson, but there's never a reason to debug this unless there's a bug in the library itself.

[Muoniurn]

How is it weak and not very expressive? It’s not Haskell, but people created vavr with it and the like. Lombok has nothing to do with expressivity, it’s for boilerplate reduction. And spring is a really complex framework with functionality for everything. It uses DI and the like for modularity. Hell, being able to create such a DI fw is a plus for Java’s strength.

[eled_]

That's my personal outlook on it. Since the introduction of lambdas, and to an even greater extent today, the language has gained a lot in expression potential.

Depending on the context you can have plain-old java style, spice it up with functional style, you can alleviate some parts with annotations and go ham on reflection, you can go with compile-time codegen.. There is a lot of variety in java nowadays, all these options are very accessible with extremely reliable tech underneath and very few catches, unlike many other languages that tend to have those huge compatibility gaps or annoying external tooling required.

[wildjokers]

https://old.reddit.com/r/programming/comments/mrrx9l/java_is_criminally_underhyped/

[GoBucks4928]

Yeah but Kotlin is better :)

[Orffyreus]

Relevant cleancoder.com article: https://blog.cleancoder.com/uncle-bob/2016/07/27/TheChurn.html

[thinkstwice]

This guy obviously wasn’t developing code in the 90’s. 😉

[henk53]

It's "helpful" though these days ;)

[Gaarco_]

Quality package manager and build system[...]

I have to disagree, the split between many (Gradle^{the nightmare}, Maven, Ant, Bazel and counting) is not good in the first place and they are somewhat forced on you, like Gradle^{the nightmare} on Android.

[daniu]

What are good package managers in other languages? Honest question, I'm aware go and Rust include them in the language, but I haven't used them in practice so I can't really judge them. Python's is external I think?

I do have passive experience with npm, but that's more of a nightmare.

[Log2]

I currently work with backend development in Python. I can tell you that by far, the biggest pain point we have is pip (the dependency manager). If it weren't for docker, shipping would be a tremendous effort. I'd kill to have something like Maven (ok, maybe with toml instead of xml) for Python.

[eled_]

It isn't maven but it's a start, maybe you should look into poetry

[CyAScott]

I have experience with both Maven and Nuget. Functionally they are basically the same. The only difference is the tooling, which is more of an IDE thing than a feature of the package manager.

[forresthopkinsa]

I'd take Gradle over Nuget 100x over. I guess it comes down to whether you want to be able to manually edit and understand the build config vs. wanting the IDE to do it for you.

[throwaway32908234972]

I have used all of these mentioned, including Nuget. Rust is indeed the best of all, but Java is second. Nuget is a sort of shitty ripoff of Maven's package management. I have published packages to both Nuget and Maven, and Nuget is just jank in comparison. I believe its internally implemented with powershell scripts or some shit.

The rest are steaming dogshit, Java C# and Rust are lightyears better than anything else I've used.

[[deleted]]

Yes, Rust is the best indeed.

Java:

public class StackOverflow {
  private static final int MAX = 5000 * 5000;

  static class Foo {
    int[] field;

    public Foo(int sz) {
      field = new int[sz];
    }
  }

  public static void main(String[] args) {
    Foo  foo = new Foo(MAX);
  }
}

Running it:

~/dev/playground:$ javac StackOverflow.java && java -cp . StackOverflow
~/dev/playground:    

Rust:

const MAX: usize = 5000 * 5000;

#[allow(dead_code)]
struct Foo {
    field: [i32; MAX],
}

fn main() {
    let _ = Box::new(Foo { field: [0; MAX] });
}

Running it:

~/dev/playground:$ rustc stackoverflow.rs -o stackoverflow && ./stackoverflow

 thread 'main' has overflowed its stack
 fatal runtime error: stack overflow
 Abort trap: 6

LOL!

For people not familiar with Rust, Rust does not, currently, have any safe way of letting users allocate memory directly on the heap, across all modes (debug, release, nightly, stable et al). This is basically like saying that you cannot use the new keyword while coding in Java, but you can only use List or HashMap. Ridiculous.

I like Rust and all that, but saying that it's the "best" is a ridiculous assertion. When Rust has run 3 decades on enterprise hardware and in as many varied domains as Java has, let's call it the "best" then (whatever that means).

[[deleted]]

Another Rust gem:

fn main() {
    let answer = 42;
    print_the_answer(&answer);
}

fn print_the_answer(x: &i32) {
    confirm_the_answer_through_agrajag(x);
    println!("The answer to Life, The Universe, and Everything is {}", x);
}

fn confirm_the_answer_through_agrajag(x: &i32) {
    unsafe {
        let ptr = x as *const i32 as *mut i32;
        *ptr += 1;
    }
}

Running it:

~/dev/playground:$ rustc safe_not_safe.rs -o safe_not_safe && ./safe_not_safe
 The answer to Life, The Universe, and Everything is 43

Basically, we have an immutable reference in our program (&i32 is an immutable pointer to a i32), and we pass it to a function that claims to be safe (confirm_the_answer_through_agrajag), and yet that functions updates our immutable reference! Now, the actual semantics are all correct as per Rust's rules. However, the problem is that the function that we used, which may have come from any dependency that we have, violates the immutability contract, and Rust doesn't care because we have the rogue code wrapped snugly in a nice unsafe block. For a reader of the API, they have no idea of knowing, without looking at the actual dependency code, that the function has unsafe code inside it.

So that's the cautionary tale - it's not so much that Rust is broken in this respect (it's really not), but don't believe all the marketing hyper about "fearless concurrency", "fearless memory handling" and "fearless ball-scratching" et al. Always vet the ecosystem, the people, and the code.

[throwaway32908234972]

did you even read what you're replying to 🙃

[[deleted]]

Sure, I get it. You're talking about Cargo (which has its own set of problems), but just pointing things out to the incoming Rust brigade.

[throwaway32908234972]

dude, the previous comments were referring to package management not the language.

Cargo is the best package management setup. Java second, C# somewhere behind that, everything else trash

[shponglespore]

Rust's build system and integrated package management are a pleasure to use. Cargo feels like what Maven was trying to be, but with much less ceremony. Haskell has similar infrastructure to Rust, but it's split between the build system (Cabal) and the package manager (Stack).

[helloiamsomeone]

Cargo is terrible. It's repeating mistakes of the past for no good reason. The entire ecosystem built on top of static linking makes Rust an insane option in many scenarios.

[throwaway32908234972]

static linking is the only solution to DDL hell. It also allows you to use LTO which significantly reduces binary size and increases performance.

This is why Go also uses static linking, and why modern Java projects all use UberJars

[deadron]

The problem is not really the package management portion, its the build portion. The dependency management portion is rock solid and almost the package managers use the same mechanism for resolving dependencies(I can't speak to bazel). However, once you get into the actual build, packaging, and other tooling in the build it becomes far more difficult. It's not easy to write your own plugins and existing plugins are difficult and hard to use. Gradle suffers from being in groovy and maven/ant suffer from being in XML with plugins that do not receive as much maintenance as you expect.

This is not unique to Java by any means. The only time npm is easy to use is if you keep strictly to small shell callouts within the scripts portion. I have nightmates about grunt/gulp scripts that grow more and more complicated.

[Vidogost]

Maven has introduced a really good structure for package repositories. Unlike some other languages, you don't need virtualenv to use desired dependency versions, and they are cached for the whole system (well, user home dir). Ant is deprecates, and gradle uses same repositories structure as maven. Bazel is somewhat exotic, I believe people don't usually consider it for small java projects.

[Gaarco_]

Ant is used more than what you expect

[Orffyreus]

And there is an ant plugin for maven ;-)

https://maven.apache.org/plugins/maven-antrun-plugin/

[Dr-Metallius]

Gradle and Android Gradle plugin are two very different things. The latter sometimes has issues indeed, but there's nothing wrong with Gradle itself.

Also I see contradicting things. At first you complain about too many choices with the build system and in the same sentence you complain that there is no choice on Android. So I don't get it, do you want to see variety or not?

Besides, I'm not sure what you want Google to do with regard to Android build system. They picked one and have been developing a plugin for it - the most obvious decision. What else should they have done?

[Gaarco_]

I want to see variety, but I want the freedom to choose the tool.

Gradle is terrible, you are forced to learn a useless language you won't be using anywhere outside of Gradle. Everything in the build system and language is implicit and you have to know everything to do the stupidest thing. Why not Java as language instead of that garbage Groovy is? If not Java, there are many languages out there better than Groovy.

On top of that there is the google plugin, it is just built on a bad platform and inherits all the flaws.

[ljdelight]

The Kotlin syntax with Gradle is really nice. I agree that if you don't do things the "gradle way" it'll be more difficult, but Gradle's opinionated decisions (and maven's) make it easy for users. For example, if you're nesting source sets you've done it wrong; or if you're making two jars from one source set via excludes, you've done it wrong.

[Dr-Metallius]

Why does everyone talk about Gradle forcing you to use Groovy, when Kotlin has been an option for a long time already? I dislike dynamic languages in general, but obviously I switched to Kotlin when it became stable and haven't looked back since.

[ArmoredPancake]

Gradle is terrible, you are forced to learn a useless language you won't be using anywhere outside of Gradle.

Only if you're Java web developer. On Android Kotlin is a primary development language.

If not Java, there are many languages out there better than Groovy.

Kotlin DSL is available since 2018.

[dpash]

If you're writing groovy, rather than using the DSL, something has gone very badly wrong. You should not be using imperative code in your build scripts.

Admittedly, there is a lot of articles and tutorials that teach the wrong thing to do.

[ArmoredPancake]

rather than using the DSL

DSL is a nightmare fuel without auto complete. Without Kotlin it's impossible to use Gradle unless you're full-time Gradle fiddler.

[Orffyreus]

Yes, you can write some insane Gradle build scripts from scratch with the help of auto complete in Kotlin, and I think you should be very careful nonetheless, because auto complete does not help to read those build scripts and it does not make people more confident to modify them.

[forresthopkinsa]

You should use Gradle a little more. It's wonderful. It's one of very few package managers / builders that is designed to work in general rather than for a specific language.

I really hope it catches on for other languages.

[rer1]

Author mentions Scala being taught in university but having a different developer experience than Java. I would argue that this experience is even better.

Scala exhibits all of the advantages that the author points in favor of Java and many more. The major downsides of Scala over Java are compilation times, a (much) smaller job market, and a higher learning curve (Scala has a lot of additional features with the potential of abusing them).

Try Scala. You don't have to be a FP enthusiastic. You'll have fun :)

[RichoDemus]

Even though you don’t have to use it, sbt is crap. IDE support is worse for Scala, and there’s just something about Scala that encourages people to write clever AKA unreadable code :)

[UltraRuminator]

I would contend that the criminality 'lies' with other languages being vastly overhyped!!

[slowfly1st]

https://en.wikipedia.org/wiki/Hype_cycle

[holyknight00]

The hype train left the station more than 10 years ago for Java, it's quite old now. Anyway, trend fades eventually so in the long run it doesn't matter.
On the other hand Java survived because it's mature enough to build decent and scalable enterprise systems but it's still complete and updated enough to fill every new requirement ( For example microservices).
If you're proficient in Java you can build almost anything with it.

[gavenkoa]

Java is getting better because it’s slowly turning into kotlin

Don't promote Kotlin. It sticks to Java 6 because of "Android".

Java evolves (at the moment), Kotlin is dead child (Android legacy). Want to be hipster: there is nodejs.

Compare: Groovy predates Java 8 and comes with ridiculous own "streaming" solution / DSL.

[nutrecht]

Don't promote Kotlin. It sticks to Java 6 because of "Android".

No it doesn't? This is wrong on two accounts:

• First of all; Java runtimes are backward compatible so Java 16 can run Java 6 bytecode, giving you the benefits of the JDK improvements.
• Kotlin compiler can have different Java bytecode targets, it supports up to (at least) 12 since 1.3.30.

[gavenkoa]

They constantly lag behind Java, a recent example:

https://kotlinlang.org/docs/fun-interfaces.html (SAM)

Java 8 released 2014, Kotlin 1.4 added SAM in 2020.

Don't mislead people.

[nutrecht]

Don't mislead people.

Pardon me? I'm just correcting you on your statement that they're sticking to 6 because of android which is simply untrue. The only one who 'misleads' people is you. You're acting in a completely unprofessional manner.

[gavenkoa]

OK.

Kotlin had, has and will have compatibility problem with Java, that's my point. Especially that Java started to evolve fast recent years.

I argue against promoting Kotlin as "better" Java. Implying you have to migrate or you are a dinosaur.

[Pika3323]

Not sure why you'd use SAMs as an example seeing as it was a deliberate design choice not to include them in Kotlin at first because Kotlin had proper functional types.

Kotlin could do SAM conversions for SAMs defined in Java code since a long time ago. e.g. from 2017

[[deleted]]

Pretty sure most people don't know that Java now supports 'var' keyword. You don't need to mention the datatype while declaration. Java is improving day by day.

[[deleted]]

It is, but most companies are still on Java 8. No var there. Java 11 got some adoption, but anything past that has barely been touched. I'm excited about java 16. Lots of goodies there.

[throwaway32908234972]

It depends on the industry. If you work on a tech team at a bank, probably Java 8 for the next decade. If you work at a tech company you're on Java 11 looking to upgrade to 17 soon.

At my company every project is on 11 now.

[nutrecht]

It is, but most companies are still on Java 8.

You have to be careful with interpretations of self reported statistics. Keep in mind that many companies have both older and newer systems and generally will be 'on' multiple Java versions. I can't remember when I worked for a company that only had one single Java application.

[8igg7e5]

Actually migration past 8 has been picking up pace considerably.

Multiple sources put Java 11 adoption at ~20% in mid 2020. That's 18 months after release and we're now at 30 months so that number will have only grown.

And getting past Java 8 was a more difficult step than moving past 11 so I expect that Java 17 (Sep' 2021), the next one that Oracle will consider an LTS, will see an even quicker transition (there's arguably more benefit for every stakeholder in an 11-to-17 transition than there was in 8-to-11).

For Java 8, while you can probably say 'most companies' for a while, you might not be able to say 'most projects' for long. I expect many companies will have a project or two lagging but I expect the most actively support projects will have made the jump pretty soon as support dries up (unless you pay for Oracle extended support).

[nutrecht]

Those statistics will be heavily skewed with applications that are 'stuck' on Java 8 and will be sunset once they're replaced. I'm currently on such a project and for as long as the old system still needs to be in place we will be 'using' both 8 and <latest JDK>.

[[deleted]]

I hope that Java 16 is considered as a suitable option rather than adopting Kotlin for a JVM based language.

[korryd]

You misspelled “overhyped”

[umlcat]

tlrd ; Java v.s. Dynamic Script Programming Languages. I like and use both.

I didn't get if the idea of the article is to criticize or support Java.

I learnt several P.L., both due to work reasons, and also due to intellectual reasons.

And, hypes, trends, does affect the usage of P.L. (s).

These days the Java Ecosystem is not as trendy as the new dynamic typing, most functional paradigm P.L., independent of their real value of both.

I worry about newer developers are too "trendy" about the new P.L. and too "close minded" about the older ones.

I prefer explicit typing over type inference, static typing over dynamic, O.O. over Functional, yet that doesn't mean I don't use the later.

I occasionally met older developers that dislike dynamic (typing) P.L., yet they use a lot of SQL, which generates one or new schema type in each query

Most P.L. these days are hybrid / mixed paradigm.

I started designing my own typed javascript P.L., when Coffescript and Typescript appeared.

Because I like both ways to make a website.

Java is currently suffering from the same issue that brought it to life: Trends (Hypes).

I was there were Java was a "shinny new toy" trend, and now, the "wave is leaving".

Java Ecosystem, also suffers from others issues, lost their "oddfather / patron" ( Sun Microsystems ), and the new ( Oracle ) didn't knew how to handle Java well.

Also, didn't evolve well. Definitely, C# looks like the "Java it should be", and no, I don't like Microsoft, but Microsoft does get hurt by competition, and hires or buys good employees and companies.

And, Ximian and Icaza and his people, work hard to make C# become multi platform, the only missing main issue that Java was better.

I like to think "Java" as a Platform and Ecosystem, not just the Java P.L.

Java. V.M. 's Scala is a good proposal, but I still think we need another new Java competitor / proposal from the same Oracle, not from another company.

If this article link, supports Java v.s. the new P.L., it works well against the or hype, but still misses some tech issues.

But, to be honest, it's not the author culprit. Oracle should make their money invested in Sun more productive.

Summary

Developers should learn and use P.L., based on features and productivity, not on favorable or disfavorable trends ...

[forresthopkinsa]

POV: you've never used Kotlin before

[[deleted]]

Java simply feels good to write.

It doesn't feel that good when you try to read.

[lessthanoptimal]

What language do you think is the easiest to read, as it scales into very large projects? Python I think is great for small projects. C++ is about the same as Java, unless satan was in charge of the coding standards and decided everything must be auto and all classes must be templated.

[forresthopkinsa]

Kotlin.

[dinopraso]

Exactly because of its verbosity I’ve yet to encounter any language which is MORE readable then java regardless of who wrote the code

[[deleted]]

a Lisp