They forgot to mention that production Java applications apparently need to log a certain minimum number of completely meaningless stacktraces per hour to work properly. Or at least I assume that is the case from the fact that all of them do that.
And spread out among a bunch of other directories, and the java file is like...3 lines. But there are 10k files spread all around directories like this that are all 3 lines a piece with a class definition.
wait, so when .io gets deregistered, are a load of companies going to have to rename their root directories and rewrite all of their include statements?
Thankfully, despite naming them like that, it doesn't actually seem to have any real purpose. Apparently they just wanted to make sure that different companies making different libraries didn't accidentally use the same name for their project....
That’s exactly the reason. And also no company is going through the bother to refactor that shit, so everything is named based on some other company 5 mergers and acquisitions ago.
yeah you need main class coz it’s OO-language. Though, not required anymore, which should’ve been done once Java got scrip language capabilities (jshell) back in JDK 9. But as of today not required anymore
imports exist in most if not all languages. Gotta be insane writing them manually in 2010 let alone 2024
installing Java runtime (JRE) is as simple as installing any app. Though for installing JDK you need 5 mins for setting PATH. Think about JDK as like TSC or Webpack and JRE as a Browser. I’d argue installing and configuring JDK is simpler than TSC or Webpack
Unless you doing some non-trivial multi-threading your stack trace will tell you exactly where is your NPE. You gotta be as blind as my teammates to spend more than 1 minutes to find where it is coz it literally tells you file and line numer where Exception occurred
I mean, yeah if you use IDE from 2000 it will look like it. IntelliJ looks modern, though I don’t like the fact latest versions look like VSCode
I hardly reach 3G of deps from all 10 projects I have on my workstation.
IDK what anon means by ecosystem here, Java ecosystem is quite standard across the board. JDK(std lib), Maven/Gradle(deps, build, publishing), Spring Framework (all sorts of blueprints and solutions to standard app level problems), Hibernate/JPA (ORM), JUnit+Mockito (testing). These are tools and libs used in 90% of projects I worked on. Of course there will be more depending on project needs. Layers? It’s not like language imposes any layers whatsoever. It’s just common practice to have 3-4 layers and some glue in-between.
don’t do GUI in Java it sucks and will suck until Java gets string interpolation. Hopefully soon
concurrency is actually the only thing which is really bloated in Java. Which will change with next LTS version if I remember correctly. And it’s not that hard if you actually read the f manual and not just “try and hope”. Again it will become much more efficient and easier to follow soon. As of now - yeah, not trivial. But people mostly prematurely optimize, so karma
Java is kinda have 20 ways to do same thing but actually no. Java built with idea of providing simple building blocks. Then it provides more specific API built on top of those building blocks. It allows to have API which solves typical problems and provides capability to solve custom problems with those building blocks. People often confuse this as many ways to do one thing but it’s like saying “I can have byte array why I need string data type”. Those are different levels of abstraction
If he just tried to walk into Java knowing nothing or maybe PHP, and refused to RTFA, he might experience about 30% to 40% of that I just trying to do everything wrong.
The date of the post is from this week so it’s not accurate at all. Java does support main outside of a class now, and it doesn’t need to be static, or take args. You wouldn’t use JavaFX in this day and age either. Installing the jdk is absolutely nothing especially if you’re using IntelliJ as it will install it for you and manage everything. No library is even close to 3gb.
This entire post sounds like it was written by someone that last touched Java in 2010.
Source: am a Kotlin dev. Java sucks. None of these are the reasons why.
Depends on the version of Java you have to use and most places still say to put it in a class because they're outdated too. (Is anything about Java modern?)
It's not accurate to accuse Anon of "lying," when both their story and yours would point to the race conditions from threads being a symptom of someone who's just learning the language.
It's not that serious though; because it's a greentext, it is both artificial AND homosexual.
It's not someone who is learning, because "how to avoid race conditions" is like java concurrency 101. The entire thing is made to prevent that shit from happening. And it is incredibly easy to setup a "happens before" relationship.
Rust is great, and I truly mean that. But saying you can't get race conditions in Rust is just not true.
And also, not everything is going to be written in Rust. When the company you're working for needs a web application quickly, that's better done in other languages.
And also also, Spring has a lot of niceties when it comes to concurrency that make this much less of a point.
Only in the context of data within the rust code. If you're writing threaded rust that interfaces with external IO, for example, you can still get bit by a race condition. A person can absolutely be shit enough to hit a race condition in rust.
How would you run into a race condition like this with safe Rust? You can't share mutable file handles between threads for example. I'm not sure you're correct in saying its still possible. Even if it is, it doesn't sound easy.
Been coding Java for about 15 years now. Pretty much agree - anon’s primary mistake was using javaFX. From a junior dev perspective I can see why they’d do that, but Java isn’t really meant for building desktop applications, it’s meant to power web apps.
What they should have done instead is create a backend restful web service and wire up a frontend rest client with something suited to web app ui dev such as angular or react. Java has some awesome frameworks built for it over the years, something like spring boot would make building that backend service trivial if you know how to use it. JAX-RS/Jersey or even servlets could be utilized for this instead, if you wanted to.
Spring boot has some nice tooling for thread management, but Java also has pretty good options for this built in as well. As chunky mentioned, if you aren’t already versed in concurrency patterns, don’t try to perform concurrent operations or you’re gonna have a bad time. But do learn how to do this, because exploiting concurrency is one of the golden rules of good computing.
What they should have done instead is create a backend restful web service and wire up a frontend rest client with something suited to web app ui dev such as angular or react.
If anon's program was designed to work as a client for some external server or if Java had absolutely no GUI frameworks, that would be fine. But if anon's goal was to create a simple desktop application, doing this would be the programming equivalent of a Rube Goldberg machine.
With that approach, you also need to be really careful about how you do it. Fuck that part up and you can end up with the locally-hosted REST server listening on the device's public network interface or vulnerable to CSRF from a web page opened in the user's browser.
Java is religiously backwards compatible. Modern java projects are not as enterprisey and boilerplatey, but, as jdk21 is backwards compatible with jdk1.3, you can still happily write code as if it's 2003.
Additionally, the java space is huge, so just wildly googling will probably not help you that much.
On the other hand back in Java 1.2, 1.3 and 1.4 days you frequently had companies install a specific patch level version because their applications worked only with that patch level. That was back when Java was actually popular for some reason.
That's entirely the fault of applications (or more likely their libraries) using internal APIs or JNI. As long as it isn't doing anything screwy with reflection and class loading or using the sun.* packages that aren't part of the language specification, Java bytecode compiled for ancient Java versions will still work on modern versions.
It's much better today, but in 2010 that was 100% accurate.
That being said, using Java as a first time programming language is like a 15 year old trying to fly an airliner to get a few blocks away to pick up some after school snacks. Obviously it's way overkill. Sure you could get across town with it, but it's probably 1000x more complicated than just a simple bicycle or even walking.
Java is industrial strength for professionals. There's absolutely no consideration made for educational usage.
Which other eco system has more stable libraries, which are easy to install and redistribute and deploy?
I would choose always choose the most boring language for the task.
That the good thing about java that it is very boring and most likely won't run into a obscure problem if you stay away from reflection and unsafe.
Pretty much any compiled language using native binaries is easier to install and distribute. Java applications are an absolute pain to get to run to the point that most need specialized wrapper scripts (usually in shell on unix platforms) and need to tinker with memory management parameters on almost all of them.
Do you mean something like c or c++ where you have to deal with big little edian, libc, utf8, platform specific threads, various compilers feature sets and a lot of undefined behaviour.
Also if you want to distribute a library it is much harder because you a have to package it yourself or what for a distro to package your library or build a header only library which has to be manually updated every time a new version comes out. With maven you just have to upload it and you can use it in another project
How often do thinker with the memory management in Java? Just use the g1 garbage collector, which will be fine most of the time if you have a problem just use another one.
You can also compile the program with GraalVM to a native binary, also most Java programs are servers where it make sense to have a systemd service to configure the server
I have developed in java and C/C++ (many years) and Anon is maybe exaggerating a bit but not lying, we all have been there more or less.
Personally I hate how java forces you into bad architectural choices. Where is the unsigned int? Why isn't an int a class BTW? Why the pass by copy for some, by reference for others? Where is multi inheritance? Lots of things are dumbed down or you have no choice in the matter.
Sure didn't help it was a power hungry beast moving at snail speed back in the day too.
I mean they are lying because Java does support main as a top level function now. If this was written last year, sure. Also IntelliJ will literally install the jdk and manage it for you. Using asdf I haven’t had to touch the PATH for Java in probably over a decade (used sdkman before that).
This entire post sounds like someone that last touched Java in 2010 and wanted to complain about it again. Java is shit, but for none of the reasons in the post.
It's easy to accuse a noob of making the wrong choices when you have the experience necessary to make the right ones. There are a ton of outdated guides on the internet for every programming language. I'm almost certain there is some school kid downloading an old Borland C++ version right now, because the youtube video from 2010, regurgitating a tutorial from 2004 said so.
Only have a beginner perspective, but in school I did really well in intro CS class that used Python. 2nd class was in Java and it almost broke me I was so confused.
Concurrency isn't bad, and package management (while maven is absolutely terrible to work generally), the dependency chains aren't exceptionally bad. Getting it installed is easier than python on platforms it's not already there on, not because it's more portable, but because the installers do more for you. Portability is hard, they haven't done it well but they've paved the default use case pretty well (although that works against you when you get to harder cases)
But the rest is pretty close.
The worst is the scaffolding, it's literally superstition for years to gain the understanding as to why you're doing it. I took two years of Java in high school before getting a degree - it was 4 years and halfway through a degree before I understood why I was making a class with a method main(string[] args). It works like that because your entry class calls the main method with a list of string arguments... I didn't understand at all, because even though it's simple it's a special case, and I'd never seen anyone name the string array anything different, so I just copied and pasted it, never understanding it because I'd been told "you just have to have that" for do long
Builds are arcane too - there's still companies that only use netbeans in their build pipeline, Android still requires a specific an old Java version in conjunction with the IDE or a gradle build, at best a project uses maven (the package manager), which is xml based and full of arcane details that are best treated as a magic incantation to be copied exactly from elsewhere
Anon pretty much sums up my experience with Java when I had to learn it in college 20-ish years ago. I'll never get rid of my distaste for the language I'm afraid.
Anon is absolutely exaggerating for comic effect. That doesn't mean Java doesn't have all of those problems though, it just isn't as ridiculous as they made it out unless you get dragged into enterprise bullshit (then you're in for it).
For the “simple” apps anon is talking about, they are exaggerating a lot. Though, when you get beyond the obligatory “Hello World” and “a window with a button”, the complexity does start to increase exponentially.
Throwing in frameworks like Spring or JavaFX does make things more complicated. But it’s still relatively manageable once you get used to it and know what goes where and when.
Now the whole configuration thing, that’s an art form best left to those hooded “seniors”. It’s good to learn eventually, but not when you first start out; lest you have a fetish for pain.
Java has come a long way. It’s not the languages fault that people create monstrosities like AbstractJavaFinalSerializedFactory or whatever. But if you do want to be “good” at Java, you will want to learn about design patterns. It also doesn’t hurt to have a thick skin too, because you’ll be both criticized and made fun of for your choices. 😊
If you've never used Eclipse, which I assume it was referencing, it does feel old, clunky, and ugly out-of-the-box (to me at least). I tried to use IntelliJ wherever possible, but a previous company had a project that really didn't like to run from it but would with a very specific setup in Eclipse (I don't recall any details now more than 10 years later).
There is a fair bit of boilerplate and bloat.
I don't remember UI stuff being so bad, but most of what I worked with was old Swing/AWT stuff. I did have to use JavaFX (I think it was?) once and remember something about it being frustrating, but it was for some existing thing I had to modify.
I don't mind Java so much, but it's certainly not my favorite language.
I don't know how one gets a nullPointer when doing a hello world, though. I'm guessing this is embellishment or mashing together something later with their initial printing of hello since I think you'd come up with some other error in that process to getting something to print before nullPointer.